[makeinstancesufo] write openTypeOS2WeightClass in instance UFOs according to designspace axis map

[frankrolf]

A suggestion from @arialcrime:

Based on some testing, it seems that makeinstancesufo sets the value for openTypeOS2WeightClass based on linear interpolation. The following example is set up to have a weight axis with three sources, and relatively random weight class values assigned to each source.

sources w/ weight class:
TestFont_0.ufo 100
TestFont_1.ufo 500
TestFont_2.ufo 900

resulting instances:
TestFont-Style_01.ufo 100
TestFont-Style_02.ufo 140
TestFont-Style_03.ufo 180
TestFont-Style_04.ufo 220
TestFont-Style_05.ufo 260
TestFont-Style_06.ufo 300
TestFont-Style_07.ufo 340
TestFont-Style_08.ufo 380
TestFont-Style_09.ufo 420
TestFont-Style_10.ufo 460
TestFont-Style_11.ufo 500
TestFont-Style_12.ufo 540
TestFont-Style_13.ufo 580
TestFont-Style_14.ufo 620
TestFont-Style_15.ufo 660
TestFont-Style_16.ufo 700
TestFont-Style_17.ufo 740
TestFont-Style_18.ufo 780
TestFont-Style_19.ufo 820
TestFont-Style_20.ufo 860
TestFont-Style_21.ufo 900

sources w/ weight class:
TestFont_0.ufo 0
TestFont_1.ufo 666
TestFont_2.ufo 1000

resulting instances:
TestFont-Style_01.ufo 0
TestFont-Style_02.ufo 67
TestFont-Style_03.ufo 133
TestFont-Style_04.ufo 200
TestFont-Style_05.ufo 266
TestFont-Style_06.ufo 333
TestFont-Style_07.ufo 400
TestFont-Style_08.ufo 466
TestFont-Style_09.ufo 533
TestFont-Style_10.ufo 599
TestFont-Style_11.ufo 666
TestFont-Style_12.ufo 699
TestFont-Style_13.ufo 733
TestFont-Style_14.ufo 766
TestFont-Style_15.ufo 800
TestFont-Style_16.ufo 833
TestFont-Style_17.ufo 866
TestFont-Style_18.ufo 900
TestFont-Style_19.ufo 933
TestFont-Style_20.ufo 967
TestFont-Style_21.ufo 1000

sources w/ weight class:
TestFont_0.ufo 0
TestFont_1.ufo 10000
TestFont_2.ufo 1000

resulting instances:
TestFont-Style_01.ufo 0
TestFont-Style_02.ufo 2000
TestFont-Style_03.ufo 4000
TestFont-Style_04.ufo 6000
TestFont-Style_05.ufo 8000
TestFont-Style_06.ufo 10000
TestFont-Style_07.ufo 8200
TestFont-Style_08.ufo 6400
TestFont-Style_09.ufo 4600
TestFont-Style_10.ufo 2800
TestFont-Style_11.ufo 1000

As far as I know, the openTypeOS2WeightClass value is not read in the makeotf workflow (usually, we assign this value in an override file). Nevertheless, I think it is not unreasonable to expect that value to be influenced by a designspace mapping.

current:

designspace mapping:

    <axis tag="wght" name="weight" minimum="100" maximum="900" default="500">
      <map input="100" output="0"/>
      <map input="300" output="250"/>
      <map input="500" output="500"/>
      <map input="600" output="750"/>
      <map input="900" output="1000"/>
    </axis>

sources:
TestFont_0.ufo 100
TestFont_1.ufo 500
TestFont_2.ufo 900

instances:
TestFont-Style_1.ufo 100
TestFont-Style_2.ufo 300
TestFont-Style_3.ufo 500
TestFont-Style_4.ufo 700
TestFont-Style_5.ufo 900

expected:

(same sources, same designspace mapping)

instances (at “output” coordinates):
TestFont-Style_1.ufo 100
TestFont-Style_2.ufo 300
TestFont-Style_3.ufo 500
→ TestFont-Style_4.ufo 600
TestFont-Style_5.ufo 900

os2weightClass via map.zip

[Lorp]

The spec suggests you should insert the rounded value of the wght axis, before any avar magic.

Here is a note from OpenType 1.9: MVAR, explicitly handing over responsibility to the corresponding registered axes:

Note: The OS/2.usWeightClass, OS/2.usWidthClass and post.italicAngle values are not supported by variation data in the MVAR table. This is because values for these three fields correspond directly to input axis values for the 'wght', 'wdth' and 'slnt' variation axes.

And here is a matching note in OpenType 1.9: OS/2, that explicitly allows non-multiples of 100:

Description: Indicates the visual weight (degree of blackness or thickness of strokes) of the characters in the font. Values from 1 to 1000 are valid.
Comments: usWeightClass values use the same scale as the 'wght' axis that is used in the 'fvar' table of variable fonts and in the STAT table. While integer values from 1 to 1000 are supported, some legacy platforms may have limitations on supported values. The following are commonly-used values:

[frankrolf]

@Lorp Is this related to Benedikt’s suggestion?
(please note that instance UFOs imply static, not-variable fonts)

[Lorp]

I don’t know about Benedikt’s suggestion. Link? I was pleased to see it’s clear that usWeightClass is not limited to units of 100 in static fonts, so relayed the links.

[frankrolf]

Perhaps my description above is not clear enough.
This all only has to do with UFO source data. The WeightClass values here are the result of a linear interpolation, nothing else can be inferred from them. As I hoped to describe above, Benedikt thinks it makes sense to insert the “input” end of the mapping values into the instance UFOs, in case such a mapping exists.

[Lorp]

I often forget about designspace-to-userspace mappings, so that may be my confusion. When you say "based on linear interpolation" which values are you talking about? What values would you expect to see? I don’t understand your third example. I’m surprised it is not rejected.

[frankrolf]

Rejected by who? Did you look into the attached zip file?

makeinstancesufo is a tool which creates ufo instances from ufo source files.
The three examples illustrate what makeinstancesufo does when setting the weight class in the UFO metadata. Using an extreme value like in the 3rd example, I demonstrate that it’s the result of a linear interpolation between two poles.

The value I/Benedikt expect or hope to see are in “expected“ – corresponding to the mapping in the designspace file (which often is a manifestation of OS/2 values).

[Lorp]

I don’t think I’m helping here. I’ll shut up :)