I tried verifying a .otf font with Fontbakery.
Among the error messages, I don't understand the following:
FAIL head version is "0.00000" while name version string
(for platform 1, encoding 0) is "Version 0.1". [code: mismatch]
I explicitly posted version 0.1,
I don't know where to look for the "head version"
(alternatively I use FF on Linux and Glyphs - recently - on Mac)
Thank you
m
Comments
https://learn.microsoft.com/en-us/typography/opentype/spec/head
https://learn.microsoft.com/en-us/typography/opentype/spec/name
Somebody who knows more about FontForge might be able to comment further on where/how to address this.
I also tried to open the source file with a text editor, but I can't find the "0.00000" string.
Personally, I would do a dump of the font with TTX and look at the 'head' table there. That is closer to the compiled TTF than cracking it open in a typical font editor.
(Although even ttx is doing some decompiling/interpretation.)
<!-- Most of this table will be recalculated by the compiler -->
<tableVersion value="1.0"/>
<fontRevision value="0.0"/>
<checkSumAdjustment value="0x13cd243d"/>
<magicNumber value="0x5f0f3cf5"/>
<flags value="00000000 00001011"/>
<unitsPerEm value="1000"/>
<created value="Sun Jun 28 15:28:27 2020"/>
<modified value="Thu Jan 5 22:37:02 2023"/>
<xMin value="-1545"/>
<yMin value="-447"/>
<xMax value="1717"/>
<yMax value="1347"/>
<macStyle value="00000000 00000000"/>
<lowestRecPPEM value="8"/>
<fontDirectionHint value="2"/>
<indexToLocFormat value="0"/>
<glyphDataFormat value="0"/>
</head>
That is the version info that is zero, but should be 0.1 if it was going to match the 'name' table. I assume the 'name' table version string really is 0.1, as that is the value you were going for, and FontBakery claims it is so. Hoping somebody with more FontForge knowledge will chime in about where the various settings are. I suspect FF just requires you to set both values, separately. (Some apps derive both from a single entry in their user interface.)
Or an 16-bit number, top 8-bit as x, lower 8-bit as y, to make x.y .
The error might be confusing as "head version" has nothing todo with the table version number of the head table, but rather with the fontRevision field within the head table. That should indeed match the version naming field.
Within FontForge the fontRevision field is known as "sfnt Revision". It is most convenient to leave it empty, so FF will grab it either from Version from the PS Names section or from the Version field from the TTF Names section.
To make things even easier, better connect the Version field from the TTF Names section to Version from the PS Names section, by right-clicking the field and select "Same as PostScript Names". That way you only have to maintain the Version from the PS Names section.
Anyway, I won a cupcake from FontBakery
most probably You right, but it looks funny: some people have no idea what extract from font, other thoughtlessly try to repair it in "Quality Checker" and in effect we have "BIG SERIOUS PROBLEM was found. Do not use this font." (Mac FontBook - iykwim
When I am doing maintenance work on fonts originally created by other people, this is one of the most common issues, especially in a VTT and/or VOLT workflow. Typically, the name table version string will have been updated, but not the head table font revision number.
[The Tiro build tool automatically updates both from the version value in the config file.]
https://github.com/FontVal-extras/FontVal-RX/blob/17fd2b13f5e902107f98c5e01203ad9301eb8dda/GenerateFValData/OurData.xml#L9343
With the description:
<problem>The fontRevision value in the head table should be consistent with the version string in the name table. The 'major' numbers should match and the 'minor' numbers should match to the thousandths place (when rounded and zero-padded).</problem>
That's IMO clearer.