GNOME Bugzilla – Bug 339052
Evolution can't handle Latin characters when system encoding is set to UTF-8
Last modified: 2006-04-20 20:28:44 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/evolution/+bug/19760 "My Ubuntu is configured with UTF-8 locales and when reading e-mails on Evolution that were sent with a iso8859-1 encoding and contain accentuated characters, those characters aren't displayed. If I change encoding, in the menu, to iso8859-1 the email message displays alright but I feel I shouldn't have to manually select the encoding, especially because that email has the header: Content-Type: text/plain; charset=ISO-8859-1; ... > Thanks for your bug. What version of the package do you use? Can you forward or attach a bogus mail to bugzilla? ... http://librarian.launchpad.net/1510892/test.email Created an attachment (id=3252) Test case Evolution 2.3.7-0ubuntu2. If you open this email on a UTF-8 configured system with Evolution the body will be empty. If you change it to iso8859-1 it'll show the latin characters. ... This problem still occurs. I'm from Portugal and most of the time I receive emails encoded in latin1 so I have to keep switching encodings and it's starting to become really annoying. Do you have any indication of a fix for the problem? Evolution version is 2.6.0-0ubuntu4"
WORKSFORME I just tested his email message and it works fine for me on a UTF-8 system.
It has the same behaviour as for the submitter on my box, using GNOME 2.14.1 on dapper. Some issues are config dependant and don't happen for everybody, that's doesn't mean there is no bug, reopening. Is there any function responsive for the encoding detection or any variable to make it verbose about it and track the issue?
Jeff: it would be nice if you'd at least pretend to be interested in helping people debug. WORKSFORME is a perfectly valid resolution, but 'hrm, it works here, maybe you could provide more details?' + NEEDINFO is usually, well, more polite.
add some debug printf's to em-format.c:em_format_format_text() I guess
the only settings that I can think of that could possibly affect this are: [fejj@linux ~]$ echo $LANG en_US.UTF-8 and gconftool-2 --get /apps/evolution/mail/display/charset UTF-8
Jeff, I can reproduce this on my machine. It looks like a problem with the inline-pgp code. If I remove the inline-pgp blocks, and just leave the text body of the message, it works fine. Could be that it can't verify the sender for me, but the signature is valid, and it is verifying the sender on your machine?
nah, I get invalid signature on my machine too.
LANG to en_US.UTF-8 or /apps/evolution/mail/display/charset to UTF-8 makes no difference em_format_format_text() has emf->charset==NULL the default charset has no value by default, setting the key to UTF-8 makes the code have charset == UTF-8 but that doesn't work on the mail which is an iso-8859 encoded
emf->charset is the override charset, and so is hardly interesting. what we care about is the charset variable, as gotten from the dw->mime_type anyways, I think I see the problem... the guy that wrote the inline pgp handler code didn't think to set the ACTUAL mime type on the munged mime part. Yay :\ The more I poke at this code the more bugs I find. I should just rewrite it from scratch, practically had to do that to the pgp stream filter as it was.
Created attachment 63973 [details] [review] 339052.patch Attached patch fixes the problem
comitted to CVS
the patch fixes the issue, thank you for investigating and fixing that!