If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

firefox 44+ not using web font with Macintosh Unicode cmap (Platform ID = 0, Encoding ID = 3, Format = 4)

RESOLVED FIXED in Firefox 49

Status

()

Core
Graphics: Text
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: Hin-Tak Leung, Assigned: jfkthame)

Tracking

46 Branch
mozilla49
Points:
---

Firefox Tracking Flags

(firefox49 fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

a year ago
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.

Comment 1

a year ago
Do you have a testcase, please?
Component: Untriaged → Graphics: Text
Flags: needinfo?(htl10)
Product: Firefox → Core
(Reporter)

Comment 2

a year ago
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.
(Reporter)

Comment 3

a year ago
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).

.
Flags: needinfo?(htl10)
(Reporter)

Comment 4

a year ago
Created attachment 8747685 [details]
test.tgz - small test case, an html file + a ttf

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
(Reporter)

Comment 5

a year ago
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.
(Assignee)

Comment 6

a year ago
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.
Blocks: 1180560
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 7

a year ago
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.
(Reporter)

Comment 8

a year ago
Yes, it is the acceptableFormat4() macro inside gfxFontUtils::FindPreferredSubtable , which is defined differently for mac OS X vs everything else now.
(Assignee)

Comment 9

a year ago
Created attachment 8748212 [details] [diff] [review]
Accept a Unicode-platform 'cmap' subtable if there's no MS-platform subtable in the font

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)

Updated

a year ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Attachment #8748212 - Flags: review?(VYV03354) → review+
(Assignee)

Comment 10

a year ago
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

Comment 11

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/988f42d740b6
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.