Björn Persson wrote:
Tim wrote:
On Wed, 2008-07-30 at 20:54 -0500, Kevin Martin wrote:
So if messages are sent using an encoding that you are not this will
happen? Crud, how do you get around /that/?
Your client should automatically display the text correctly, transcoding
if it has to. Of course, that will only work if:
1. The message correctly identifies which encoding it used.
2. It's an encoding that your client understands.
3. You have fonts that can provide the characters needed.
4. You haven't forced your client to use a particular encoding.
5. The message hasn't been mangled in transit.
Thunderbird is good with character encodings in my experience, so points 1 and
2 shouldn't be a problem on your end, Kevin. Point 3 should give different
symptoms. I don't know if point 4 is possible in Thunderbird. You may want to
check that, but otherwise the problem is probably not with Thunderbird. Then
it's either the other person's email program, or a broken gateway (point 5).
If you think all of that is a right headache, it is. That's why there
was a push for unicode all those years back. One scheme for everyone,
and no transcoding required.
Unicode was invented some 50 years too late. A gazillion different encodings
were created in the meantime, and now we have to cope with the mess.
Björn Persson
Well, my encodings /were/ set to force UTF8 in and out. I've now just
set that as the default but aren't enforcing them with the
Preferences->Display->Fonts check boxes anymore. It looks /better/ but
still non-alphanumeric characters (like apostrophe) are hosed. Maybe
I'll change my default from UTF8 to one of the ISO "standard" encodings
and see how it looks.
Kevin
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
