Jump to content

'Soft Returns' default to full Carriage Returns


hmedia
 Share

This topic is 5692 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hi,

I'm developing an automated batch export of a bunch of fields with SoftReturns between each line, so the info can be collected at the other end by InDesign and formatted on the run. All sounds cool huh. It almost all works, but...

FileMaker always changes my SoftReturns (Linefeeds) back into FullReturns. The formatting of the text when it gets to it's InDesign location relies on the line breaks to be SoftReturns.

Anyone know anything about FMPro's distinct dislike of SoftReturns? I'll Find/Replace in InDesign but would love a FMPro solution if it exists.

Paul

Link to comment
Share on other sites

  • 4 weeks later...

I am having the exact opposite problem.

In several calculated fields, I use the paragraph end character (¶) and when I export the combined calulations for all the records in the found set, the paragraph returns I entered are all "soft" end-of-line returns (in Pages and in MS Word they look like a down arrow, bent to the left MS Word finds them in Windows with CNTL-l, but can't find them on a Mac). The only true paragrah break occurs between each record.

Does anyone know how to get "true" paragraph returns?

Link to comment
Share on other sites

Here is a file that illustrates what is happening to me -- if you click the export button, and look at the resulting text file in a processor with "invisibles" showing you will see that the paragraph returns (backwards P with a double-staff) in the calculations get converted to soft line feeds (down arrows, bent to the left).

My guess is that you are using a combination of calculated fields and "stacking" them on top of each other. You only get a true paragraph return character between layer, but not inside of each layer. My problem is that I am stacking everything inside of a calculation, which is why I am getting only soft returns.

So, to answer your question, if you reduce everything to a single calculated field, your hard returns should go away. It looks like my only answer is to use a looping script that builds each record in a single humongous global text box and then export it... hopefully before the memory limit is exceeded.

Ugh-Lee, at best!

Paragraph_Endings.fp7.zip

Link to comment
Share on other sites

I deleted your post (the one you forgot the file as an attachment) as a [color:red]Duplicate Post. In the future, you can add a forgotten file by Editing your post. I.e. Click on the [color:blue]Edit Button in the [color:blue]Body of the post, and then jump to the [color:red]Manage files area, add your file, and [color:blue]Submit the Changes.

HTH

Lee

Link to comment
Share on other sites

"I'm developing an automated batch export of a bunch of fields with SoftReturns between each line..."

FMP doesn't have "soft returns". It only has carriage returns which usually display as the reverse-P characters (aka pilcrows).

Most export file formats like CSV and Tab use carriage returns as row (record) delimiters, which means they canot be included in exported text. It might be possible that FMP is converting the carraige returns into new-line characters which would show up as the bent left arrows. (These aren't soft returns either.)

Try exporting the text as html tables instead: the paragraphs will be converted into

html codes. An xml file format might also work, if InDesign can work with it.

Link to comment
Share on other sites

Long story short

- build the text you want to export into a global field

- then use Export Field Contents

- import that file into a file with one field

- Export to final file

Using your example file you can see the difference between export types.

File 1) ManualCR.tab is just as the name suggests a manually typed file with Carriage Returns at the end of each line.

File 2) Export.tab is the field exported (using File>Export), notice the "returns" are hex 0B instead of the 0D 0A that you see when manually creating the file.

File 3) ExpFieldContents.txt is funky. Apparently there are extra characters between each character that is exported and the returns are a soft return - 0D. FileMaker does however import this as if it were the first file ManualCR.tab

File 4) Export2.tab is the result of importing ExpFieldContents.txt into a new file and then exporting those records.

Export.gif

If you can't veiw the picture because its reduced you can find it at https://home.comcast.net/~fu2jobu/Export.gif

Link to comment
Share on other sites

This topic is 5692 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.