Ninja Builder

[simoncozens]

An experimental version of gftools.builder which uses ninja to orchestrate font builds instead of fontmake's top-level methods.

~~Currently only does the variable font bit; the real speedup is with the statics.~~

[simoncozens]

Building all Rubik targets with gftools-builder: 1m 52s. Building all Rubik targets with gftools-builder-ninja: 23s.

[felipesanches]

I think you'll need to update requirements.txt and setup.py to include the new ninja dependency.

[simoncozens]

There is still some problem here with instance UFO filenames. Sometimes fontmake puts them into instance_ufo/ regardless of what's in the designspace file and sometimes it goes with the path in the designspace file, and I can't work out what happens when.

[simoncozens]

Just an update on this: I've used it to build hundreds of Noto fonts, and for that it works well. I haven't tracked down the issue with instance UFOs ending up in the wrong place, because I'm scrambling to get lots of fonts built and released and don't really have any bandwidth for anything else. If anyone wants to play with it, clone the googlefonts-project-template and try building that.

[arrowtype]

Hey, sorry to have complicated this PR. I really appreciate you taking a bit of time to respond to my questions! I definitely don't want to block it when it's already proving useful for a bunch of projects. Mine is a somewhat weird use case (it is also for Google Fonts, FWIW), so I can try to hack on it on my end if what I need isn't applicable to your projects. Thanks for all your great work here!

[simoncozens]

Start with looking at the build.ninja. Looks like an argument to genstat has become a JSON string instead of a filename.

[simoncozens]

OK, I've fixed the stat table issue, but there's another problem, which is that sometimes glyphs2ufo produces a designspace file with instance filenames like this:

  <instances>
    <instance name="Texturina Thin" familyname="Texturina" stylename="Thin" filename="instance_ufos/Texturina-Thin.ufo">

(Note "instance_ufos".)

When you run fontmake -o ttf -i -m on that designspace, all the generated instances end up getting placed in instance_ufo/.

I don't know if that's a glyphsLib bug or a fontmake bug or both. (@anthrotype?) I suppose we could probably work around it by passing -n instance_ufo to glyphs2ufo, but it's a bit ugly.

(Edit: Actually, we don't use glyphs2ufo directly, we use fontmake -o ufo -g, but it comes to the same thing: it writes instance_ufos and fontmake doesn't honour that.)

[simoncozens]

Boggle

$ grep "ExtraLight" master_ufo/Texturina-Italic.designspace | grep 72pt
    <instance name="Texturina 72pt ExtraLight Italic" familyname="Texturina 72pt" stylename="ExtraLight Italic" filename="instance_ufo/Texturina72pt-ExtraLightItalic.ufo" stylemapfamilyname="Texturina 72pt ExtraLight" stylemapstylename="italic">

$ fontmake -o ufo -i -m master_ufo/Texturina-Italic.designspace
...
INFO:fontmake.font_project:Generating instance UFO for "Texturina 72pt ExtraLight Italic"
...

$ ls -al instance_ufo/Texturina72pt-ExtraLightItalic.ufo
ls: cannot access 'instance_ufo/Texturina72pt-ExtraLightItalic.ufo': No such file or directory

[simoncozens]

And another issue: if we have a .designspace file where there are instances but no filenames defined (e.g. the Roboto Serif designspace), I don't know how to work out what the eventual UFO file names will be. (We need those as targets, so we can then add rules to convert them to TTF.)

[anthrotype]

if there's an instance filename attribute, it is meant to be interpreted as relative to the directory of the .designspace file itself. So in your example above (where you grep'ed for "ExtraLight" in Texturina), the instance has filename="instance_ufo/Texturina72pt-ExtraLightItalic.ufo" but the designspace file is inside master_ufo/Texturina-Italic.designspace, so the generated instances are going to be in.. master_ufo/instance_ufo/... fontmake is following what it's told, some other tool might have set those instance filename attributes incorrectly (glyphsLib?).

if we have a .designspace file where there are instances but no filenames defined (e.g. the Roboto Serif designspace), I don't know how to work out what the eventual UFO file names will be.

I'm fixing that in https://github.com/googlefonts/fontmake/pull/102. If an instance does not have any filename attribute defined, we make up its name from the instance ufo's family/style name (similarly to how we make up the OTF/TTF output path from a UFO input). In addition to this, you will be able to pass --output-path if you are building one instance UFO (you know you can already filter which instance(s) to build with -i option which takes a regex matching instance.name attr). I hope that helps..

[anthrotype]

and you will also be able to pass --output-dir option to override in which directory the instance UFOs gets saved when building -i -o ufo

[simoncozens]

Well this is frustrating; coming back to try to fix it, I now can't make it fail in the way that I'm sure it used to. It correctly builds:

• Albert Sans
• Texturina
• League Spartan
• Nunito
• Questrial
• Inconsolata (with fallback to old builder)
• Silkscreen

So... it works?

[anthrotype]

frustrating but in a good way 😉

[m4rc1e]

Seems to be failing the builder tests. I put these in place so we don't cause regressions for The Type founders, #670

[simoncozens]

Thanks. It seems like it works for .glyphs and .designspace files but not for individual .ufos.

[simoncozens]

OK, apart from Windows which I'll disable because, well, Windows users shouldn't expect ~nice things~ shell syntax.

[madig]

FWIW, when fiddling with filename attributes with designspaceLib, set the filename on .filename and set .path = None. This will stop dsLib from trying to be clever.