AVAR fails in browsers on macOS if non-registered axes are in font (Mojave & Catalina)

This may be a dumb question, but if so, I hope the answer is simple. 😃

The problem

I am using <map> elements in a designspace file in an attempt to refine the distribution of instances precisely along the weight curve of my sources.

My font project has weight masters A, B, and C (approximately Light, ExtraBold, and Heavy).

However, through many experiments, I am having almost no luck* in manipulating intermediate weights via map/avar, except by changing the relative values of weights A and C.

I have verified that the avar table is affected by different values in the map elements of my designspace. However, even when I attempt to do fairly radical experiments (such as shifting the weight of 400/Regular to be right next to 800), I can see no affect in the output variable font, when tested in web browsers.

*Update, just before I post this: when building with only FontMake in a simpler way (not my full build script), the mapping is working in FontView and Illustrator, but still not in any web browsers – even though I have changed all the font names, which has always worked to avoid font cache issues in the past. So, this could possibly be isolated as a browser bug? I’m going to quit and restart everything to see if that has an effect, and will report back. (DONE. Comment below.)

My current understanding

In a recent edit to the designspaceLib readme, the map element includes this definition:

map element Defines a single node in a series of input value (user space coordinate) to output value (designspace coordinate) pairs. source

Therefore, my current understanding is that the element works like this:

<map input="[CSS VALUE HERE]" output="[TYPE DESIGN VALUE HERE]" />

Further, I am under the impression that the output value or “designspace coordinate” must be used in the xvalues of both sources and instances. This is informed by previous trial and error – if I use the input value in sources or instances, fontmake fails to build an output.

So, I am currently trying to use “stem widths” for my designspace coordinates (specifically, the stem width of the /n when scaled to a common x-height).

Context / Goal

My general goal is to visually match the thickness of my “Regular” instance to the Regular instances of Roboto, Helvetica Neue, and SF Pro Text.

But, despite many attempts to adjust intermediate weights with avar, the instance weights are unchanging, so the only way I have found to alter the middle masters is by changing the values of the lightest and heaviest masters (for example, by assigning my heaviest master to a user-space value of 1000 rather than 900). Mostly, I am stuck with this same result, in which my Regular is less thick than the Regular instances of common/generic Sans Serifs:

I am testing this in a simple html/css document (permalink to current commit).

Example of avar failure (?)

This axis map:

<axis tag="wght" name="Weight" minimum="300" maximum="1000" default="300">
      <labelname xml:lang="en">Weight</labelname>
      <map input="300" output="40" />
      <map input="400" output="158" />
      <map input="500" output="159" />
      <map input="600" output="160" />
      <map input="700" output="161.0" />
      <map input="800" output="162" />
      <map input="850" output="180" />
      <map input="900" output="197.5" />
      <map input="1000" output="215" />
</axis>

Yields this avar result:

<segment axis="wght">
      <mapping from="-1.0" to="-1.0"/>
      <mapping from="0.0" to="0.0"/>
      <mapping from="0.1429" to="0.67426"/>
      <mapping from="0.2857" to="0.68"/>
      <mapping from="0.4286" to="0.6857"/>
      <mapping from="0.5714" to="0.6914"/>
      <mapping from="0.7143" to="0.7"/>
      <mapping from="0.7857" to="0.8"/>
      <mapping from="0.8571" to="0.9"/>
      <mapping from="1.0" to="1.0"/>
</segment>

My expectation is that if 0.1429 is mapped to 0.67426, my 400/Regular instance should be nearly identical to my 800/ExtraBold instance.

However, the visual result is indistinguishable from much less distorted map values.

Here’s the font with a “distorted” avar

Here’s a font with a “less distorted” avar

Reproducing the issue

This testing has been done with a designspace for my project, Recursive (permalink to current experimental designspace). This can be build with fontmake:

fontmake -m <path/to/file>.designspace -o variable

[arrowtype]

I tried to remove all the other axes except for the wght axis (using fonttools varLib.instancer font.ttf MONO=drop CASL=drop slnt=drop ital=drop) and now the avar table seems to be applied correctly

Interesting … it’s super good to know about the instancer! What a useful tool. 😃

I can confirm that limiting Recursive to just a wght axis made the mapping work.

I then tried to make versions with just two axes, and it failed each time if there is a non-registered axis.

• FAILED: Weight & Monospace
• FAILED: Weight & Casual (AKA “Expression”, depending on the version of Recursive)
• WORKED: Weight & Slant
• WORKED: Weight & Italic
• WORKED: Weight & Slant & Italic

Example of working with only registered axes: wght + slnt + ital (Click to expand)

[Lorp]

The problem is not restricted to registered axes. A test font with wght (axis 0) and wdth (axis 1) was recompiled using TTX in two versions which differ in the avar-mapped axis.

Font 0 has a visually obvious mapping on axis 0 only:

  <avar>
    <segment axis="wght">
      <mapping from="-1.0" to="-1.0"/>
      <mapping from="0.0" to="0.0"/>
      <mapping from="0.9" to="0.1"/>
      <mapping from="1.0" to="1.0"/>
    </segment>
    <segment axis="wdth">
      <mapping from="-1.0" to="-1.0"/>
      <mapping from="0.0" to="0.0"/>
      <mapping from="1.0" to="1.0"/>
    </segment>
  </avar>

While Font 1 has the same mapping on axis 1 only:

  <avar>
    <segment axis="wght">
      <mapping from="-1.0" to="-1.0"/>
      <mapping from="0.0" to="0.0"/>
      <mapping from="1.0" to="1.0"/>
    </segment>
    <segment axis="wdth">
      <mapping from="-1.0" to="-1.0"/>
      <mapping from="0.0" to="0.0"/>
      <mapping from="0.9" to="0.1"/>
      <mapping from="1.0" to="1.0"/>
    </segment>
  </avar>

Font 0 was observed to work correctly. Font 1 has issues in macOS 10.14.6, such that when axis 0 is at min, the avar mapping in axis 1 is ignored. Expected behaviour is observed in FontGoggles and in Samsa’s main glyph view.

These two test fonts both work well in macOS 10.15.5.