158835 - Quirky Unicode font rendering

Status: RESOLVED INVALID

(Core :: Internationalization, defect)

Description

[Niklas Dougherty]

Mozilla has major problems displaying some segments of Unicode, and also makes
quirky substitutions for perfectly normal characters within certain character
sets. This applies to all Mozilla versions, up to 1.1b.

Consider the following screen dump (for simplicity) of a test page on runes:

Correct behavior (Chimera): http://homepage.mac.com/nikd/test/chimera.png

This is how it should be rendered, using ATSUI. Now, consider how Mozilla
renders the same thing, with three different fonts:

Quirky behavior 1: http://homepage.mac.com/nikd/test/code2000.png
Quirky behavior 2: http://homepage.mac.com/nikd/test/cyberbit.png
Quirky behavior 3: http://homepage.mac.com/nikd/test/caslon.png

The first example shows how the baseline is shifted down 0.5 em or so (it
varies; sometimes it goes down half a page... if it shows at all). All examples
show that wrapping doesn't work as it should; the text overlaps with the text on
the right side.

All examples also show the ISO Latin 1 characters eth and thorn being rendered
differently (smaller, unlegible, fixed width) than the surrounding ISO Latin 1
characters (here with Lucida Grande, the default system font, which of course
has these characters), despite what has been defined in the style sheet. This is
the typical "MacRoman behavior" Mac users had to endure in the "good old days".

Why is Mozilla defaulting to MacRoman behavior on a UTF-8 page, and why is it
unable to patch it so that eth and thorn (and so on) are rendered correctly? In
general, why doesn't Mozilla use ATSUI rather than the legacy QuickDraw? It
makes no sense at all.

Relevant Unicode fonts (Windows TrueType):

Code2000: http://home.att.net/~jameskass/
Titus CyberBit: http://titus.fkidg1.uni-frankfurt.de/unicode/tituut.asp
Caslon: http://bibliofile.mc.duke.edu/gww/fonts/Unicode.html (CASLR___.TTF)

Comment 1

[Jo Hermans]

ATSUI : see bug 121540

Comment 2

[Greg K.]

[e-mail], are those runes Plane 1 characters? If so, that's covered by bug
135219. The unnecessary glyph substitution problem is bug 148361.

(If those two bugs cover what you're reporting here, let us know so we can close
this bug.)

Yes, many font problems on Mac are solved by moving to ATSUI with the patch on
bug 121540. They'll get back to it one of these days. In the meantime, be sure
to add your vote to it (using the voting function; be sure not to add
evangelical or "please do this soon" comments).

Comment 3

[Niklas Dougherty]

Greg, it seems to be the same faulty glyph substitution as per bug 148361. This
must be terrible for the Icelandic Mac owners (if there is such a breed), since
they still use eth and thorn...

However, this doesn't account for the the main bug reported here, namely the
baseline shift and the erroneous wrapping (of correct glyphs). Runes are not
higher plane characters. They are in the block 16A0-16FF in the BMP of Unicode.
The same bug can be reproduced with other weird alphabets.

Of course, ATSUI would take care of plane 1 rendering as well. At least native
Cocoa apps handle plane 1 correctly.

Comment 4

[Roy Yokoyama]

->nhotta 

Comment 5

[Yuying Long]

Confirm has overlapping problem in testpage:
http://homepage.mac.com/nikd/test/test.html
by adding Titus CyberBit ttf font.

Comment 6

[nhottanscp]

I think there was a regression in Mac font.
Yuying, could you try recent trunk?

Comment 7

[Yuying Long]

Yes, the test page is displayed fine on 09-06 trunk build / Mac 10.1.5.

Comment 8

[nhottanscp]

mark as wfm

Comment 9

[Yuying Long]

Verified.

Comment 10

[Niklas Dougherty]

Attachment: WFY? DNWFM.

Yeah, right...

Comment 11

[Niklas Dougherty]

I don't know what you guys define as "fine", but this bug still exists and it
looks as bad as it possibly can.

Reopening, per attachment 1 [details] [diff] [review], 2002-09-06-08 trunk. MOX 10.1.5.

Put a WONT or whatever, but don't lie to my face that this bug is fixed. IT AIN'T!

Comment 12

[Yuying Long]

Attachment: screen shot on 09-06 Netscape trunk build

It doesn't display fine on my Mac 10.1.5 with 09-06 trunk build.

Is there any difference between mozilla and Netscape build with this area?

Comment 13

[Niklas Dougherty]

It does work with Titus Cyberbit and Caslon, but not with the more important (as
in more widespread, prettier, bigger and most general Unicode font available)
Code2000. Get it at http://home.att.net/~jameskass/CODE2000.ZIP and see for
yourself.

Comment 14

[Alan{H}]

I am attaching screenshots of a Unicode character ([U+2699] GEAR) failing on OS X 10.6.2 in Firefox. This shows up for me in FF3.5 and 3.6b5, both.

Reference (Safari 4):
http://emberapp.com/alanhogan/images/safari

Firefox 3.6b5 (ignore gradient, shadow differences):
http://emberapp.com/alanhogan/images/firefox