google / google/fonts

Proposal: more precise metadata on font sources

Open
#9,257 6 comments 0 reactions 0 assignees View on GitHub
-- Needs Eng team opinion -- Needs manager's opinion I API / Website / Platform I Tools / workflow / repo
Dominant language
HTML
Stars
20.5k
Forks
2.9k
Avg merge
1d 21h
Merged PRs (30d)
95

Description

We are working towards a goal of building the entire library from sources and, for that reason, we should have more precise specifications of the exact version of the font sources that were used to build the latest releases of fonts pushed to the GFonts API.

I'll use Aubrey font family as an example here.

[ofl/aubrey/METADATA.pb](https://github.com/google/fonts/tree/main/ofl/aubrey/METADATA.pb) currently specifies `repository_url` + `branch`.

![Image](https://github.com/user-attachments/assets/90525d73-ea42-4ffd-b931-8f890b2e8f89)

Keeping a `branch` value is imprecise because it is a moving target. The contents of a branch can change over time.

We should at least specify a commit hash using the `commit` field that is already available for usage on METADATA.pb files.

(We can see at https://github.com/cyrealtype/Aubrey/releases/tag/v1.102 that the latest release was built from commit [1946b0d99c0fec87702a59afc8b5b941a32e0171](https://github.com/cyrealtype/Aubrey/commit/1946b0d99c0fec87702a59afc8b5b941a32e0171))

But perhaps it could be good to be even more explicit and set a (yet to be formalized) `tag` field, like this:
![Image](https://github.com/user-attachments/assets/4735e885-1869-45e7-966a-1c73643b9d46)

I believe that with the current gftools-packager workflow, we always have a tag pushed right before publishing a family release or update. Maybe we would still have to rely on commit hashes for very old families that have not been updated recently. Other than that, usage of branch names or commit hashes should be discouraged. And we could have a fontbakery/fontspector check for that.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.