20.13 KB, image/png
272.42 KB, image/jpeg
2.03 KB, patch
|Details | Diff | Splinter Review|
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.
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.
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.
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
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.)
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.
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.
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.)
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)
Jonathan, FWIW, thank you for your attention to detail and understanding of typography.
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+
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Verified using Mozilla/5.0 (Windows NT 6.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12.
Status: RESOLVED → VERIFIED
Looking good in 4 Beta 13 in Windows XP. :) Thank you!
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.