240841 - Wrong display of special East-Asian characters

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[philippe (part-time)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316

Special East-Asian characters coded using html entities in the range #93**
display wrongly [numerics in circle, numerics between ()......]. This happens
independently of the encoding of the page. Sample page:
http://dev.l-c-n.com/Gecko/specialChar.php

This happens both in Mozilla1.7b and Firefox nightly builds. Every other browser
on Mac OS X (tested: Opera7.5pr4, Safari 1.2.1, IE5.23) and IE5.x on OS9
(japanese localisation) can display the characters correctly.


Reproducible: Always
Steps to Reproduce:
1.code an html doc with one of the characters mentioned
2.view page (see sample url)
3.

Actual Results:  
The browser displays the wrong characters. see the screenshot included in the
sample page.

Expected Results:  
The browser should display the correct charaters [numerics in circle, numerics
between (), numerics followed by a . (period), alpha-numerics between ()].

Comment 1

[Boris Zbarsky [:bzbarsky]]

Odd... I get the right rendering with a current Linux trunk build.  Is this
Mac-only?

Comment 2

[Greg K.]

Confirmed using Camino/2004041608. Whether encoded as decimal 9312, hex 2460 or
embedded directly as a real Unicode character, the Circled Digit One character
displays as an exclamation point on OS X.

Reassigning to Layout: Fonts and Text.

Comment 3

[Greg K.]

It does appear to work properly using Mozilla-Win/1.6, so this is probably Mac only.

Comment 4

[Jungshik Shin]

This is certainly Mac only. Let me take it for the now (I may have a Mac soon...)

Comment 5

[HARUNAGA Hirotoshi]

dup of Bug 155551?

Comment 6

[Jungshik Shin]

Philippe, can you switch fonts to Osaka (if what you use is Hirango(sp?)) and
see if the problem goes away? 

Comment 7

[Greg K.]

Attachment: XHTML testcase

This isn't just about Japanese fonts. As shown by this testcase, some fonts do
display the circled numbers correctly (TITUS Cyberbit Basic, Code2000, Arial
Unicode MS and Osaka), but Lucida Grande fails (though it does contain these
characters).

(Note also the poor spacing of the characters using TITUS Cyberbit Basic. This
is also evident in bug 174506. See bug 208037 for another Mozilla/TITUS
Cyberbit Basic problem.)

Comment 8

[philippe (part-time)]

(In reply to comment #6)
> Philippe, can you switch fonts to Osaka (if what you use is Hirango(sp?)) and
> see if the problem goes away? 
> 

I've update my test file (http://dev.l-c-n.com/Gecko/specialChar.php), linking
two more test, one using Osaka[1] (works OK), one using Hiragino [2] (doesn't
work). The original test file doesn't mention any font-family, except for
'sans-serif', and -for me- falls back on 'Optima', my default font in Gecko
browsers.
[1] http://dev.l-c-n.com/Gecko/specialChar_Osaka.php
[2] http://dev.l-c-n.com/Gecko/specialChar_Hiragino.php

Comment 9

[Jungshik Shin]

It seems that this bug is closely related with (if not a dupe of) bug 120401.
Judging from my brief experiment, Mozilla has little trouble with 'dfont' (data
fork font) but has trouble with otf (open type font) and ttf (Windows truetype
font : I'm using the terminology used by MacOS font info.). As noted in bug
120401, Mozilla is ignorant of the true character coverage of those two types of
fonts. 

Circled/parenthesized letters/numbers are not covered by JIS X 0201 and JIS X
0208 so that they can't be represented in Shift_JIS and EUC-JP. Therefore,
Mozilla's character coverage evaluation based on the mapping between 'legacy
character sets' and languages (Japanese -> Shift_JIS?) fails to recognize that
'Hiragino' has glyphs for circled/parenthesized letters/numbers. 

This explanation has some missing links (for instance, it can't explain why
circled/parenthesized letters are rendered with '!', '#', etc)

Comment 10

[Jungshik Shin]

At least, this bug depends on bug 120401. We'll see whether this bug is fixed
completely by an upcoming patch for that bug. 

Comment 11

[Jungshik Shin]

*** Bug 155551 has been marked as a duplicate of this bug. ***

Comment 12

[Asaf Romano (gone)]

This is fixed with the *last* patch for bug 120401 (this was a result of the
quickdraw converter).

Comment 13

[Asaf Romano (gone)]

...it is not fixed anymore, becaue we restord the quickdraw converter (see last
comments in bug 120401)... but it will be fixed in bug 254585.

Comment 14

[philippe (part-time)]

Since the landing of Cairo (Bug 328116) and the use of ATSUI this now works correctly.