Google Fonts

Axis Registry Protocol

🕷 Type designers are familiar with the five axes already defined by Microsoft in the OpenType specification. However, for each new variable font that type designer develops, it often introduces new axes. In order for a family introducing new custom axes to be added to the Google Fonts API and Catalog, each axis it offers must be “registered” – it must have a definition in the GF Axis Registry.

The requirements and principles of axis definition have been established mainly by a cross-functional group of fonts team members by Q3 2022. This protocol provides a guide to handling it within the font project as part of the onboarding process to Google Fonts. It offers detailed information on the required information, how to define it, and the required steps.
Background reading:
must→ Variable fonts specifics

Table of contents


Discovering innovative ways to use technology is at the core of OpenType Font Variations. The format opens the possibility to all sorts of combinations of shape changes controlled under the new font capabilities. With this big encouragement to creativity, it is common for type designers to think they could just come up with new axes all the time, but Google’s position is that there should be efficiency of resources whenever they could be applied. If three fonts can use the same axis, that is preferable to having three different axes.

The “Don’t Repeat Yourself - DRY” principle from software development comes at hand to understand the benefits of avoiding duplications to reduce contradictions, miss-implemented code, and potential developer confusion.

From selecting the axis name, tag, or description, to the type of range, it’s always necessary to find a balance between the current project demands and the further uses the axis could have. Thus, the reusability principle and keeping the end-user at the center of the decisions become essential to make it simpler and easier to understand, select and use the fonts and their axes.

This protocol covers the end-to-end process of discussing, reviewing, and uploading new axes and attempts to mitigate possible causes of conflict, such as:


The following are the required steps to register a new custom Axis into Google Fonts Axis Registry

1. Validate the incoming custom axes against the Axis Registry.

The first step required is to inspect the current GF Axis Registry and the Knowledge/Glossary page (search for “axis”) to determine if there is already a custom axis that could be used for the variation purpose on the font. We should ensure it is not a duplicated concept. Then according to the findings:

2. Modify the current axis registry to cover the needs of the incoming font.

Derived from case 1.2. If a registered axis matches the function and name but not the range values of the incoming axis, then the following could be applied.

3. Registering a new custom axis

Derived from 1.3 and 1.4. If there is no other registered axis that matches the needs of the upcoming axis, then a new axis should be registered. Read the below contents with details on the Axis Requirements and the process to include it.

Axis Requirements

The following are the requirements for a new custom axis to be registered, with expanded details about the Axis Metadata Fields that should be included in the .textproto file for the axis.

Types of axis

Identifying and selecting the accurate type of the axis is crucial for the axis definition. The type of range and its values play a key role in communicating a better sense of the purpose and use as well as the reusability of the axis.

Continuous Range axes

Commonly percent (0..100) or “per mille of em” (0..1,000). Within ranges, two subcategories could be defined: Relative and Absolute.

Relative range axes

The default is usually always the same, e.g. 400 wght, 100 width, 0 mono. For new expressive axes, the default range for these is likely to be a percent range 0..100, and probably with a 0 precision value (meaning no decimal places). The default might be 0, 50 or 100 depending on if the axis is adding something that usually isn’t used, something that usually is used but can be turned up or down, or something usually used that can be removed. Width is unusual as a relative percent range, as it has 100 as default and goes up and down from there.

Going forwards, we would like to see the registry more consistent. Most of the upcoming axes are likely to be Relative ones with a percent range since users are more accustomed to thinking about things in terms of percentages (particularly for technical stuff) and more comfortable with integers than decimals. Hence, pseudo-boolean axes are expected to be avoided or rather exceptions.

Absolute range axes

When the value corresponds to some measurement of the font, often a specific length of a specific form of a specific reference glyph. For example the distance from the bottom to the top edge of the extrusion of a 3d-looking typeface like Nabla, which is the same on every glyph, but the square edges of “H” are a good reference; or the Font Bureau Parametric Axes like Y Opacity (YOPQ) which measures the bottom to top edges of the bar of the “H.”

The default range of these axes is typically “per mille of em”, 0..1000. Most fonts use a UPM of 1000, so there is a 1:1 map between the “font units” the type designer draws with and the “slider units” the design app user interacts with. If the font uses another UPM, say 2048, which is the original default for TrueType fonts, the font units can be easily scaled/normalized.

Per mille values not only have 100s of years of history in typography, but also the (mental) arithmetic is more straightforward. For example, if you want to make a 2pt rule and adjust the typeface so that at 36pt size the bar of the ‘H’ is 2pt and the size of the extrusion is also 2pt, with the axes mentioned above.

Absolute axes, by their nature, have no meaningful per registry/library default because the default value is unique to each font’s default instance’s reference glyph shape’s measurement. In these cases, the default value required could be set to zero, and it will always need a per family default override. Refer to the default_value in the Axis Requirements section of this document.

Axis registering process

Creating an Axis Proposal issue.

Creating a Pull Request for the new axis

Creating educational assets

Every custom axis included in the GF Axis Registry should have an entry in the Knowledge/Glossary page to provide more expanded information on the axis.

Therefore, additional educational information should be created to communicate more details on the axis concept and use. These assets could be added after the font family introducing the axis is pushed to Production.

Foreseeable scenarios

Over time, following the AVAR 2 table development, it is expected type designers will combine the axes in many ways to create synthetic ones and make, for example, the OpenType features as variation axes.

This would allow for the user to choose things like the size or thickness of features like Old Style Figures or Small Caps. This approach would also reduce the file size as the data for these axes does not exist; they are composed of the combination of other axes. Roboto Flex is 1.8 Mb, but Roboto Flex with avar2 Is approximately 300 Kb, an 80% file size savings.

Eventually, the registry of those synthetic axes should follow the same protocol for their inclusion.

Similarly, eventually, Stylistic Sets could become a variation axis since for them to interact with another axis, they had to be an axis on its own. That is the case of the Wonky axis, which is an axis controlling glyph substitutions, but being it an axis it can interact with the Optical Size axis to activate it at discresion.

Named and fallback positions

Some fonts provide named positions on a custom axis. For example, the Element Shape in Handjet defines different shapes at each integer value along the axis (Triangle, Square, Lozengue, etc) and Kablammo’s design is centered around four named positions on a custom axis.

Named positions are similar to, but different than, fallback positions. Fallback positions were originally defined for the legacy axes, width and weight, to cover the axis values that matched the pre-VF world. Google Fonts creates static instances at each of the fallback positions and delivers them when a requestor does not support VFs. For example, when wght=451 is requested by a non-VF client, Google Fonts could deliver weight 500.

Additionally, fallback positions are defined on the axis and not on the font with the expectation that all fonts that support an axis will want the same fallback positions (very reasonable for legacy support).

All this makes fallback positions unsuitable for named positions, and have been reserved to the Microsoft OpenType registered axis (and will remain for the custom axis already registered in GF registry)

Named positions are not yet supported. For the time being, fonts will be published and delivered only in VF format without Named Positions and therefore without static companions on the downloadable zip file.

These are some links where you could find more detailed information about this Culture:

Further reading:
team  METADATA file