Should we standardize on family names suffixes for static vs variable font families?
Current issue
Because variable fonts are new and still gaining support, some users need static fonts in software like InDesign or older environments (still very widely used).
Though we have standardized on an approach for variable font file naming, we have yet to standardize on a system for the typographic family names of fonts.
Currently, it is common for type designers to suffix family names with "Var" or "Variable," to indicate to users that these fonts are special. For instance, the latest version (3.4) of Inter builds to "Inter" (static) and "Inter Variable." Another example (not libre) is Upgrade & Upgrade Var from TYPETR.
Of course, @davelab6 has expressed the goal of showing variable fonts as the current standard, and showing static font as a legacy format.
Potential challenges with using "static" as a suffix, however, are:
- "Variable fonts" are getting a marketing / blogpost buzz, so users probably have a better chance to understand the suffix "Variable" than "Static." For a typical user, the term "static" may be even more ambiguous than "variable," and far less useful as a Google query.
- Static fonts enjoy wider support, so if we aim to keep things simple for everyday font users, it may make sense (for the time being) to keep these "legacy" versions as the current "main" / non-suffixed versions of fonts.
Question
Should we enforce a "Static" or "Variable" suffix in font names, or should we allow font designers to make the decision on their own?
I think its a upstream project decision what to call the fonts, but Google Fonts will have VFs that use the family name, unadorned, as the latest version of the family, and the API will transform the VF into static fonts for API clients who need static fonts; and in Github we'll include static fonts that have the same family name in their name table metadata - "Family" with nothing appended, and use filenames indicate the status, so that users can manage their font installation themselves.
While I encourage any upstream project to do the same, if upstream projects want to address the challenges you describe in another way, such as to have their name tables set up as "Family Variable" and "Family Static" or any other appended names, that is entirely up to them, and as a downstream we'll rename files and modify the name table metadata to meet our requirements.
For users, the same situation has been around for 20 year for OTF and TTF versions that share the same family name.
(I wonder if some upstreams could even start using the extensions .ttf and .ttv for static and variable fonts... After all, .otf has never been formally standardized.)
@felipesanches I think the Fontbakery action here is to add GF-profile VF-section checks that ensure 'variable' and 'static' don't enter our collection.
@davelab6
use filenames indicate the status, so that users can manage their font installation themselves. ...For users, the same situation has been around for 20 year for OTF and TTF versions that share the same family name.
I agreed with this in the abstract, but after testing and experience, I am convinced that Static suffixes are needed.
Why? The user experience of this issue of Var vs Static fonts is actually quite different from OTF vs TTF fonts. In the latter case, the OTF and TTF fonts are experientially the same – though the curves may be subtly different, I've never noticed OTFs and TTFs of the same family having different features, capabilities, or clearly different shaping. Also, apps tend to support both equally (in my experience) and don't show entries in a duplicate way.
By contrast, static and variable fonts have quite different capabilities. Currently, both have pros and cons. Unfortunately, this means that designers must install both static and variable versions of a family in order to actually use it – but without suffixes on the family names of one or the other, font menus treat this in an unpredictable way.
For example, if someone wishes to use a font family, they might want to use the variable version in Sketch but also have access to the family in some apps that don't really support variable fonts (e.g. Figma) or don't render them properly (e.g. InDesign, Illustrator, etc). However, installing both yields strange results, if no suffix is present. It's unclear which family is which, and selecting one may actually activate the other.
In the case of Inter (without suffixes), this leads to double stylename entries in apps like Sketch and Keynote. In Sketch, the variable axes are only available if I select the correct stylename:

In the case of Recursive v1.031 (permalink), which doesn't use suffixes, there is an even worse problem: once you select a static family, it becomes impossible to select the normal VF at all. This is likely due to postscript names matching exactly.

In InDesign, some characters of Recursive are rendered quite poorly. The TDH here are very bad:

Of course, part of this comes down to software needing to improve. But also, people may continue to rely on old versions of software for any number of reasons, and therefore miss the perfect future reality of variable fonts in those apps. So, the problem is very real, and not going away soon. Therefore, I strongly think we should have a single, clear, unified way to differentiate static families. And, until there is a consensus built into FontBakery, every type designer making a VF for Google Fonts will have to stumble through the same painful process of not being sure what works and what will make sense to end users.
My proposal:
- Static fonts should append
Staticto the end of family names. As an abbreviation,Stmay be used instead (unless there is a clearer abbreviation? I can't think of one so far).
In the case of Inter, this would result in the following family names:
- Inter
- Inter Static
In the case of Recursive, this would result in the following family names:
- Recursive
- Recursive Sans Linear St
- Recursive Sans Casual St
- Recursive Mono Linear St
- Recursive Sans Casual St
Files would look like:
- inter[slnt,wght].ttf
- InterStatic-MediumItalic.ttf
- recusive[ital,slnt,wght,CASL,MONO].ttf
- RecursiveSansLnrSt-ExtraBold.ttf
- RecursiveMonoCslSt-MediumItalic.ttf