User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 As shipped, Mozilla handles many Unicode characters very poorly. These include subscript numerals and the IPA eng-character, both of which I would like to use. I created a modified version of Thryomanes Regular, adding the missing subscripts, and Safari displays this beautifully. Mozilla ignores the fact that the selected font has the Unicode characters requested and sticks to the fallback characters. Reproducible: Always Steps to Reproduce: 1.Download the modified Thryomanes Regular font from http://psd.museum.upenn.edu/test-utf8.htm. 2. Install the font and ensure that Mozilla can use it. 3. Look at http://psd.museum.upenn.edu/test-utf8.htm again. Actual Results: Bad character rendering (excessive space around characters; ugly characters selected) persists. Expected Results: Mozilla should have selected the displayed characters from the current font.

Are you sure the modified font is modified correctly? (I think TrueType fonts have multiple mappings of encodings to glyphs (see bug 172771 comment 5 and bug 172771 comment 7) -- it could be that the font API safari uses the cmap's in the font in different priority, or something like that. But that doesn't really make sense...) Also, are the "fallback" characters you refer to glyphs in another font, or synthesized glyphs? Did you quit Mozilla and restart after modifying the font?

I checked the FontLab export options and 'Use Unicode indexes as base for TrueType encoding' and 'Do not reencode first 256 characters' are set to true. The codepage picklist is grayed out. On the question of fallback characters, I confess I do not understand the internals of Moz's font handling. Since Netscape 4, my attempts to get the browser to display subscript digits (i.e., U+2080 and following) have always resulted in small but varied size characters with excessive spacing around them; I don't know if these come from another font (my assumption) or if there is some other mechanism at work. If I can fix this by making a change in the font I'll be happy; what I can't do right now is put the font on my website and ask people to use Mozilla with it--I'd really like to be able to push Mozilla. And, yes, I have tried after quitting Mozilla. Steve

Ok. I'll download the font and see what its cmap tables look like. It's possible that the Apple Unicode cmap in your font doesn't map your new characters to glyphs while the Microsoft Unicode cmap in the font map them correctly (or the other way around). If Mozilla-Mac uses one mapping table that doesn't map new characters to glyphs while Safaris uses the other that does (or combines two0, what you observed can be explained. I'm not sure what Fontlab means by 'Do not reencode first 256 characters', but it appears suspicious.

Mozilla's Unicode rendering will probably not improve much until bug 121540 is revisited.