Axis mappings/avar not working in Firefox with a multiaxis VF

The avar tables are identical in both fonts (the one made with fontmake, which works, and the one made with Glyphs, which doesn’t) So it is probably something else :thinking:

I think I diagnosed the problem - Glyphs is adding an extra axis to the STAT table. I have a weight and optical axis, and dont have or mention an italic axis anywhere in the Glyphs file. But if I dump the STAT table you can see it adds one (Edit: whoops pasted the wrong one):

<STAT>
    <Version value="0x00010001"/>
    <DesignAxisRecordSize value="8"/>
    <!-- DesignAxisCount=3 -->
    <DesignAxisRecord>
      <Axis index="0">
        <AxisTag value="wght"/>
        <AxisNameID value="256"/>  <!-- Weight -->
        <AxisOrdering value="0"/>
      </Axis>
      <Axis index="1">
        <AxisTag value="opsz"/>
        <AxisNameID value="257"/>  <!-- Optical size -->
        <AxisOrdering value="1"/>
      </Axis>
      <Axis index="2">
        <AxisTag value="ital"/>
        <AxisNameID value="388"/>  <!-- Italic -->
        <AxisOrdering value="2"/>
      </Axis>
    </DesignAxisRecord>
    ...
    <AxisValueArray>
      <AxisValue index="0" Format="1">
        <AxisIndex value="0"/>
        <Flags value="0"/>
        <ValueNameID value="382"/>  <!-- Thin -->
        <Value value="100.0"/>
      </AxisValue>
     ...
    <AxisValue index="63" Format="1">
        <AxisIndex value="2"/>
        <Flags value="2"/>  <!-- ElidableAxisValueName -->
        <ValueNameID value="2"/>  <!-- Regular -->
        <Value value="0.0"/>
      </AxisValue>
    </AxisValueArray>
    <ElidedFallbackNameID value="2"/>  <!-- Regular -->
  </STAT>

The last AxisValue looks odd too.
If I remove the STAT table it compiles just fine and avar works in Firefox.

That answers why it was working with fontmake (from UFO), where I didn’t set up the STAT table. As for why it worked in Chrome even when broken, maybe different interpretations of the output from OTS? I.e. Chrome ignores the problem as a warning because it doesn’t affect rendering, while Firefox decides to choke on it, as a hard error? I think it’s likely

The OpenType spec states:

the segment maps for the different axes must be given in the order of axes specified in the ‘fvar’ table.

Maybe that is not the case in your Glyphs-exported avar table?

No, it’s (almost) definitely the STAT table as I mentioned above, fvar is fine — the fvar axes are in order, but probably more importantly (and unlike STAT) fvar doesnt have any non-existent axes listed. The OTS error being thrown by Firefox doesn’t make sense but removing the offending axis in the STAT table resolves it

@jkutilek Just tried a git diff with the before/after ttx and nothing important is changing, only some head data.

@GeorgSeifert Sending you everything now!

Maybe tax is normalizing some values?

I tried the font you send me and it works fine in Firefox. What version of Firefox do you use and how do you load the font. Can you send me the .html?

edit: But I still found a problem and fixed it.

You can disregard what I say about STAT above, I must have done two things and forgot which fixed it and gotten it wrong.

The avar table in FF may have an index problem of some kind. Not sure if it’s an OTS problem. But if you delete one of the mapping values in between -1 and 0, it fixes it.

    <segment axis="opsz">
      <mapping from="-1.0" to="-1.0"/>
      <mapping from="-0.96875" to="-0.875"/>
      <mapping from="-0.9375" to="-0.5625"/>
      <mapping from="-0.90625" to="-0.375"/> <!-- e.g. delete this one to fix -->
      <mapping from="-0.875" to="-0.1875"/>
      <mapping from="-0.75" to="-0.0625"/>
      <mapping from="0.0" to="0.0"/> 
      <mapping from="1.0" to="1.0"/>
    </segment>

I double checked the masters and exports and all the axis locations are correct. This is with no “Axis Mappings” custom parameter. The table itself is right. But deleting a value from the Glyphs-created binary fixes it.

The weird thing is if I use fontmake to build the font from UFO with an avar table containing all 8 correct mapping values, Firefox is fine with it. Some other table that Glyphs generates, is maybe relying on the count here, or something (7 optical sizes = 8 mappings, maybe that is a clue). I’m not sure.

Ok, I just confirmed a suspicion, I see how I got confused. It is not a value in the avar table that is wrong itself. But if you recompile the avar table at all with ttx, it fixes it.

ttx -t avar BrokenFont.ttf
ttx -m BrokenFont.ttf BrokenFont.ttx 

This (recompiling the TTF binary using the same avar table that it reads) fixes the problem. Weird!

Can you try the latest cutting edge version (3124). It should produce a valid avar table.

1 Like

You fixed it! :tada: Thanks Georg!

I opened up an old Variable glyphs file, fixed all the Axis Locations (no axis mappings) for both masters and exports and the result is the same “Axis value map out of order”, exported from version 3130. Samsa on Chrome doesn’t recognize the variability even though Gauntlet does, for example.

I also saw an extra italic axis in the export that is not on the file visually.

Any thoughts on why this can be happening?

Can you send me the file?

That’s your video call lesson, all fixed – it was a problem of setting 0 width masters and also an export instance where most compressed had 0 unit for width and then the black had 40 units. This confused the design space a bit. All good now, thanks Rainer!