185880 - ISO-8859-2 character coding not correct in mail composer

Status: RESOLVED INVALID

(MailNews Core :: Composition, defect)

Description

[Tristan Miller]

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:

Comment 1

[Tristan Miller]

Attachment: Screenshot showing described behaviour

Comment 2

[Mike Cowperthwaite]

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.

Comment 3

[Tristan Miller]

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.

Comment 4

[Mike Cowperthwaite]

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.

Comment 5

[Mike Cowperthwaite]

No response from reporter; =>Invalid
Tristan Miller, you may reopen this bug, but if you do so, address the issues 
raised in comment 4.

Comment 6

[Tristan Miller]

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 <[e-mail]>
To: [e-mail]

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

Comment 7

[Mike Cowperthwaite]

(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).