180914 - Mozilla doesn't render Latin-1 and Latin Extended A/B chars using specified font

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX: Mac, defect, P2)

Description

[Niklas Dougherty]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021031
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021031

When defining a stylesheet with the font stheiti (or stkeiti, stfangsong,
stsong, other), Mozilla doesn't use this to render all content on a page.
Specifically, Mozilla ignores the stylesheet definition for all Latin Extended A
and B glyphs (Pinyin uses these), even though these are defined for the said fonts.

This is not a TEC problem (bug 111728), according to Henri Sivonen, so we're
filing this as a new bug. It is irrelevant what encoding is used (GB 18030,
UTF-16, UTF-8).


Reproducible: Always

Steps to Reproduce:
1. Load testcase
2. Load screen dumps
3. Compare

Actual Results:  
Mozilla is uselss rendering Pinyin

Expected Results:  
Mozilla should render Pinyin flawlessly

Comment 1

[Niklas Dougherty]

Attachment: Pinyin testcase

This doesn't render as intended.

Comment 2

[Niklas Dougherty]

Attachment: Screen dump of Mozilla's rendering

This is how it shouldn't be.

Comment 3

[Niklas Dougherty]

Attachment: Screendump of Omniweb's rendering

This is how a Mac OS X app renders this. This is how it should be.

Comment 4

[Niklas Dougherty]

The substituted font is Lucida Grande.

Comment 5

[Boris Zbarsky [:bzbarsky]]

There's a component for this.  ;)

Comment 6

[Niklas Dougherty]

Note that ביםףתאטלעשֱֹֽ׃�ְָּׂ� are in Latin-1, a pretty common encoding.

Comment 7

[Niklas Dougherty]

Btw, those Latin-1 chars caused Universal Auto-Detect to bring on Traditional
Chinese.

Comment 8

[Niklas Dougherty]

Similar weird rendering at http://www.i18nguy.com/unicode-example.html

Look at René Magritte, Céline Dion, Søren Kierkegård, François Truffaut, Rudi
Völler for a starter with extremely common Latin-1 glyphs. The more "unusual"
Latin glyphs (Extended A, Extended B, Latin Additional) look like they always
have in Mozilla, although the fonts defined in the style sheet have the relevant
glyphs. Some Greek and Cyrillic samples also look ****, while the Asian and
Semitic samples render perfectly (minus Latinized Vietnamese, which uses Latin
Ext. A and B heavily).

Comment 9

[Carine Held]

Reproduced on Mac OSX, 12/16 Trunk build.

Comment 10

[Greg K.]

Dup of bug 157272?

Comment 11

[Jungshik Shin]

see bug 120401 and bugs refered to therein. 

Comment 12

[Jungshik Shin]

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

Comment 13

[Asaf Romano (gone)]

Can someone check the status of this bug with latest 1.8 build? last checkin
from bug 120401 should change something...

Comment 14

[Jungshik Shin]

The patch for bug 120401 didn't fix this bug. Hmm... I need to run mozilla under
gdb and see what's really going on...

Taking this for now.

Comment 15

[Jungshik Shin]

What I think is happening is:

1. QuickDraw routine doesn't recognize that a Chinese font covers Latin-1 and
extended Latin for Pinyin because they're not a part of Mac Simplified Chinese. 
2. ATSUI fallback is invoked. However, ATSUI doesn't respect the current
selected font  and just picks a font that happens to cover Latin-1 and extended
Latin

We have to figure out a way to let ATSUI APIs know the current font and use it.
Alternatively, we have to find a way to use ATSUI from the beginning without
perf. hit.

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Are bug 208037, bug 219426, bug 223823, bug 148361, or bug 158560 duplicates of
this one or just similar-sounding?  (This seems to be the only one with a
developer postulating the underlying issue)

Comment 17

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 18

[Simon Montagu :smontagu]

WORKSFORME in current trunk