1211993 - Open Sans WOFF file used on Mozilla sites triggers browser console error "downloadable font: kern: Too large subtable., table discarded"

Status: RESOLVED DUPLICATE of bug 1185685

(www.mozilla.org :: Pages & Content, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 0. Open Browser Console (ctrl shift J)

 1. Visit any of these sites...
     https://www.mozilla.org/en-US/firefox/
     https://www.mozilla.org/en-US/firefox/43.0a2/firstrun/
     https://www.mozilla.org/en-US/thunderbird/
   ...and shift-reload for good measure (in case you have resources cached).

 2. Look at your browser console.

ACTUAL RESULTS:
The following logging appears in browser console (categorized as "CSS Errors"):
============
downloadable font: kern: Too large subtable., table discarded (font-family: "Open Sans" style:normal weight:normal stretch:normal src index:1) source: https://mozorg.cdn.mozilla.net/media/fonts/OpenSans-Regular-webfont.2696e36f12c5.woff responsive-bundle.bc7f79e9daec.css:1:1575
downloadable font: kern: Too large subtable., table discarded (font-family: "Open Sans Light" style:normal weight:normal stretch:normal src index:1) source: https://mozorg.cdn.mozilla.net/media/fonts/OpenSans-Light-webfont.1c8075cacedb.woff
============

The errors are for the stylesheet at https://mozorg.cdn.mozilla.net/media/css/responsive-bundle.bc7f79e9daec.css

EXPECTED RESULTS: We should be using valid woff files that don't trigger browser console errors.

Comment 1

[Daniel Holbert [:dholbert]]

Looks like this error message means the kerning table has >= 10923 entries (65536/6), and some fonts are known to trigger this, according to this bit of C++ in ots_kern_parse:

> 98     const size_t kFormat0PairSize = 6;  // left, right, and value. 2 bytes each.
> 99     if (num_pairs > (65536 / kFormat0PairSize)) {
> 100       // Some fonts (e.g. calibri.ttf, pykes_peak_zero.ttf) have pairs >= 10923.
> 101       DROP_THIS_TABLE("Too large subtable.");
> 102       return true;

http://mxr.mozilla.org/mozilla-central/source/gfx/ots/src/kern.cc#96

jfkthame, do you have a feel for how extreme this table-size is? In particular:
 (1) does this mean the font is likely to have some bogus/broken data?
 (2) Whether or not the font is bogus, should we try to get the font changed so that we can actually honor its [smaller] kerning table?
 (3) Should we try to fix OTS to accept larger kerning table sizes?

Comment 2

[Craig Cook (:craigcook)]

This has been previously reported in bug 1185685 and others. 

The short version is that, yes, Open Sans seems to have a massive kerning table because it has a massive character set and I'm not sure what we can do about it. 

If there's anything we can do on the website end, we're very much open to ideas. Switching to woff2 might help (for browsers that support woff2) but perhaps not. Using a subsetted Open Sans would solve it, but then we have to jump through hoops for locales to make sure they get the right subset. We'll also soon be switching mozilla.org to Fira Sans, which I don't think has this kerning table issue, but that's at least a few months away (and doesn't help any other sites still using an unsubsetted Open Sans).

Otherwise it might be down to either fixing the font itself or changing the tolerances in Firefox.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #1)

>  (1) does this mean the font is likely to have some bogus/broken data?

Yes, the data in the font is bogus, according to the OpenType specification. The header of a Format 0 'kern' subtable has an unsigned 16-bit 'length' field, which means its maximum length is 64K; so there's a hard limit to the number of 6-byte entries it can contain.

What has presumably happened is that the font developer has created more than the permissible number of kern pairs, and the subtable length therefore exceeded 64K; but it's only a 16-bit field in the file format, so it must have been truncated. And that means any code that actually relies on the subtable length field is likely to misbehave -- perhaps harmlessly, perhaps not.

(In the case of Firefox, I believe the code in gfxHarfBuzzShaper.cpp would notice that it's invalid and give up trying to interpret it, so no real harm would be done even if OTS allowed it through, but it would serve no purpose; no kerning would actually happen. So the table would simply be wasting 100K+ of RAM.)

>  (2) Whether or not the font is bogus, should we try to get the font changed
> so that we can actually honor its [smaller] kerning table?

Reporting this upstream to the Open Sans developers (assuming the issue still exists in the latest version) would be good. They should either reduce the number of kerning pairs, or encode them in a different format -- using a GPOS 'kern' feature instead of the legacy 'kern' table would be a good step forward.

In the meantime, simply REMOVING the 'kern' table from the font would avoid the errors, as well as reducing the waste of bandwidth that results from having a large, bogus table in there.

>  (3) Should we try to fix OTS to accept larger kerning table sizes?

No; in this case OTS is clearly right to flag this as an error.


(In reply to Craig Cook (:craigcook) from comment #2)
> This has been previously reported in bug 1185685 and others. 
> 
> The short version is that, yes, Open Sans seems to have a massive kerning
> table because it has a massive character set and I'm not sure what we can do
> about it. 
> 
> If there's anything we can do on the website end, we're very much open to
> ideas. Switching to woff2 might help (for browsers that support woff2) but
> perhaps not. 

No, that won't help. This is about the content of the 'kern' table, not about how the font file is packaged/compressed for transmission.

There's nothing we can/should do for other sites using Open Sans, aside from reporting the bug upstream to the font developer. For mozilla.org, the workaround would be to strip the bad table out of the font files.

Comment 4

[Daniel Holbert [:dholbert]]

From some quick googling, I found this as an upstream home of Open Sans (since Google commissioned the font according to Wikipedia):
  https://www.google.com/fonts#UsePlace:use/Collection:Open+Sans

If I view that page and click "Choose", or if I just directly visit https://www.google.com/fonts, I see this same error in my error console:
===
downloadable font: kern: Too large subtable., table discarded (font-family: "Open Sans" style:normal weight:normal stretch:normal src index:2) source: https://fonts.gstatic.com/s/opensans/v13/PfybUH-csLekLIU-pU-o7w.woff2 css:7:12
===

So it looks like the latest version of the font is affected.  I'll reach out to the developer that's listed on that page, via https://twitter.com/SteveMatteson1, and see if I can find out where to report the issue.

From a Mozilla Web Properties perspective, it seems this is a dupe of bug 1185685 (and it'll go away when we switch to Fira as noted there) so I'll mark it as such.

Comment 5

[Craig Cook (:craigcook)]

(In reply to Jonathan Kew (:jfkthame) (PTO until Oct 12) from comment #3)

> There's nothing we can/should do for other sites using Open Sans, aside from
> reporting the bug upstream to the font developer. For mozilla.org, the
> workaround would be to strip the bad table out of the font files.

I only mentioned it because other Mozilla sites use the fonts hosted on our CDN. If we were to make code changes on mozilla.org so it would use subsetted versions for different locales, any other sites still using the CDN-hosted unsubsetted font would continue to have the same errors. My point being that the real fix is to fix the font, not the website.

Comment 6

[Daniel Holbert [:dholbert]]

(Reached out to the font developer, BTW: https://twitter.com/CodingExon/status/651490754779480064 )