Google Fonts is the most-used font platform. According to the 2020 Web Almanac (HTTP Archive’s annual state of the web report), 70.3% of websites using font-hosting services use Google Fonts.
As seen in Google Fonts Analytics, the sum of the total views for the fonts in the Catalog increases every day and is currently above 60 trillion views per week (by June of 2022), where many fonts have over a hundred of millions views per week.
Getting a font family published on the website means it has to be included in the GF API for them to be served to websites at that range of views per font. Therefore, GF requires all families to pass a range of checks that ensure that they work well under a wide range of different environments and for a high proportion of users.
Google treats fonts with the same level of care as they do software.
Google Fonts is doing its best to ensure that publishing or updating fonts are unlikely to break existing documents or websites. Thus, you must follow some rules, which have been adapted from Joel Spolsky’s classic article The 12 steps to better code. Joel’s article explains the benefit of these requirements.
Fonts to be onboarded to Google Fonts are expected to abide by the following requisites:
The design source files (plus scripts) are available in your preferred font editor format.
The file formats most used are UFO, .glyphs, .glyphspackage, fontforge or fontlab 7.
.glyphspackage is preferred over .glyphs due to it being easier to work with in version control (Git). Fontlab V files must be converted to another format because the software runs only on older OS versions. If you are using any font format other than .glyphs, .glyphspackage, and .ufo, include a build script that converts the sources to UFO, and include the UFO sources in the Git repository. Use Fontlab to UFO or FontForge to UFO for example.
Fonts should be built using open-source tools.** This ensures that they can be built under the same conditions on any platform.
Fonts should be built in one step. All GF font production tools can be run from the command line. This allows to use them to generate font families by running a single command.
If the build process necessitates more than one step / one command, then every step needed to build the fonts should be included in a single build script. See the chapter about building fonts for more information.
Font builds must be repeatable. Given all of GF tools are written in Python and distributed using pypi/pip, this allows to use specific versions of each package, ensuring the same conditions for each build with the same quality of results.
Projects are kept in a version control system. Since GF only releases Open Source fonts, each released family is expected to be hosted in GitHub and have its own upstream repository.
CI (Continuous Integration) should be used for build and testing purposes, applied to fonts. GF main repository github.com/google/fonts uses CI. When new fonts are pushed, the CI will run a test suite (gftools qa, which is a wrapper around Fontbakery and various other proofing scripts), and the results will be reviewed.
Issues and reported Fails should be fixed before publishing or upgrading.
Reviewers of the Pull Request should have knowledge about typography and font software.