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

NEW
Unassigned

Status

()

Core
Layout: Text
15 years ago
9 years ago

People

(Reporter: stinney, Unassigned)

Tracking

({intl})

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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?
(Reporter)

Comment 2

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

15 years ago
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.
Keywords: intl

Comment 4

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

Updated

14 years ago
Status: UNCONFIRMED → NEW
Depends on: 121540
Ever confirmed: true
Assignee: layout.fonts-and-text → nobody
QA Contact: ian → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.