Fontbakery: new check: Ensure VF PRs to google/fonts include info about where to fetch static fonts

Created on 2 Oct 2019  Â·  8Comments  Â·  Source: googlefonts/fontbakery

For VF pull requests to google/fonts, we usually include a dir called 'static' which contains new static fonts e.g https://github.com/google/fonts/tree/master/ofl/oswald. We should have a check that ensures the following, if the pr is for a VF family, there should also be a static dir which contains static fonts.

Yesterday I merged a pr which didn't contain this dir and @thlinard rightly called me out on it,.

New check proposal

Most helpful comment

github.com/google/fonts remains for me (and I hope for others) a simple and practical way to have an easy and up-to-date access to all the fonts, in Desktop version.
When InDesign 2020 comes out and will be widely deployed in my organization, I'll probably focus less on static fonts, but for now, we can't use VF version.

All 8 comments

For new variable fonts in the library, do we know for a fact that static fonts are used in Google Fonts, or are they being overwritten with statics generated from the variable font's named instances? I am fairly sure I have been told this is the case, but I don't know where I have found it in writing.

If they are being overwritten by generated instances, is there a separate reason to include them in each new PR? For example, do we expect users to come to google/fonts to download fonts? Or are the static fonts in directories withing google/fonts used in the downloads provided via fonts.google.com?

I'm not trying to be argumentative on this; I just know that for fonts with many named instances, this requirement adds a significant amount of complexity to the build process and PRs, so I just want to be certain it is a valid requirement.

@rsheeter thoughts?

github.com/google/fonts remains for me (and I hope for others) a simple and practical way to have an easy and up-to-date access to all the fonts, in Desktop version.
When InDesign 2020 comes out and will be widely deployed in my organization, I'll probably focus less on static fonts, but for now, we can't use VF version.

That's helpful to hear the need, @thlinard – thanks!

I still wonder if it might be slightly more elegant in the long run to auto-generate statics from VFs, but that would definitely take some setup, so for now, this seems like reason enough to keep statics in PRs.

There are also cases where we don't want to serve the auto-derived statics from a VF, such as when they are hand hinted.

Generally speaking GF will generate it's own instances. We don't rely on named instances, we use our axis registry so, for example, regardless of what named instances are present we'll always generate hundred-weights, etc.

For serving purposes we don't need the statics to exist here, except for the rare case where we need hand hinted instances.

Here's an example of a user that would benefit from corresponding statics being included in a VF PR that was merged last July/2019: https://github.com/google/fonts/issues/2314

We should provide the URLs for where to fetch statics - from our API and from upstream - and not duplicate them here.

Was this page helpful?
0 / 5 - 0 ratings