Firefox changes font mid-line on some numerals

VERIFIED FIXED

Status

()

VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: jack.yan, Assigned: jfkthame)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre

When using certain fonts, Firefox will display one digit (so far I have encountered a 7 and an 8) in different font, which appears to resemble Century or a similar serif typeface.

The two typefaces this has happened with is Helvetica Bold and an in-house design.

As an aside, when I had bug 611209, one of the few characters that would display normally was the 8.

Reproducible: Always

Steps to Reproduce:
1. This tends to happen most at jyanet.com (note the 8 in 1987). It had happened at a page at sitelevel.com, but I cannot relocate it at the time of this report.
2.
3.
Actual Results:  
The 8 is in a different font.

Expected Results:  
There is nothing in the CSS or the page which would cause the change.

Unfortunately, I cannot provide a font file publicly for testing this bug. I realize in the back-up fonts specified in the stylesheet (which includes Helvetica and Arial), most people will not see the changing 8.
(Reporter)

Comment 1

8 years ago
Created attachment 513702 [details]
The digit 8 changes font mid-line in Firefox 4 Beta.

Font specified is Lucire 2, an in-house font. There is nothing in the 8 slot in the font file that could be causing this.
(Reporter)

Comment 2

8 years ago
Created attachment 513704 [details]
The digit 7 changes in Helvetica

This is from <http://www.sitelevel.com/query?query=%2522Stanley+Moss%2522&B3.x=41&B3.y=8&crid=0f04fc052287c7c2>, where the digit 7, meant to be in Helvetica, comes out in a serif font. Here, the 8 is fine.
(Assignee)

Comment 3

8 years ago
This is happening because the fonts are Type 1 (rather than TrueType/OpenType) fonts, causing us to use a different code path (there's no 'cmap' table to check character coverage), and the numeral in question happens to have glyph ID 31. This runs afoul of the check at http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxGDIFontList.cpp#380, which is not correct for these fonts. I'm guessing it should perhaps apply only to .fon fonts, but need to do some more testing before proposing a patch.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

8 years ago
Jonathan, I knew your insight would spot the issue straight away. In a nutshell, should we be regenerating our font to get the correct glyph ID? (Obviously, Linotype will have to do theirs.)
(Assignee)

Comment 5

8 years ago
No, it's our bug and we should fix it.

"Glyph IDs" are not really meaningful in PS Type 1 fonts, as the glyphs are referenced by name in the CharStrings dictionary. Windows is mapping them to numeric IDs for the sake of APIs like GetGlyphIndices, and I *think* it is simply numbering them in the (arbitrary) order in which the CharStrings entries occur. If you could arrange that the glyph at index 31 is a "placeholder" that you don't actually map to a character code, that would work around the problem - but you shouldn't have to do that. (And depending how you generate fonts, it might not be easy to control the ordering anyway.)

My current belief (subject to further testing) is that our code that treats ID 31 as an invalid glyph is only correct for old .fon fonts, not for .pfm/.pfb fonts, and should be applied more selectively. But I need to test this across a variety of fonts and Windows versions.
(Reporter)

Comment 6

8 years ago
I did have a go at re-generating, and now it’s the 1 that gets replaced by a variety of different fonts (not just the single egyptian one as before).

You’re right that it’s not that easy to put in a cmap, at least for a PostScript font. I’m going to play with the glyph mapping and see if I can improve the font in any case.
(Assignee)

Comment 7

8 years ago
This is a regression caused by bug 561304, which added the check for "glyph ID" 31 when using GetGlyphIndices to test character coverage of fonts in GDI. I did some more testing and confirmed that on WinXP, GetGlyphIndices returns 31 for missing glyphs with bitmap fonts (.fon), but does not do this for Type 1 (.pfm+.pfb) fonts; for these, it returns 0xFFFF, and 31 is a valid "glyph ID" (which appears to mean the sequential index of the glyph in the font's CharStrings dictionary).

(Incidentally, on Win7 I didn't see 31 being returned for missing glyphs at all - GetGlyphIndices seems to mark all missing glyphs with 0xFFFF, even for old bitmap fonts. So we could make the check for 31 conditional on the Windows version. But I don't think this is really necessary; it should be harmless.)
Blocks: 561304
Keywords: regression
(Assignee)

Comment 8

8 years ago
Created attachment 513972 [details] [diff] [review]
patch, don't reject glyph index 31 in Type 1 fonts
Assignee: nobody → jfkthame
Attachment #513972 - Flags: review?(jdaggett)
(Reporter)

Comment 9

8 years ago
Jonathan, FWIW, thank you for your attention to detail and understanding of typography.

Updated

8 years ago
Attachment #513972 - Flags: review?(jdaggett) → review+
(Assignee)

Comment 10

8 years ago
Comment on attachment 513972 [details] [diff] [review]
patch, don't reject glyph index 31 in Type 1 fonts

Requesting approval-2.0; this fixes a regression from 3.6 that affects Windows GDI users with "old" PostScript Type 1 fonts (i.e. not packaged as .otf). Those are not particularly common, I think, but we still shouldn't break them! The patch is very safe and has no effect at all on other platforms or font types.
Attachment #513972 - Flags: approval2.0?
Attachment #513972 - Flags: approval2.0? → approval2.0+
(Assignee)

Comment 11

8 years ago
http://hg.mozilla.org/mozilla-central/rev/c039f28137e5
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 12

8 years ago
Verified using Mozilla/5.0 (Windows NT 6.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 13

8 years ago
Looking good in 4 Beta 13 in Windows XP. :) Thank you!

Comment 14

8 years ago
WFM on:
Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
You need to log in before you can comment on or make changes to this bug.