HTML-friendly return characters in calculation strings

[iMarcW]

Is there any way to include a return character in calculation text strings that browsers won't choke on?

There's the pilcrow, of course, but this resolves to a "gremlin" as far as BBEdit is concerned. When exported to text, it's not considered a return at all but some sort of non-standard, unreadable character. Simply including a return inside the quote leaves a single space, and backslashing one doesn't seem to work either.

I'm thinking some kind of ASCII character code or HTML entity, or perhaps there is a way to encode the exported output?

[comment]

When exporting as text, Filemaker reserves the "real" return character for separating records - so returns in fields must use something else. Text files are not intended for consumption by browsers anyway.

You have a number of choices here, starting from a simple Substitute() through GetAsCSS() and GetAsURLEncoded() and ending with a full-fledged HTML document, produced by exporting either as HTML table or as XML with a stylesheet. It all depends on what you are actually trying to do.

[iMarcW]

Thanks for the reply. It makes sense that FileMaker reserves the return character in that instance. I just discovered something interesting though. If you use the pilcrows in a single text field and export that field's contents, it renders the returns correctly, because there are no records to separate. So, problem solved, for me anyway.

I'm trying to export simple HTML from a database through a script that writes the information from each record to a global field, then exports that field's contents. I did it to replace unstored calculations I was using to do the same thing (which would give a return after each record when exported), but I didn't realize until now that it also gives me the ability to use the pilcrow return characters within the field, so I can still put each record's contents on a separate line.

[comment]

Yes, that should work for you - if the receiving links don't mind UTF-16 encoding. This was discussed at some length here:

http://www.fmforums.com/forum/showtopic.php?tid/192035/post/275735/#275735

I am not sure what advantage a global and a script have over an unstored calc, but in any case the "correct" (albeit more difficult) solution is to use XML. Or, if a simple table is sufficient, export as HTML Table.

[iMarcW]

Yep, it works, they just show up as returns, with no encoding issues. As to why global/script vs. unstored calcs, it just seems to make for less overhead. I need to export HTML in several formats, and instead of having a separate calculation field for each format, I can keep the formulas in scripts and have them all use the same global field to assemble the data for export (it would be even better if you could use a variable and export the contents of that). HTML tables are too simple, XML too complex.

[Fenton]

Export 1 field (any field) via xml with stylesheet:

<?xml version="1.0" encoding="utf-8"?>



xmlns:fm="http://www.filemaker.com/fmpxmlresult" exclude-result-prefixes="fm" >

	

	

		

	

[Fenton]

Another fairly simple method, on a Mac. Use a shell script in a Perform AppleScript step. By default it writes a utf-8 file, and it translates the internal FileMaker line endings to Mac returns.

	copy cell "filename" of current record to fileName

	copy cell "Text_" of current record to exportMe

	do shell script "echo -n " & quoted form of exportMe & " > ~/desktop/" & quoted form of fileName

	-- -n prevents a final line feed from being added