More on scewed up attachements
mm
Originally only concerned sending from a PC to a Mac.
Partial solution at the bottom. Mac users will be especially
interested, but so will Eudora users.
Background:
For the last 6 or 9 months, my friend sends me a file as an
attachmment to email and I display it, convert it to .rtf and .htm,
and use Eudora to send them back as attachments, and until a couple
months ago, this worked fine for the .rtf files, but the .htm files
never looked good. By "never looked good" I mean the standard English
font, which was 90% of the text, looked fine, but the Hebrew was all
garbled.
I'm using MIME protocol. While someone suggested Base64, a subset of
MIME IIUC, Eurdora 7 only has three choices, MIME, BinHex, and
UUEncode. My friend's Mac is using a fairly new verion of Mac/OS,
maybe the newest.
OTOH, when I sent the files to myself with Eudora, both formats looked
fine.
About 2 months ago I switched from win98SE to winXP and at that time,
it seems, the .rtf files started being garbled in the Hebrew also.
OTOH, since the problem started, I booted into win98 and sent the same
files and this time both formats were garbled at the Mac end. (Neither
from win98 nor winXP did I try resending old files that came out well
the first time. Including these and others, there are so very many
possible tests to make and I've spent so much time on this as it is.
:( )
I also determined that the files at the Mac end were maybe 5% shorter
more or less than when I sent them, but when a couple were sent back
to me, they were the same length as went sent from the Mac.
And I think in the missing 5% there was font information for the .htm
files. But what about the .rtf files. Do they carry font
information with them, for special fonts like Hebrew??
PARTIAL SOLUTION!! and as a Eudora patriot (or programmiot) I'm not
happy about this either.
I sent an .rtf file and an .htm file from Outlook Express to my own
computer, reading it with Eudora. In the .rtf file, the Hebrew was
garbled. It's not an inline attachment. I'm not reading it with
Eudora but with Wordpad, which read it just fine before I emailed it
to myself.
OTOH, the .htm file came out perfectly for me and also for my friend
with the Mac.
So OE works half the time for sending attachments to Mac and Eudora
works not at all. But Eudora works all the time for sending
attachments to myself, but now not at all for sending to a Mac.
I don't know what protocol OE is using. I looked in Options and
several places in Help and couldn't find where to set it or any
reference to it.
Should I now try Thunderbird, or Netscape email, etc.?
Should I send files from Eudora to OE?
I think there are too many possible tests to make.
mm
John H Meyers
[I think we just went through this two weeks ago,
but my memory is so short I'm doing it all over again :]
> For the last 6 or 9 months, my friend sends me a file as an
> attachment to email and I display it, convert it to .rtf and .htm,
> and use Eudora to send them back as attachments, and until a couple
> months ago, this worked fine for the .rtf files, but the .htm files
> never looked good. By "never looked good" I mean the standard English
> font, which was 90% of the text, looked fine, but the Hebrew was all garbled.
Was Hebrew sent using UTF-8 (character encoding)? Eudora doesn't handle UTF-8.
> I'm using MIME protocol. While someone suggested Base64,
> a subset of MIME IIUC, Eurdora 7 only has three choices,
> MIME, BinHex, and UUEncode.
MIME (Multipurpose Internet Mail Extensions)
is now the universal structure, for both Windows and MacOS,
for sending multipart messages, including attachments,
while "base64" is simply one of the possible encodings
which can be used within a MIME message part:
http://en.wikipedia.org/wiki/MIME
http://en.wikipedia.org/wiki/Base64
Eudora should generally automatically decide
the proper encoding for any attachment,
using "base64" for things which can not be sent as text.
However, when you send an attachment, such as RTF or HTM,
which is likely to be a text file, make sure that you have
depressed the "Text as attachment" button
in the formatting toolbar within the message composition window,
so that the file will actually be sent as a separate attachment,
rather than being included within the message body itself.
The "Text as attachment" button is immediately to the right
of the "QP" button (one usually leaves both of these depressed).
When no "stationery" is used,
the "Composing Mail" option
[x] May use quoted-printable [DO]
and the "Attachments" option
[ ] Put text attachments in body of message [DON'T]
set the initial state of those buttons
in each new outgoing message; however, if you use
any "stationery," then the button states that are
already saved in the stationery are used instead.
As an alternative to these concerns about text attachments,
you could enclose your attachments in "zip folders,"
which the lastest MacOS can automatically un-zip,
just as can Windows XP (and later).
"Zip" files are always binary, and are always "base64" encoded,
so that the file which the recipient receives will always be identical
to the file which the sender sent -- this does not, however,
ensure that each person's computer will process the identical files
in the same way. After all, even HTML (and its extensions)
can be so varied that different browsers often do not handle
the same thing in the same way, which is why many webmasters
either struggle to make sites compatible with different browsers,
or else just paste a "best viewed with Internet Explorer 8" sticker
on their page, and say "your experience may not be so good
with non-supported browsers" :)
> About 2 months ago I switched from win98SE to winXP and at that time,
> it seems, the .rtf files started being garbled in the Hebrew also.
> OTOH, since the problem started, I booted into win98 and sent the same
> files and this time both formats were garbled at the Mac end. (Neither
> from win98 nor winXP did I try resending old files that came out well
> the first time. Including these and others, there are so very many
> possible tests to make and I've spent so much time on this as it is.
> :( )
RTF files are interpreted by a program, usually Microsoft Word.
Doesn't "Word" also have different versions,
which from time to time may act a bit differently?
Good old "plain ascii text," made from only 7-bit characters,
was once impossible to misinterpret, but unfortunately,
it included only "Western," unaccented characters.
Now that we have so many ways of encoding character sets,
many of which have incompatibilities, it's back to the good old
"Tower of Babel" again :)
For quite some period, various 8-bit characters
were re-used in different character sets,
to represent different letters or symbols in each set,
which requires the users at each end
to agree on the same set at the same time,
or otherwise produce misinterpretation.
If you happen to be the user at both ends
(when you send files to yourself),
this is easier than when you correspond with someone else,
particularly if their software is very different.
UTF-8 is designed to create a universal standard
for all character sets, using multi-byte characters
to keep expanding the range of possible
uniquely defined characters, to encompass all languages,
without re-using any character,
thus potentially solving this problem.
It is not trivial to accomodate UTF-8 in a program,
particularly if everyone keeps typing on varied keyboards, etc.,
but a goal was announced some years ago
that email software should try to incorporate UTF-8.
Most email software did, but Eudora never caught up.
An independently written "UTF8ISO" plugin for Eudora under Windows
is able to decode UTF-8 for many "Western" languages
into 8-bit "ISO" character sets which Eudora can display natively,
but this doesn't necessarily work as well for other languages.
There are still people managing to exchange email using Eudora,
however, in Hebrew, in Japanese, and other languages,
but whatever arrangements they use are not universal.
> I also determined that the files at the Mac end were maybe 5% shorter
> more or less than when I sent them, but when a couple were sent back
> to me, they were the same length as went sent from the Mac.
MacOS uses 1-character text line endings (CR or LF),
while Windows uses 2-character text line endings (CR+LF);
this frequently accounts for such differences,
particularly when the difference equals the number of lines :)
If text from a Mac looks bad in Notepad, open it instead with Writepad,
or convert it with some good universal editor, such as I mentioned last time:
http://www.editpadpro.com/editpadlite.html [free, fewer features]
http://www.editpadpro.com/cgi-bin/affref.pl?aff=jhmeyers
"Pro" version, free trial for 30 days, basic features
(and some "Pro" features) continue working forever,
the above is my "affiliate" link.
> But what about the .rtf files. Do they carry font
> information with them, for special fonts like Hebrew??
Windows font info is included.
> PARTIAL SOLUTION!!
"Something is better than nothing" :)
> Should I now try Thunderbird, or Netscape email, etc.?
Netscape? When is the next version due?
Try Thunderbird -- or, you could even try "Eudora 8,"
which happens to be a special version of Thunderbird,
enhanced by former Eudora developers to sort of resemble Eudora,
but being Thunderbird in reality, it supports UTF-8, in case that helps.
It is not guaranteed to help, given all the mysterious
conversions that you are currently performing,
which may never even try to use UTF-8, for all I know,
but science needs pioneers, to boldly go
where no one but Captain Kirk has gone before :)
http://eudora.com/betas/
https://wiki.mozilla.org/Eudora_Releases
Come to think of it, try Gmail -- all computing
is going into the "cloud" anyway,
so might as well ascend to Heaven right now :)
FWIW (never tried by me):
Microsoft Viewer Plugin - on this "Eudora plugins" page:
http://e-gadgets.freehostia.com/plugins.htm
"This viewer supports Central European, Cyrillic, Chinese, Japanese,
Greek, Hebrew, Korean and many other international characters and
alphabets. It supports Unicode (UTF-8), ISO, Windows and even
DOS standards, plus, it has auto-detection encoding capabilities
(which may not work always; in those cases you have to
change encodings manually; it's "Encoding" from drop-down menu.)"
Want to see the (official!) "Future birthplace of Captain Kirk"?
[in the next county north of my home]
http://www.youtube.com/watch?v=1H4SH3Zx6xg
http://en.wikipedia.org/wiki/Riverside,_Iowa
http://www.youtube.com/watch?v=5sl-X9GyJho (you just missed it!)
--