Home› Font Technology

FontBakery checking

mauro sacchettomauro sacchetto Posts: 353
in Font Technology
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

  • Thomas PhinneyThomas Phinney Posts: 2,513
    Both the 'head' table and the 'name' table can have version info, in an OpenType font. In your case, they both have info, but they disagree. The version info in the 'head' table says zero, and the one in ID 5 of the 'name' table says 0.1

    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.
  • mauro sacchettomauro sacchetto Posts: 353
    edited January 5
    Thank you, but the nature of the problem is clear to me.
    In the two sectors PS NAMES and TTF Names the version is correctly set, and I can't find in FF other fields where the 0.00000 exists.
    I also tried to open the source file with a text editor, but I can't find the "0.00000" string.
    Unfortunately at the moment I can't verify the .otf file with Glyphs, because my daughter has it on Mac....
  • Thomas PhinneyThomas Phinney Posts: 2,513
    I would be happy to take a look at the OTF.

    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.)
  • mauro sacchettomauro sacchetto Posts: 353
    Good suggestion, thanks! This is what I see:

      <head>
        <!-- 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>

    I attach the file (note that only the Latin alphabet has been modified, all the rest belongs to a different version. Everything is largely experimental)



  • Thomas PhinneyThomas Phinney Posts: 2,513
    Well, FontBakery isn’t wrong about the 'head' table saying the version is zero. 
    &nbsp; &nbsp; <fontRevision value="0.0"/><br>

    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.)
  • Hin-Tak LeungHin-Tak Leung Posts: 359
    edited January 6
    If I remember correctly, font version is a 32-bit number, the top 16-bit is x, the lower 16-bit is y, to make x.y. It is not a string. Use the opentype spec.

    Or an 16-bit number, top 8-bit as x, lower 8-bit as y, to make x.y .
  • Erwin DenissenErwin Denissen Posts: 287
    Disclaimer: I have an outdated version of FontForge which I open up maybe once a year for these kind of support questions, so my advise might not be the best.
    mauro sacchetto said:
    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)
    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.

    Hope this helps.
  • mauro sacchettomauro sacchetto Posts: 353
    Thanks to all.
    « Within FontForge the fontRevision field is known as "sfnt Revision". It is most convenient to leave it empty, » : this advice was decisive and in fact eliminates the error. As soon as I get the MacBook back I check how things are in Glyhs.
    Anyway, I won a cupcake from FontBakery :)



  • c.g.c.g. Posts: 47
    For the sake of completeness, version is also stored in the topDict of CFF table, where x.y must be two integers. If checkoutlinesufo doesn’t find two integers, it will fail.
  • Grzegorz Luk (gluk)Grzegorz Luk (gluk) Posts: 112
    more interesting question is: from where come idea that 'fontRevision' in head table and 'Release and version' (id=5) in name table should be equal ? :)

  • Erwin DenissenErwin Denissen Posts: 287
    Grzegorz Luk (gluk) said:
    more interesting question is: from where come idea that 'fontRevision' in head table and 'Release and version' (id=5) in name table should be equal ? :)

    I think it is required to avoid ambiguity, as some use fontRevision while others extract the font version from the version naming field.
  • Grzegorz Luk (gluk)Grzegorz Luk (gluk) Posts: 112
    edited January 6
    Erwin Denissen said:
    ... required to avoid ambiguity ...
    according to OpenType doc 'fontRevision' is set by font manufacturer, and 'Release and version' in name table by the font vendor. In most cases it will be the same person and then the entries will be identical, but not always :) Otherwise, the entries have a different format!
    ...as some use fontRevision while others extract the font version from the version naming field...
    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 :D  :D )
  • John HudsonJohn Hudson Posts: 2,725
    As a side note: this check is not limited to Font Bakery. Microsoft’s venerable Font Validator tool performed the same check and also gave an error warning if these two data differed.

    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.]
  • Hin-Tak LeungHin-Tak Leung Posts: 359
    edited January 7
    Argh, yes, in Font Validator, the warning is W1314:

    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.
Sign In or Register to comment.