Closed Bug 1269187 Opened 5 years ago Closed 5 years ago
firefox 44+ not using web font with Macintosh Unicode cmap (Platform ID = 0, Encoding ID = 3, Format = 4)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20160430030223 Steps to reproduce: Use a web font with a Macintosh Unicode cmap (Platform ID = 0, Encoding ID = 3, Format = 4). It works under firefox 43, breaks in firefox 44. This is obviously another case with ots https://lists.w3.org/Archives/Public/public-webfonts-wg/2016Jan/0000.html The sad thing is that there is no console message and ots-sanitize does not complain either. https://github.com/khaledhosny/ots/issues/106 https://github.com/khaledhosny/ots/issues/107 I only worked it out because one app does complain - and in my opinion, wrongly: https://github.com/nodebox/opentype.js/issues/185 Seriously, Platform ID = 0, Encoding ID = 3 is for most purposes the same as Platform ID = 0, Encoding ID = 3 , especially for largely english-only or european-languages-only usage. Actual results: It works under firefox 43, breaks in firefox 44. No console messages. Expected results: It works under firefox 43, breaks in firefox 44. No console messages.
Do you have a testcase, please?
Component: Untriaged → Graphics: Text
Product: Firefox → Core
Sorry, there was a typo in the initial report, it should read - note the 3,1 in the latter part: "Seriously, Platform ID = 0, Encoding ID = 3 is for most purposes the same as Platform ID = 3, Encoding ID = 1 , especially for largely english-only or european-languages-only usage." (In reply to Loic from comment #1) > Do you have a testcase, please? I do, but the files aren't mine to give away - I was giving a talk on the microsoft font validator and got it off another speaker who said an SVG-in-OT font has stopped working. A testcase isn't difficult to make - you can "break" a working Web font example by renaming the more common Platform ID = 3, Encoding ID = 1 (microsoft unicode) to Platform ID = 0, Encoding ID = 3 and see that it stops working. BTW, there is at least one font shipped in current Mac OS X which has Platform ID = 0, Encoding ID = 3 cmap only, and does not have Platform ID = 3, Encoding ID = 1 cmap's.
I would suggest just "break" a working web font example with ttx to make a testcase, by doing changing <cmap_format_4 platformID="3" platEncID="1" language="0"> to <cmap_format_4 platformID="0" platEncID="3" language="0"> (the reverse was how I changed the submitted example to work around the firefox bug). .
test.tgz - small test case, an html file + a ttf Just made this fresh. the font used is derived from https://github.com/Robmaister/SharpFont/blob/master/Source/Examples/Fonts/AlexBrush-Regular.ttf by stripping all the cmap's except the "Platform ID = 0, Encoding ID = 3, Format = 4" one. It works with firefox 43 and breaks with firefox 44, as I experienced with the other example which was not mine to share. I picked this font to create a new example, just because it is handy and has a distinct look. Nothing special. tested against: https://ftp.mozilla.org/pub/firefox/releases/43.0/linux-x86_64/en-GB/firefox-43.0.tar.bz2 https://ftp.mozilla.org/pub/firefox/releases/44.0/linux-x86_64/en-GB/firefox-44.0.tar.bz2
You can make the testcase working again by copying the original ( https://github.com/Robmaister/SharpFont/blob/master/Source/Examples/Fonts/AlexBrush-Regular.ttf ) over the mod'ed version with recent firefox'es. As I said, they differ only by having all the non "Platform ID = 0, Encoding ID = 3, Format = 4" cmap stripped off.
The testcase works in Firefox on Mac OS X, but fails on Windows. If you're on Linux, things probably changed as a result of the switch to a new font-list backend that shares more code (and behavior) with the Mac and Windows backends than the old version. That was enabled in FF44 by bug 1180560. AFAICS, the font isn't being rejected as such; but then Firefox is not finding a 'cmap' subtable to use, and so it ends up with an empty character map. This happens because the code in gfxFontUtils::FindPreferredSubtable looks like it's set up to accept (0, 3, 4) subtables on the Mac, but not on other platforms. It has been that way for a long time, though I'm not sure why; presumably when it was written, there was no expectation that these values would be used except by Apple, but that seems like a poor choice.
Status: UNCONFIRMED → NEW
Ever confirmed: true
That's a bit unfortunate. There are many professional font designers working on Mac OS X, and it is just stupid to reject fonts designed for/by Mac OS X users on other platforms. The creator of font with this issue which wasn't mine to share, works on Linux.
Yes, it is the acceptableFormat4() macro inside gfxFontUtils::FindPreferredSubtable , which is defined differently for mac OS X vs everything else now.
I guess this was originally coded as it is because Windows GDI will not load a font that lacks an MS-platform cmap subtable and only has a platform-0 one. But if we _do_ have such a font -- because we're on a platform (including Windows DWrite) that can load it, there's no reason why our cmap-reading code shouldn't use the table that's available. This won't change behavior for fonts that currently work, because their MS-platform subtable will still be preferred.
Attachment #8748212 - Flags: review?(VYV03354)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Attachment #8748212 - Flags: review?(VYV03354) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/988f42d740b6a94cd46ad9cc1ad6b30f6c8541e3 Bug 1269187 - Accept a Unicode-platform 'cmap' subtable if there's no MS-platform subtable in the font. r=emk
You need to log in before you can comment on or make changes to this bug.