Having problems with message search?
On May 9, 2007, at 9:49 am, J Bradley wrote (off-list):
... I’m on PowerPC G5 10.4.9 with Entourage 11.3.3 (can’t get 11.3.4 to install – tried 5 times! grrr!)
I also have an Intel but haven’t tried the new beta on that yet.
My mistake about assuming that you were using Mail, even though you had mentioned before what you were using. Your problem description seemed like a typical Mail problem.
I only have the older Entourage 10.1.6. Hopefully, that doesn’t matter. I have no idea about your installation problems.
Previously i was using 4.02 running in FMP 6.0v4, which was working fine.
Attached are the sources from the two mails, and a screenshot of the one that came out wrong.
Thanks for the message sources. If you were using Mail, they could be fully tested and debugged in AppleScript using my scripts for Mail. Entourage, however, takes care of all the decoding and simply sends text to my script.
So let’s start over. In your first error report, on May 7, 2007, at 1:38 pm, you wrote (to eMA-Talk):
Mainly - most mails from a colleague that uses Google Mail (to send) - andmost (80%?) of his mails seem to loose all the line feeds on their way in.It looks like the ones that are ok have extra non-utf-8 plain text chunks inthem, but i can't see why
Both sources you sent use UTF-8, which is simply the "character set" used to send each character, not the content formatting.
The email source called "working" was a very standard format with "alternative" text/plain and text/html parts included (the email program chooses which one to display) , as well as a JPEG image attachment. So it would be a real mystery if it didn’t work.
The other one, "notworking," also has two "alternative" parts labeled text/plain and text/html, but they are not just text. Both parts use a "Content-Transfer-Encoding" of "base64" for the text. That stuff, in the source, just looks like a block of garbage characters. And this is probably how you received the 80% of your friend’s emails, that were archived without their line breaks.
Entourage normally decodes the base64 just fine, and returns normal plain text to my script, which eMA sends to FileMaker. (I am presuming here that Entourage itself displays both kinds of emails correctly, right?)
My best guess is that the "base64" encoded text included ASCII "line feed" characters at the end of paragraphs, without any ASCII "return" characters. Entourage could display either kind correctly, but sent eMA the same text, with line feeds and no returns.
However, FileMaker does not display line feeds as line breaks when they are sent to it by AppleScript. It only displays return characters that way. (To make it more confusing, I can copy and paste the same text into FileMaker, and it does display the line feeds as line breaks.)
To test this, the source is of no help. I need to have the actual message in Entourage, and then archive it into eMA.
But I am sending you a small AppleScript application (off-list). If you run it, when that badly formatted message is displayed in eMessage Filer or FileMaker, the line breaks should immediately be fixed—if my guess is correct.
If it works, you could fix all such archived messages that way. And if it does work, I will also then revise the Entourage script, with that feature built-in, and then send it to you. Or, I will issue a new beta version of eMA.
Alternatively, or if this doesn't work, send me, as an email attachment, a ".eml" file of a complete Entourage message that does not archive correctly. You can make one by dragging the message from the message list in Entourage to the Finder Desktop. Then I can test it further.
(I don’t understand why Google would format these two messages differently: it would seem that they were processed on different machines, one of which used base64, for no apparent good reason. Or, it may be that your correspondent sent them two different ways: perhaps, for example, he initiated some from his own email application and initiated others online, from a web site.)
The prev button thing sounds strange – i just checked and it still does it (on the list view, showing more than one page of records, go to the end, select a record then click the prev button (or use CMD+left-arrow). For me the list redraws and i end up on the first page. If i use CTRL+up-arrow though it works properly – most curious!
Well, I solved that, now. I had a "Scroll Window [Home]" command in all four button scripts, but that line was disabled in the Next button. It was meant for the Msg View, and I just never noticed what it was doing when in the List View. Obviously, I didn’t finish testing this one, so I have disabled them all, for now.
--
Cheers,
John
Offline 
Send Email