User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 When composing an e-mail or newsgroup message, changing the default character coding from ISO-8859-1 to ISO-8859-2 will select the correct font size and style as defined in the Preferences menu, but does not actually change the character coding. See the screenshot I have uploaded. In this case, I set in the Preferences menu that Central European (ISO-8859-2) text is to be displayed with the Lucida Sans iso8859-2 font size 32, which is indeed installed on my system. (See the Gnome character map window, which is set to display the characters of this font.) In the e-mail composer window, I select ISO-8859-2 as the character encoding. The font changes to Lucida Sans size 32, but all the glyphs appear as they do in ISO-8859-1. The three characters I have typed in the window appear as an O with tilde, an O with slash, and an Icelandic thorn. However, these characters are supposed to appear as O with long umlaut, R with hachek, and T with cedilla in ISO-8859-2. (Again, see the Gnome character map.) Reproducible: Always Steps to Reproduce:
Tristan Miller, is this bug still a problem for you, with current builds of Mozilla or Thunderbird? There have been substantial improvements in this area since 1.3.
I am now using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804. The behaviour described in this report can still be duplicated.
In your screenshot, the characters that appear in the character map's "Text to copy" field are the same as those in the compose window. Why do you expect them to be different in the compose window? When you paste the characters in, Mozilla is not performing a simple numerical byte-paste; it's taking the actual characters and translating them to the Unicode equivalents, while in the editor. (I don't know how Linux/Gnome does it, but in Windows the characters in the paste buffer are in Unicode already.) The 8859-2 (or whatever) encoding doesn't take place until the message is being composed for sending (or saving). I believe this bug is invalid.
No response from reporter; =>Invalid Tristan Miller, you may reopen this bug, but if you do so, address the issues raised in comment 4.
Mike, I did indeed respond to your comment #4 above, but for some reason the e-mail gateway didn't process my message. Here it is again, this time pasted into the web interface: ---------- Forwarded Message ---------- Subject: Re: [Bug 185880] ISO-8859-2 character coding not correct in mail composer Date: Wednesday 25 August 2004 16:04 From: Tristan Miller <firstname.lastname@example.org> To: email@example.com Greetings. On Tuesday 24 August 2004 14:31, you wrote: > In your screenshot, the characters that appear in the character > map's "Text to copy" field are the same as those in the compose window. > Why do you expect them to be different in the compose window? Because the fact that the option to change the character set is in the "View" menu leads the user to believe that the editor is not, in fact, a Unicode editor, and that typing or pasting characters therein does result in a numerical byte-paste. > The 8859-2 (or whatever) encoding doesn't take > place until the message is being composed for sending (or saving). > > I believe this bug is invalid. Now that I am aware of the behaviour, I agree this bug as originally interpreted is invalid. However, a problem remains; namely, the misleading positioning of the the character set encoding in the View menu. Since changing the encoding in the composer will never affect how the message is actually *view*ed therein, I propose this command be moved to another menu, such as "Options", and perhaps explicitly renamed to "Set character encoding". This mirrors the rather sensible (IMHO) behaviour of KMail and KNode. Regards, Tristan
(In reply to comment #6) > Now that I am aware of the behaviour, I agree this bug as originally > interpreted is invalid. Then you should have left it marked as such. Please do not repurpose bugs, at least not without some consensus. > However, a problem remains; namely, the > misleading positioning of the the character set encoding in the View menu. You'll be pleased to know that this problem has just been fixed -- bug 227265 (and bug 92499 for Seamonkey).