Re: [Evolution] Character encoding specified in Content-Type field of outgoing messages

[Dan Winship <danw ximian com>]

> What I had been doing is pasting some text containing a Euro symbol from
> a stored message, described as being of charset=ISO-8859-1 in the
> Content-Type header of that message into the message I was composing. If
> before I do the copy and paste, I change the window showing the stored
> message to display as ISO-8859-15, the message I compose gets sent out
> as ISO-8859-15. However, if I leave the window with the stored message I
> am copying text from so that it displays text using ISO-8859-1,

Does the character display as a euro symbol when you view the message as
iso-8859-1? If so, then either there's a bug in something or you have
font problems. The message ought to appear differently depending on
whether you view it as 8859-1 or 8859-15, and it should only show a euro
symbol if you display it as the latter.

The message does not inherently have "a euro symbol" in it, it has an
0xA4 byte in it. When you view the message as iso-8859-1, that byte gets
converted to Unicode character U+00A4 (the unknown currency symbol), and
that is what is copied and pasted into the composer. When you display
the message as iso-8859-15, the same 0xA4 byte gets converted to Unicode
U+20AC (the euro symbol), and that is what gets copied and pasted into
the composer. The composer overrides your default charset selection,
because if you have pasted a U+00A4 into the message, it can't be sent
as iso-8859-15, and if you have pasted a U+20AC into the message, it
can't be sent as iso-8859-1.

> Why can't Evolution simply send out messages specifying that charset in
> the message header which the user selects in the Character Encoding
> menu?

The fact that users ever have to know about character encodings is a
bug. The way it should work is that you should just be able to type
stuff, and the mailer will handle encoding everything correctly so that
the recipient sees what you typed. The menu exists because things don't
always work that nicely in the real world, but it's only there as a
hint. "*IF* you can send this message in iso-8859-15, then please do so,
rather than using iso-8859-1". But if the message can't be encoded in
8859-15, there's absolutely no reason why Evolution would want to try,
since that can't possibly do the right thing.

> Evolution's second-guessing the user as to which character set to use
> becomes more problematic under the following scenario...

That sounds like a bug in the behavior of "insert text file". Might be
improved in 1.4 though.

-- Dan