User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 In Tools/Options/Content/Default font, my font "Arial Unicode MS" is not displayed in the font list. I managed to debug it as far as to get that nsIFontEnumerator.EnumerateFonts("","",{}) doesn't list the font. Other programs, including IE, can display the font just fine. In the font list I obtained manually from Win32.GDI.EnumFontFamiliesExW() the font is provided twice, both as "Arial Unicode MS" and "@Arial Unicode MS", but neither entry gets to Firefox. Reproducible: Always Steps to Reproduce: 1.Install Arial Unicode MS, reboot not necessary 2.In Firefox, open Tools/Options/Content 3.In the list of fonts, the font is not displayed. Expected Results: Expected "Arial Unicode MS" entry in the font list I wish there could be ways to debug nsIFontEnumerator to understand why it ignores the font

I've tried to investigate further and that's what I found. The reason why the font is ignored lies in gfx/thebes/src/gfxFontUtils.cpp line 298: // some buggy fonts on Mac OS report lang = English (e.g. Arial Narrow Bold, v. 1.1 (Tiger)) #if defined(XP_WIN) NS_ENSURE_TRUE(ReadShortAt(aBuf, OffsetLanguage) == 0, NS_ERROR_GFX_CMAP_MALFORMED); #endif where the font "Arial Unicode MS" has OffsetLanguage 1 . I've read the TTF spec from http://www.microsoft.com/typography/tt/ttf_spec/ttch02.doc , page 38 line 17, which says this: USHORT format Format number is set to 4. USHORT length Length in bytes. USHORT version Version number (starts at 0). USHORT segCountX2 2 x segCount. I.e. according to this document it's version number, not a language. I therefore have question about validity of the code above, -- or the specification above. It seems strange that the comment in the code says about problems on Mac OS, whereas my problem is manifested on Win32, but also XP_WIN symbol gets defined in my build. Also, I've tried to comment out the line, and the font gets displayed just fine. I can produce a simple patch that removes the whole code snipped totally, but I'd expect that's be a naive approach. I checked history of the file, and the first version I could get was dated Dec 28 2007, which also shows... Well anyways I'd like to get my font displayed and I'd like to get the bug fixed, if there is one, so tell me if I can do anything else here.

After more testing, I believe the patch below is actually is what needs to be done, and what was meant by the author of the comment about the Mac OS. --- gfxFontUtils.cpp.0 2009-11-02 22:42:52.000000000 +0100 +++ gfxFontUtils.cpp 2009-12-03 18:12:12.000000000 +0100 @@ -294,7 +294,7 @@ NS_ENSURE_TRUE(tablelen > 16, NS_ERROR_GFX_CMAP_MALFORMED); // some buggy fonts on Mac OS report lang = English (e.g. Arial Narrow Bold, v. 1.1 (Tiger)) -#if defined(XP_WIN) +#if defined(XP_MACOSX) NS_ENSURE_TRUE(ReadShortAt(aBuf, OffsetLanguage) == 0, NS_ERROR_GFX_CMAP_MALFORMED); #endif

This problem is reproducable on my WinXP machine as well. I've confirmed that the problem does NOT appear on FF3.0.14 but does on FF3.5.5 and FF3.5.6.

