fontbakery: Check 044 is always an error

Observed behaviour

Check 044 always produces this error:

   Checking font version fields (head and name table).
 * FAIL: head version is ('1', u'00099'), name version string for platform 1, encoding 0, is ('1', u'001') [code: mismatch]
 * FAIL: head version is ('1', u'00099'), name version string for platform 3, encoding 1, is ('1', u'001') [code: mismatch]

   Result: FAIL

It does this on a fresh, unedited font directly out of Glyphs. I think this output looks good.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 27 (13 by maintainers)

Commits related to this issue

split code-test: check/044 and check_parse_version_string (issue #2006) — committed to felipesanches/fontbakery by felipesanches 6 years ago
fix #2006: accept rounding fontRevision due to bad ... interpretations of float values causing false-FAILs (such as 1.001 being interpreted as 1.00099) — committed to felipesanches/fontbakery by felipesanches 6 years ago
split code-test: check/044 and check_parse_version_string (issue #2006) — committed to fonttools/fontbakery by felipesanches 6 years ago

Most upvoted comments

Here are pertinent comments from Peter Constable in the fonttools thread that Nikolaus linked above (https://github.com/fonttools/fonttools/issues/944#issuecomment-299973659):

The Fixed type has been problematic for versioning because of different interpretations for the fractional portion. In OT1.8, we changed all the instances we could to majorVersion/minorVersion uint16s. A few tables – maxp, post, vhea – were not amenable to this because of versions having been defined that would not work with that pattern.

The head.fontRevision field is another problematic case: I’ve seen fonts that handle the fractional portion in both ways. If you treat head.fontRevision as a floating value, then when reading an existing font you have to decide which interpretation to assume.

In these few remaining places where Fixed is used for versioning, I’d be inclined to treat the whole as a single, atomic value; or else treat it as two separate uint16s without trying to assume how to interpret the minor portion as a fraction.

chrissimpkins on Aug 13, 2018

(I’m out of office until later this week)

I read the whole thread but didn’t get the part where Glyphs does the wrong thing?

One thing I liked to suggest to change ttx to handle most of the 16.16 version fields as two 16bit major/minor fields. The float conversation is just to annoying.

schriftgestalt on Aug 13, 2018