Plan library-scale bug fixing project

[davelab6]

Internal issue b/148455761 discusses this; in Q2 it would be good for me and Chris to work with y'all on a plan to fix the library at scale :)

Eg #1178 indestructible-type/Bodoni#39

[simoncozens]

This is something I have been thinking about. There is a speadsheet here which tracks the library-wide fails and gives suggestions for how to fix them. Many of the issues can be scripted or hotfixed, but the best way to start is to track down as many upstream repos as we can, which I have been working on.

[davelab6]

Adobe Fonts have also been working on this per the adobe-fonts fontbakery profile, made a Google Sheet to triage with me, and then drove a fonttools hotfix process using internal scripting with results posted to Drive only.

They identified the following indic fonts that lack a Rupee character, so adding that will be a good priority small-fix commission :)

• Kavivanar
• Modak
• Palanquin
• Palanquin Dark
• Pavanam
• Sumana

[rsheeter]

It would be helpful to fontc testing and adoption if we could include the ability to find the sources and identify which specific ones to compile as part of this. This enables us to test build things (googlefonts/fontc#724).

[simoncozens]

We already have this. Repos based on the googlefonts-project-template will have a sources/config.yaml which identifies the sources to build. Running gftools-builder sources/config.yaml on any compliant repo should build the relevant sources. This is how gfautobuilder (which I mentioned in your issue) works. builder2 is merged now. I'm seriously considering making a switch which makes the actual build-the-font operations use fontc instead of fontmake.

[simoncozens]

Repos based on the googlefonts-project-template will have a sources/config.yaml

This said, one thing I've found to be fairly common is that we have repos containing multiple font families. e.g. Big Shoulders has a subdirectory for Big Shoulders, Big Shoulders Inline and Big Shoulders Stencil. Each subdirectory has its own sources/config.yaml.

It may be useful to add a metadata field to the SourceProto to help distinguish how to build these things. Either:

• config: "We expecting every upstream to have a gftools-builder config.yaml, here is where it lives in the repo." This would be ideal but problematic on some fonts which have idiosyncratic non-Google build processes (For example, the SIL fonts which use their own build toolchain) and for non-commissioned fonts where we can build them from source, but we don't have the ability to put a config.yaml file in their repo.
• source_files: "Here are the arguments to gftools-builder, which may be a config.yaml for repositories under our control, and a list of font source paths for repositories we don't control."
• build_script: "Here are the commands to build the family."

@rsheeter @m4rc1e WDYT?

[rsheeter]

I immediately wonder if google/fonts could store the config for the cases where we can't get it upstream? Concretely, I'm imagining the SourceProto config that is able to distinguish local repo from upstream. It might not be modelled exactly like this but conceptually origin/path/to/config means it's in this repo, upstream/path/to/config means it's in the remote.

We would prefer upstream but not strictly require it.

[simoncozens]

I like that a lot. It means as gftools-builder advances we can very easily bring more cleverness into the build, and it helps us to build complex upstream projects out of our control, without requiring us to fork the upstream or keep pushing changes to them.

[simoncozens]

In fact it's even easier than messing with the SourceProto. If we have a config.yaml in google/fonts/ofl/whatever, use it, otherwise use theirs.

[rsheeter]

For the case of an upstream repo with many config.yaml do you need a field in SourceProto to allow specification of which one to use?

[simoncozens]

I now have the technology to do a lot of this "library-scale fixing": a way to rebuild fonts from source if we can, and a way to hotfix fonts/METADATA/OFLs/etc if we can't.

The question now is how to do this without overloading things. I suspect that a PR containing 1000 TTF updates and 200 METADATA.pb updates would cause an issue for the backend, but equally that 200 PRs would cause an issue for the onboarders.

@rsheeter any thoughts?

[rsheeter]

I think we can thread the needle a bit. Flex fonts, CJK fonts, and variable fonts with lots of axes are dramatically more expensive than static families. Maybe we start with say 1 PR with 10 "cheap" families and see how that goes?