261557 - iso-8859-15 formatted message displayed incorrectly

Status: RESOLVED INVALID

(MailNews Core :: Internationalization, defect)

Description

[Olaf]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803

In the message I have this header part:

Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Type: text/plain; charset="iso-8859-15"
MIME-Version: 1.0

The character … is displayed as �. Switching message view manually from
iso-8859-15 to iso-8859-1 as a workaround works.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Cowperthwaite]

If changing the encoding to 8859-1 makes it display correctly, that implies to 
me that the message is incorrectly encoded, not that it is incorrectly 
displayed.

I can't tell precisely what characters you're referring to, since you pasted 
them in as UTF-8.  The first one displays as an ellipsis (...), the second 
displays as the "unknown character" glyph, a small open box.

As it happens, the ellipsis character is not part of either character set.  The 
Unicode representation of the ellipsis is 0x2026, which doesn't fit in the 8-bit 
subset that is 8859-1.  Microsoft put the ellipsis into Windows-1252, in one of 
the open positions left in the 8859-1 spec (0x85); lots of mail that gets sent 
encoded as 8859-1 has characters that properly only belong in the 1252 character 
set, but since most fonts that support 8859-1 have the 1252 extension 
characters, those end up getting displayed.

I guess that what is happening here is the 8859-15 decoder is more stringent 
about allowing only characters that belong in the set.

See <http://www.cs.tut.fi/~jkorpela/latin9.html>.

Comment 2

[Simon Montagu :smontagu]

(In reply to comment #1)
> If changing the encoding to 8859-1 makes it display correctly, that implies to 
> me that the message is incorrectly encoded, not that it is incorrectly 
> displayed.

Agreed
 
> I guess that what is happening here is the 8859-15 decoder is more stringent 
> about allowing only characters that belong in the set.

You are correct.

If it's true that the original message includes an ellipsis character encoded as
0x85, then this bug is INVALID.

Comment 3

[Mike Cowperthwaite]

No response from reporter; =>Invalid