fonttools: 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