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

Does the -i / --interpolate flag produce nothing if a font has only a single master and instance? #1080

Open
arrowtype opened this issue Mar 21, 2024 · 11 comments

Comments

@arrowtype
Copy link

arrowtype commented Mar 21, 2024

I’m finding that, if I add the -i / --interpolate flag to a fontmake run, when trying to build from a simple Glyphs file that has just a single master and instance, I get no output.

On one hand, that would make some sense... if there’s nothing to interpolate, why would fontmake output anything?

On the other hand, it becomes an issue, because it seems that the gftools builder will add -i to most fontmake calls, even when not needed. (See googlefonts/gftools#878)

Additionally, if fontmake decides to not output anything due to a flag that is deemed irrelevant, I would expect to receive an error for that flag.

Reproduction:
https://github.com/arrowtype/fontmake-issue-1080-reproduction

If I’m just overlooking something obvious, I would also appreciate learning what I’m missing!

Thanks so much for any help, as always.

I’m using fontmake 3.8.1.

@anthrotype
Copy link
Member

It should work, if it doesn't it's a bug, will take a look tomorrow. Thanks

@arrowtype
Copy link
Author

Awesome, thanks so much! I did get the same result on two different computers, for what it’s worth. So, I don’t think it’s a problem with my particular environment (though of course I might be wrong). I really appreciate you taking a look!

@arrowtype
Copy link
Author

Testing this a little further, one interesting point is that fontmake 3.6.0 does output a master_ufo folder for fontmake -i -o ufo -g "New Font.glyphs", but this no longer works as of fontmake 3.7.0.

And, even in 3.6.0, if -i -o ttf is specified, it doesn’t create any TTF, but only the master_ufo folder.

I do think the 3.6.0 behavior might unblock googlefonts/gftools#878, but it could perhaps still be better to also output binaries when that option is specified.

@anthrotype
Copy link
Member

I cannot reproduce.. I made a new font in Glyphs.app, added one instance the Exports at the same location as the only master, and it worked with -i, whether i do -o ufo or -o ttf. I can see the font in respectively instance_ufo/ or instance_ttf/ directories.

Can you please upload a test font and a command line that reproces this with just fontmake (no gftools)? thanks

@arrowtype
Copy link
Author

Okay, thanks so much for testing this on your end! Looking at my reproduction case again, I now realize that it didn’t define an export in the Glyphs file – so it is not surprising it doesn’t build with -i. 🤦‍♂️

Unfortunately, the real font that sent me down this path is one I can’t share, but which does still exhibit this issue. But, the fact that the simple reproduction case doesn’t actually reproduce the issue indicates that the issue may be in the font, after all. I’ll dig in a bit more and see if I can find anything, and reopen this if I do think the issue might be here, after all.

@arrowtype
Copy link
Author

arrowtype commented Mar 26, 2024

Just to update this – the more complex Glyphs source had a similarly simple problem and solution: it had a mismatch between the single Master and Export. The Master was specified as weight=100 while the Export had weight=900. Once the Master was updated to weight=900, the build worked as expected.

Sorry for the false alarm here! Hopefully my mistake helps someone else out there, if they encounter the same question.

@anthrotype
Copy link
Member

Maybe we can try to identify this situation and issue a warning at least

@arrowtype
Copy link
Author

If that is a possibility, that does sound helpful! It’s very easy to set up Glyphs files with such small issues, and it can be hard to troubleshoot unless you really know what to look for.

@anthrotype
Copy link
Member

it had a mismatch between the single Master and Export. The Master was specified as weight=100 while the Export had weight=900. Once the Master was updated to weight=900

I tried that but still cannot reproduce the silent pass/no font gets built situation. In my case, with a single wght axis, one master at axis coordinates wght=100 and one instance at wght=900, fontmake crashes with a "no default master source" error:

$ fontmake -g ~/Downloads/New\ Font.glyphs -i -o ufo
INFO:fontmake.font_project:Building master UFOs and designspace from Glyphs source
INFO:glyphsLib.parser:Parsing .glyphs file
INFO:fontmake.font_project:Loading 1 DesignSpace source UFOs
WARNING:fontTools.designspaceLib.statNames:Cannot determine default source to look up family name.
INFO:fontmake.font_project:Interpolating master UFOs from designspace
WARNING:fontTools.designspaceLib.statNames:Cannot determine default source to look up family name.
fontmake: Error: In '../../Downloads/New Font.glyphs' -> 'master_ufo/NewFont-Regular.designspace': Preparing the Designspace for interpolation failed: Can't generate UFOs from this Designspace because there is no default master source at location 'Weight: 900'. Check that all 'default' values of all axes together point to a single actual master source. For axes with a mapping, the 'default' values should have an 'input="..."' map value, where the corresponding 'output="..."' value then points to the master source

@anthrotype
Copy link
Member

ok, after I added an Axis Location parameter to the single master, I can now see this:

$ fontmake -g ~/Downloads/New\ Font.glyphs -i -o ufo
INFO:fontmake.font_project:Building master UFOs and designspace from Glyphs source
INFO:glyphsLib.parser:Parsing .glyphs file
INFO:fontmake.font_project:Loading 1 DesignSpace source UFOs
INFO:fontmake.font_project:Interpolating master UFOs from designspace

no font got built, no error nor warning. Yeah I can see this can be quite confusing, we should address it.

@arrowtype
Copy link
Author

Ah, yes, that is pretty much what I’m seeing. Thanks for looking into it! Yes, it would be handy if it gave a clear error or warning message. Feel free to reopen this issue if you’d want to track that here (I closed it upon realizing my error).

@anthrotype anthrotype reopened this Mar 27, 2024
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

No branches or pull requests

2 participants