219426 - Mozilla default ugly Unicode characters persists even when font has required characters.

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[stinney]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 2

[stinney]

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

Comment 3

[Jungshik Shin]

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.

Comment 4

[Greg K.]

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