Closed Bug 158835 Opened 22 years ago Closed 4 years ago

Quirky Unicode font rendering

Categories

(Core :: Internationalization, defect)

PowerPC
macOS
defect
Not set
major

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)
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).
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.
Keywords: intl
QA Contact: ruixu → ylong
Blocks: unicode
->nhotta
Assignee: yokoyama → nhotta
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
I think there was a regression in Mac font. Yuying, could you try recent trunk?
Status: NEW → ASSIGNED
Yes, the test page is displayed fine on 09-06 trunk build / Mac 10.1.5.
mark as wfm
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Verified.
Status: RESOLVED → VERIFIED
Attached image WFY? DNWFM. (deleted) —
Yeah, right...
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 → ---
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?
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
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
Status: REOPENED → RESOLVED
Closed: 22 years ago4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: