Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Axis mappings completely upside down #993

Open
simoncozens opened this issue Mar 27, 2024 · 3 comments · May be fixed by #1040
Open

Axis mappings completely upside down #993

simoncozens opened this issue Mar 27, 2024 · 3 comments · May be fixed by #1040
Assignees

Comments

@simoncozens
Copy link
Collaborator

Let's take Nunito.glyphs which is a Glyphs 2 file and convert it to designspace. The weight axis mappings look like this:

    <axis tag="wght" name="Weight" minimum="200" maximum="1000" default="200">
      <map input="200" output="42"/>
      <map input="300" output="61"/>
      <map input="400" output="81"/>
      <map input="500" output="91"/>
      <map input="600" output="101"/>
      <map input="700" output="125"/>
      <map input="800" output="151"/>
      <map input="900" output="178"/>
      <map input="1000" output="208"/>
    </axis>

In Glyphs, I open the file, change it to file format 3 and save it. When run through glyphs2ufo, the axis mapping now looks like this:

    <axis tag="wght" name="Weight" minimum="42" maximum="208" default="42">
      <map input="42" output="200"/>
      <map input="61" output="300"/>
      <map input="81" output="400"/>
      <map input="91" output="500"/>
      <map input="101" output="600"/>
      <map input="125" output="700"/>
      <map input="151" output="800"/>
      <map input="178" output="900"/>
      <map input="208" output="1000"/>
    </axis>

I think this is because Glyphs changed its understanding of the Axis Mapping custom parameter, so that's a pain but it probably can't be helped.

Let's get rid of the Axis Mapping custom parameter, save the Glyphs file, and try again, relying on the axis coordinates in the instances to provide the mapping.

 <axis tag="wght" name="Weight" minimum="1" maximum="1000" default="200">
      <map input="1" output="208"/>
      <map input="200" output="42"/>
      <map input="300" output="61"/>
      <map input="400" output="91"/>
      <map input="500" output="91"/>
      <map input="600" output="101"/>
      <map input="700" output="125"/>
      <map input="800" output="151"/>
      <map input="900" output="178"/>
      <map input="1000" output="208"/>
    </axis>

Where did that "1" come from?

@schriftgestalt
Copy link
Collaborator

That was changed after this discussion: #745 (comment)

@schriftgestalt
Copy link
Collaborator

I’ll look into the "1".

@schriftgestalt schriftgestalt self-assigned this Mar 27, 2024
@simoncozens
Copy link
Collaborator Author

Just hit some weird issues in fontmake with the compatibility checker dying:

% fontmake -o variable -g sources/AndadaPro.glyphs
    if not CompatibilityChecker(source_fonts).check():
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/simon/others-repos/fontmake/Lib/fontmake/compatibility.py", line 26, in check
    first = self.fonts[0]
            ~~~~~~~~~~^^^
IndexError: list index out of range

This turns out to be the same issue! Because the axis mappings are upside down, we produce designspace files like so:

    <axes>
        <axis tag="wght" name="Weight" minimum="96" maximum="140" default="96">
            <map input="96" output="400" />
            <map input="140" output="840" />
        </axis>
    </axes>
    <sources>
        <source filename="AndadaPro-Regular.ufo">
        <location>
            <dimension name="Weight" xvalue="96" />
        </location>
        </source>
        <source filename="AndadaPro-XBold.ufo">
        <location>
            <dimension name="Weight" xvalue="140" />
        </location>
        </source>
    </sources>

and when splitInterpolable runs on this, it produces a designspace with no sources, which gets handed to the compatibility checker, and self.fonts is empty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants