Re: [Evolution] 8 bit characters problem back ?

[Larry Ewing <lewing helixcode com>]

On 10 Dec 2000 18:16:12 -0500, Jeffrey Stedfast wrote:
> [comments below...]
>
> On 10 Dec 2000 18:29:30 +0100, César Talón wrote:
> > El 10 Dec 2000 15:20:11 +0100, Fred RISS escribió:
> > > Hello,
> > >
> > > It seems to me that an old gtkhtml bug is back. I receive a lot of mails
> > > with accentuated caracters and after recompiling the anon CVS version
> > > of evolution (with the anon CVS version of bonobo, gal and
> > > gtkhtml) the lines containing such 8 bit characters are cut at the
> > > position
> > > of the first of those... I can't even write any in the composer.
> > > Did I get an outdated version or is it really back ?
> >
> >
> > The problem with gtkhtml that stops showing the rest of a line from an
> > accented chars is still there if you don't have the locales right. For
> > me the only way of making it work directly was using my locale in
> > /etc/environment, regardless of the gdm language setting. With that
> > setted up, everything works fine, except html mail.
> >
> > HTML mail doesn't show the accented chars correctly, instead it shows
> > chars like: "ó" instead of ó, "í" instead of í, etc. This only happens
> > with HTML mail and composing mail with HTML, however, if you answer a
> > mail as plain text, the chars appears fine.
>
> I just got a thought about what might be causing this but I'm not sure.
> If you could confirm this, it'd be great. All the HTML mail I have with
> 8bit chars (and I don't have much) has a charset set to UTF-8. The chars
> you are seeing suggest that the html editor is getting UTF-8 chars
> instead of whatever the charset should be (iso-8859-1 should work for
> the examples you gave).


Right now the mailer is feeding gtkhtml with a pure utf-8 stream when of
html.  This is what it is designed to do, but gtkhtml is incorrectly
assuming the input it is getting is iso-8859-1.  This is very bad and
leads to the corrupted display problem.  The only incoming html parts
with 8 bit characters that display correctly in evolution right now are
ones in which all the high characters are encoded as html entities.
This bug was well hidden because evolution uses entities when it
converts text/plain to html and the composer saves all html with
entities.  I'll clean this brokeness up as soon as I can.

It also looks changes in how addresses are kept is breaking the address
display in the composer because it seems to be handing non-utf-8 text to
e-entry which expects utf-8.  And last but not least e-entry is broken
because it is expecting utf-8 in STRING atoms on the primary selection.
Hopefully we can take care of most of this before the next release.

--Larry