Closed
Bug 158835
Opened 22 years ago
Closed 4 years ago
Quirky Unicode font rendering
Categories
(Core :: Internationalization, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: nikd, Assigned: nhottanscp)
References
()
Details
(Keywords: intl)
Attachments
(2 files)
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•22 years ago
|
||
ATSUI : see bug 121540
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•22 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.
Comment 5•22 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•22 years ago
|
||
I think there was a regression in Mac font.
Yuying, could you try recent trunk?
Status: NEW → ASSIGNED
Comment 7•22 years ago
|
||
Yes, the test page is displayed fine on 09-06 trunk build / Mac 10.1.5.
Assignee | ||
Comment 8•22 years ago
|
||
mark as wfm
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 10•22 years ago
|
||
Yeah, right...
Reporter | ||
Comment 11•22 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•22 years ago
|
||
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•22 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.
Updated•15 years ago
|
QA Contact: amyy → i18n
Comment 14•15 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
Updated•4 years ago
|
Status: REOPENED → RESOLVED
Closed: 22 years ago → 4 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•