Quirky Unicode font rendering

REOPENED
Assigned to

Status

()

--
major
REOPENED
17 years ago
9 years ago

People

(Reporter: nikd, Assigned: nhottanscp)

Tracking

({intl})

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
ATSUI : see bug 121540

Comment 2

17 years ago
nikd@mac.com, 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).
(Reporter)

Comment 3

17 years ago
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.

Updated

17 years ago
Keywords: intl

Updated

17 years ago
QA Contact: ruixu → ylong

Updated

17 years ago
Blocks: 158590

Comment 4

17 years ago
->nhotta 
Assignee: yokoyama → nhotta

Comment 5

17 years ago
Confirm has overlapping problem in testpage:
http://homepage.mac.com/nikd/test/test.html
by adding Titus CyberBit ttf font.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 6

16 years ago
I think there was a regression in Mac font.
Yuying, could you try recent trunk?
Status: NEW → ASSIGNED

Comment 7

16 years ago
Yes, the test page is displayed fine on 09-06 trunk build / Mac 10.1.5.
(Assignee)

Comment 8

16 years ago
mark as wfm
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 9

16 years ago
Verified.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 10

16 years ago
Created attachment 98204 [details]
WFY? DNWFM.

Yeah, right...
(Reporter)

Comment 11

16 years ago
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!
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

Comment 12

16 years ago
Created attachment 98222 [details]
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?
(Reporter)

Comment 13

16 years ago
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.
QA Contact: amyy → i18n

Comment 14

9 years ago
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
You need to log in before you can comment on or make changes to this bug.