I've been seeing Chrome and Firefox rejecting a lot of WOFF2 files lately, for OTS (OpenType Sanitiser) failures. But this is confusing, because the browser will fall back to the WOFF generated from the same source font, which sails through without a problem.
I have a test page
using Bungee Shade from Google Fonts if you want to see this in action. In the case of Bungee, the sanitiser is removing one of the cmap
subformat tables. Open Sans also fails this test for having a too-big kern
table. Note that in both of these cases, OTS still reports the fonts as "passing" since the fonts are still valid after the modifications.
If I run the TTFs through OTS before generating the WOFFs, then everything works fine.
The original WOFF2 works fine in Edge on Windows 10, which doesn't use OTS.
Firefox shows these errors:
Anybody here know why WOFF2 gets this strict treatment but the same font in WOFF format works?
You should report this against Firefox/Chrome. it is also possible to work around this limitation in the font.
Many thanks to @Khaled Hosny and Myles Maxfield of the Safari team for helping me figure this out!!
So padding to glyphs to 4 bytes is a good workaround in this cases, but a conforming implementation should accept the font regardless of the padding used.