Trying to create a x-platform export of iCalendar data and problems on PC with EOL characters

[Gary Brusanowski]

I'm trying to export an .ics file that includes iCalendar data for use in iCal, Outlook, Google Calendar, etc. I'm using a technique from this discussion

http://fmforums.com/forum/showtopic.php?tid/188654/

where I'm building my data in a single field with embedded FileMaker returns and exporting the one field from one record using Fenton's XML style sheet. The Mac version works okay, with a single line feed at the end of each line. But on the PC, I'm getting 2 line feeds, not carriage return / line feed like I would expect. If someone can look at the sample file and let me know where I'm going wrong, it would be very much appreciated.

TestExport.fp7.zip

[comment]

It sounds like the same bug as described in the thread you mentioned. There is a link there to another thread with a possible workaround.

I suggest you submit a bug report to FMI.

BTW, you are only exporting one record, so the record delimiter you have specified in your stylesheet is irrelevant - you are dealing with in-field carriage returns here.

Edited June 28, 2009 by Guest

[Gary Brusanowski]

Thanks for the tip, but are you saying the style sheet I'm using won't work in this case? If so, can you point me at one that does and let me know what inside should be changed to make this work?

Thx

[comment]

I am saying no stylesheet will work unless you modify the actual data being exported, as described in the workaround. Note that I am saying this based on the various reports - I am using a Mac myself, and cannot test this.

[Gary Brusanowski]

Sorry, I misunderstood. Can you point me to the workaround?

Cheers,

Gary

[comment]

http://fmforums.com/forum/showpost.php?post/305783/

[Gary Brusanowski]

I'm afraid your Workaround file didn't work; I'm still getting double line feeds when outputting on Windows. I've included a sample output file here.

CourtCal.ics.zip

[comment]

I don't see your implementation of the workaround, so I cannot offer anything useful on that.

BTW, I took another look at your file. You don't need this workaround at all. You can - and should - export your data directly from the events table, instead of composing the entire file in a global field (which requires carriage returns in the field, which in turn trigger the bug).

Alternatively, you could just export the global field contents - provided that your target application doesn't mind UTF-16 encoded input.

[Gary Brusanowski]

Thanks for the input. As for implementation I just pasted your Workaround stylesheet in the container and it's used during output. As for just setting it up it as separate records unfortunately, this isn't practical. The system this will be used on is remote and the number of dates it will have to output could be in the thousands. Initial tests doing it that way would have made the feature pretty much useless to my client. This way is far faster but, of course, isn't working on the PC yet. And also unfortunately, the target apps need UTF-8. I really just need a style sheet that will convert the vertical tabs to PC CRLF properly.

[Fenton]

Sorry, didn't respond sooner. The extra returns is a problem that Windows causes. The below is an excerpt from a posting by Beverly Voth (on another list).

IF your xsl:output _method_ is "text", then you must, let me repeat: MUST, optimize your XSLT. What that means is remove any and ALL whitespace from between and around tags and text, unless the text is intended to be included.

What you are seeing (on windows) is the additional whitespace (returns) that are in the XSLT. It shouldn't be that way, they should be IGNORED, but there appears to be a bugglet there (windows only, as mac does not require the optimization).

[comment]

I just pasted your Workaround stylesheet in the container and it's used during output

Pardon my bluntness, but had you taken the trouble to read the entire thread or to examine the demo file, you would have seen that the contents of the exported field need to be modified in order to use this workaround.

As for just setting it up it as separate records : unfortunately, this isn't practical.

I thought you already had them as separate records (at least in the file you posted I see 16 separate records). All you need is to export them as they are. Surely looping through thousands records to collect them into a single field cannot be much faster?

[comment]

This was discussed on the other thread, too - but following Beverly Voth's suggestion didn't help.

[beverly]

Gary contacted me directly. Gary, I cannot download your file, please send it mailto:[email protected]

What we are saying: you must remove any spaces or returns in your XSLT that are NOT used for spacing. For example:

This will place a return in your output. You can't see the character, but it's another line (return with CR/LF - depending on platform).

Beverly