downloadable font: post: Bad number of glyphs: 228
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: andyroddam.taopix, Unassigned)
Details
Attachments
(1 file)
|
25.26 KB,
font/ttf
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Steps to reproduce:
(1) Using css @font-face rule to load font into DOM and display target span using the font 'five cents'
Actual results:
The font is rendered using a system fall back font and the following messages are displayed in the console.
Expected results:
The target span should display the text using the font 'five-cents'
downloadable font: post: Bad number of glyphs: 228 (font-family: "five cents" ...)
downloadable font: post: Failed to parse table (font-family: "five cents" ...)
downloadable font: rejected by sanitizer (font-family: "tpxfive cents" ...)
|
||
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•5 years ago
|
||
As reported in the web console error messages, the font is invalid. The 'post' table claims that it has 228 glyphs, but the font in fact (as recorded in the 'maxp' table) only has 149 glyphs. The OpenType spec says these numbers should match.
(I notice the 'name' table is also invalid, because the PostScript name (name ID 6) includes a space, which is not allowed according to the OpenType spec.)
So this is a broken font, perhaps the result of attempting to subset a font using tools that fail to ensure it complies with the spec.
I'd guess it probably doesn't work in Chrome, either.
|
Reporter | |
Comment 3•5 years ago
|
||
That is correct, it does not work in Chrome either. However, this font does work in Safari.
You are correct in stating that there are several inconsistencies within the font meta data. I am aware of this. The reason that I have logged this bug is that Firefox does in fact render many fonts that have many inconsistencies within their font meta data.
It would seem that in some cases the Firefox rendering engine fails to parse certain font data and then bails out whereas Safari is able to decide whether the invalid meta data would prevent the font from being rendered.
|
|
||
Comment 4•5 years ago
|
||
Both Firefox and Chrome use the OpenType Sanitizer (https://github.com/khaledhosny/ots) to check downloaded font data before attempting to use it. OTS validates the font against the OpenType specification; in some cases, for minor flaws where the correct values are evident, it will automatically correct the data, but otherwise it will reject fonts that do not conform to the spec.
In general, the appropriate response to such problems is to fix the font resource. Yes, it's possible that some systems may successfully render a given font even though it does not follow the spec, but that's always a gamble; it happens to work in Safari today, but there's no reason to expect that it always will. Maybe in a macOS update it'll "mysteriously" stop working because Core Text becomes stricter; who knows?
Description
•