exporting html as tab separated text file on a PC.

[Batfastad]

This one is pretty specific.

But basically I use a series of filemaker fields to build an html calculation field which I then export in a tab separated text file.

The tab separated file is renamed .html, then attached to an e-mail to form an html e-mail newsletter using a program called GroupMail Pro.

However there is a problem.

This is all done on PCs and the e-mails display fine on PCs.

However when we come to view them on Macs then for every line break there is a square character.

This happens in Entourage X, Mail.app, and Thunderbird

When viewing the source of the message it seems many of the line breaks and quotation marks in the code have been replaced by the following =0B

I think that =0B is then being replaced by a square character by the mac e-mail client.

Is there anyone who's encountered this problem before??

[DykstrL]

I am doing something similar to build HTML pages for updating a web site and had the same problem.

I build the HTML code in a global field and parse out all line breaks - then export as a single record in a tab-delimited file with a ".HTM" extension. The code looks really ugly and unreadable, but it seems to look just fine on a MAC.

[Wim Decorte]

Windows uses CrLF as the end-of-line character. Mac uses only one of these (I always forget if it's Cr or Lf - Cr = carriage return, Lf = line feed)

Since those are ascii characters outside of the normal character scope they turn up as squares.

Before you deploy on the Mac you probably need to strip out the offending character. It can be done in an automated way through AppleScript and BBedit, I'm sure. You can also do it through VBscript and Regular Expressions.

HTH

Wim

[Batfastad]

Is there a break character I can use on the PC that will display on the mac?

[Fenton]

Couldn't you just do the whole thing as HTML, where <p> is the same on any platform?

Another alternative is just the line feed, which is ASCII #10, or n (grep symbol). It is the default line ending on Mac OS X (more or less, we can also read rn, which was Mac OS 9's line ending). If I save a text file as Unicode text with n it opens OK with MS Word or WordPad on Windows, as Unicode text. Don't know about email.

This whole line ending thing is a bit of a fiasco. Too bad they didn't just stick with Lf, which I believe was the first. I don't really know why; must have been some reason, besides driving us all crazy.

Ah, upon looking at my trusty ASCII table, I see that x0B is ASCII #11, which is the "vertical tab" character, which FileMaker uses for returns in multi-line text fields. That may be what you're seeing. Perhaps your Windows programs are translating that to a return automatically, so you don't see the problem.

You could explicitly translate those to returns; but then it's not really what we call "tab-separated" text, 'cause it has extra returns. I don't know how/why you're using tab-separated text in an email, so don't know whether it's a problem or not. if it's just the ASCII #11, then it's not so much a line-ending problem as a weird character problem. Can you just remove them?

We Mac users send emails to PC people all the time; line endings are never a problem. So something's up; don't really know what.

[Batfastad]

The problem is that the HTML file is built in the database so we can have the archive of items served to the web.

It is then exported as filename.html in tab separated format so it can be attached to our bulk e-mail software.

I thought tab separated text would have no impact on the formatting of the file, because it is just a one record, one field export.

In my calculation field that builds the export field from other fields, I have many of the FileMaker line return characters (that backwards P thing) to make the source code easier to edit after export.

I'll try removing all the FileMaker line returns to see if that does the trick anyway.

Thanks