(In reply to comment #1) > where the font "Arial Unicode MS" has OffsetLanguage 1 . I've read the TTF spec > from http://www.microsoft.com/typography/tt/ttf_spec/ttch02.doc , page 38 line > 17, which says this: > > USHORT format Format number is set to 4. > USHORT length Length in bytes. > USHORT version Version number (starts at 0). > USHORT segCountX2 2 x segCount. > > I.e. according to this document it's version number, not a language. If it were indeed a version number, then "version 1" seems to be entirely undocumented, so attempting to interpret it with code written for "version 0" would be risky..... However, note that this is an obsolete document. The current OpenType spec does label this field as "language", and explicitly says that "This field must be set to zero for all cmap subtables whose platform IDs are other than Macintosh (platform ID 1)." So the Arial Unicode MS font is apparently out of spec in this regard, although it's probably a harmless error. (In reply to comment #2) > After more testing, I believe the patch below is actually > is what needs to be done, and what was meant by the author > of the comment about the Mac OS. No, I think the code was correct for the original intent: author meant to skip the check on Mac OS, in order to allow such fonts to be used there even though they're not strictly correct. The check was left in place on Windows because we didn't expect to run into such fonts there. However, given the case you've reported, we should probably just skip this check altogether, and assume that incorrect values in that field will not actually cause any harm. Or maybe we should check for lang = 0 or 1 (which for Mac-platform tables would mean "English" - setting this is likely to be the root of the error in font construction), but still reject other "crazy" values.

Possible patch attached; I have not tested this on Windows yet, but AFAICS it should resolve the issue.

Is this an issue with a specific version of Arial Unicode MS?

Comment on attachment 420007 [details] [diff] [review] proposed patch, allow language = 0 or 1 Yeah, makes sense to just accept 0 or 1 and return an error for anything else.

Patching to "==0 or ==1" makes sense to me too. As to the font version, the font file (can be downloaded for free from microsoft site), doesn't seem to be changed for the last six years.

The previous comment about font version was interesting. This problem does not happen on all machines with Arial Unicode MS in our shop. It turned out that the ones with the problem were font version 0.86 and the ones that worked as expected were font version 1.01. Version 1.01 is about 6 years old and the 0.86 version is about 9 years old. There is an interesting history of Arial Unicode MS on wikipedia at http://en.wikipedia.org/wiki/Arial_Unicode_MS Note that Arial Unicode MS is no longer freely downloadable and hasn't been for about 4 years. However its pretty ubiquitous because of its distribution with so many Microsoft products. This font is particularly useful on workstations that display documents in many languages, e.g. at a library or publishing house. The character glyphs are pretty decent quality compared to some other generic unicode fonts that are free.

quote: "However, note that this is an obsolete document. The current OpenType spec does label this field as "language", and explicitly says that "This field must be set to zero for all cmap subtables whose platform IDs are other than Macintosh (platform ID 1)." So the Arial Unicode MS font is apparently out of spec in this regard, although it's probably a harmless error." It seems that, Arial Unicode is not a OpenType font, but a True Type font. In a standard windows font selection dialog, each font entry displayed together with an icon, "TT" for TrueType and "O" for OpenType. So technically speaking the font is not out of spec - the OpenType spec doesn't apply, which also means that the field in question is version, not language.

(In reply to comment #10) > quote: "However, note that this is an obsolete document. The current OpenType > spec does label this field as "language", and explicitly says that "This field > must be set to zero for all cmap subtables whose platform IDs are other than > Macintosh (platform ID 1)." So the Arial Unicode MS font is apparently out of > spec in this regard, although it's probably a harmless error." > > > It seems that, Arial Unicode is not a OpenType font, but a True Type font. In a > standard windows font selection dialog, each font entry displayed together with > an icon, "TT" for TrueType and "O" for OpenType. So technically speaking the > font is not out of spec - the OpenType spec doesn't apply, which also means > that the field in question is version, not language. No, this is a (very common) misunderstanding. The term "OpenType" is heavily overloaded, and there is lots of confusion surrounding what it means to be an OpenType font. Two points that are relevant here: first, TrueType fonts are simply a (valid) subset of OpenType, and the old TrueType spec *is* obsoleted by the current OpenType spec. Note that the Microsoft typography site offers it "for historical purposes", not as a current specification. And second, regarding the file icons used by Windows (and indeed the "Font type" shown in the Fonts folder details view): despite appearances, these do NOT serve to differentiate "TrueType" and "OpenType" fonts. AFAIK, the simple rule is that the "O" icon appears if the font has a digital signature; the "TT" icon appears otherwise. It's true that the DSIG table appeared at some stage as part of the re-branding as "OpenType", but its absence does not make a font any less "OpenType" - it is an optional table. The Windows UI is extremely misleading here - or, if you prefer, Windows is using its own unique definition of "OpenType" versus "TrueType". In any case, even under the old v1.66 TrueType spec, "version 1" of the format 4 cmap table was undocumented, so the most reasonable default thing to do with it would have been to reject it as unknown. But in this particular case, as we think we understand what was meant, it seems safe to simply ignore that field.

Thanks for a great explanation, that clears the issue to me - please commit!

Pushed: http://hg.mozilla.org/mozilla-central/rev/a80ceb157886