Use gftools/CI for building

[simoncozens]

Hi! My name is Simon, and I'm a contractor for Google Fonts; I work with Rosalie on some of the more tricky programming stuff. This PR:

• Moves a few things around in the repository (notably source/wavefont -> sources/) so that it more closely resembles a standard GF project.
• Allows for building the binary fonts with the Google Fonts builder
• Adds a Makefile so that onboarders can rebuild the whole font in a single command
• Adds CI building and testing, so that onboarders can rebuild and QA the whole font in zero commands
• Renames instances so that they more closely fit the GF schema
• Fixes a number of fontbakery fails.

[dy]

@simoncozens thanks for the work!

A couple questions. I want to retain old build process with the new one and document that. If that's something you can help with.

1. I see produced fonts in /fonts folder - but I don't see generated variable font. Is that something gftools are capable of?
2. Currently variable wavefont.woff2 is generated into root folder (by old pipeline), I wonder if that should reside under different location?
3. Can we add more instances? Hairline and regular seem to be a bit extremes, it seems light face can be also useful.
4. Old pipeline patches characters via cmap.ttx to map to blanks - is that something done by gftools?

I can make these changes myself I suppose, but if you can give input/explainer I'd appreciate

[simoncozens]

Hi Dmitri! So the old build process has not changed; you can still use npm to template your UFO files. I have just put a Makefile wrapper around it.

I see produced fonts in /fonts folder - but I don't see generated variable font. Is that something gftools are capable of?

Yes, I don't know why I thought this wasn't a variable font, but we can remove the line buildVariable: false from sources/config.yaml and gftools builder will build variable fonts too.

Currently variable wavefont.woff2 is generated into root folder (by old pipeline), I wonder if that should reside under different location?

gftools-builder doesn't make variable woff2 yet (I have a PR for it but it needs rebasing). When that PR is merged, it will produce a variable font in fonts/webfonts/wavefont[ROND,wght].woff2.

Can we add more instances? Hairline and regular seem to be a bit extremes, it seems light face can be also useful.

Good idea. If you look in _sources/wavefont.designspace you will see the instances tag. Perhaps we will need an instances variable in the templater so we can set which instances we want and their designspace position.

Old pipeline patches characters via cmap.ttx to map to blanks - is that something done by gftools?

In a font, any unmapped character is mapped to the .notdef glyph, which in this font is a space, so nothing special is needed for the cmap.

[dy]

Thank you for responses.

In a font, any unmapped character is mapped to the .notdef glyph, which in this font is a space, so nothing special is needed for the cmap.

What I see from tests is that ./fonts/otf/Wavefont-Regular.otf doesn't stub .notdefs with blank (likely browser hands .notdefs to fallback font in stack):

Original wavefont.otf:

We recently introduced cmap.ttx (identical to Adobe Blank method), which patches final otf font with ttx -o wavefont.otf -m wavefont.otf source/Wavefont/cmap.ttx command. I wonder if that post-processing can be done to generated /fonts, or if there's an other way to provide format 13 cmap table in sources?

⁂

Another consideration - does it play role now to store generated ufo files under /sources folder? Can that folder be removed from the repository, ie. can gftools just do make build? (it seems to generate unnecessary diff logs and increases repository weight). Is that used by github actions?