Width class mapping in G3

[simoncozens]

When mapping user-space to design-space in the designspace file, glyphsLib uses the "Width Class" in the instances of the source file, not the axis coordinates. However, Glyphs does not write a widthClass for the default value (5). For some reason, glyphsLib then infers a widthClass of 100, leading to a designspace like this:

    <axis tag="wdth" name="Width" minimum="2" maximum="100" default="100">
      <map input="2" output="70"/>
      <map input="3" output="79"/>
      <map input="4" output="89"/>
      <map input="100" output="100"/>
    </axis>

[simoncozens]

Obviously there are two problems here. I can fix the inferred default, but the other problem is that the range of the width axis then goes from 2.0 to 5.0. I think that axis coordinates should be used for mapping instead.

[simoncozens]

Setting the _axis_defaults to (100, 5) messes up all the tests, and I don't know why.

[schriftgestalt]

Using the weight/width class as axis location and mapping is simply wrong, e.g.: it breaks the export of all of my own fonts. Please use the axis coordinates as is. And only add a avar mapping when there is an "Axis Location" parameter in both the masters and the instances. Because inferring the mapped axis ranges from instances only works if you have instances exactly at each master. And that is an assumption I would not dare to make.

[anthrotype]

this must be a regression in the glyphs3 transition, or a change of semantics in g3. We should ensure that existing glyphs2 fonts that relied on the old glyphsLib behavior continue to work and use whatever g3 now defines for g3 sources

[simoncozens]

Looks like something was supposed to go through WIDTH_CLASS_TO_VALUE in builder.axes, but in some cases it hasn't.

[simoncozens]

        # Try to guess the user location by looking at the OS/2 weightClass
        # and widthClass. If a weightClass is found, it translates directly
        # to a user location in 0..1000. If a widthClass is found, it
        # translate to a percentage of extension according to the spec, see
        # the mapping named `WIDTH_CLASS_TO_VALUE` at the top.
...
            # Instances have special ways to specify a user location.
            # Only weight and with have a custom user location via a key.
            # The `user_loc_key` gives a "location code" = Glyphs UI string
            user_loc_str = getattr(master_or_instance, self.user_loc_key)
            new_user_loc = user_loc_string_to_value(self.tag, user_loc_str)
            if new_user_loc is not None:
                user_loc = new_user_loc

In [2]: master_or_instance.widthValue
Out[2]: 89

In [3]: user_loc_str = getattr(master_or_instance, self.user_loc_key)

In [4]: new_user_loc = user_loc_string_to_value(self.tag, user_loc_str)

In [5]: new_user_loc
Out[5]: 4

As per most glyphsLib bugs, glyphsLib is guessing something when it already knows the right answer.

[anthrotype]

i think in glyphs2 widthValue was a string like "Semi-Condensed" or similar, glyphs3 changed it to an int. So something has broken in the transition. The guessing was necessary before, it did not know the right answer because there wasn't yet any.

[simoncozens]

Yeah, it looks like another problem is that in G2 files, instance.width is a string, whereas in G3 files instance.width is coming in as a class number.

[simoncozens]

I think I have a fix.