I was not sure if this belonged in type business or type technology.
As a graphic designer, primarily working in print, I almost never use variable fonts and find them intimidating often. Or, more precisely, I don't have the confidence they will work as reliably as standard fonts, especially if I am working in a team sharing project files.
I'm aiming to work on a display face of my own design this year, and so was dreaming about how I would release this so-far-fictional design, and it got me thinking about variable fonts.
I was apologising to a type designer friend recently about my lack of use of variable fonts. They said most people are not using them, and it got me wondering if there was any public data that could shed light on the subject.
Do any resellers or foundries share this info? Have I missed a conversation about it elsewhere?
As available typefaces and usage grows, I think it will be interesting to see what kind of typefaces are popular, and for which media.
I have no information about how they perform in apps.
Use fonts in InDesign (adobe.com)
I occasionally run variable font stats on the entire Google Fonts library. The overall library has been growing steadily for many years, and is now at 1474 families. The past year and a half or two years, it was holding steady at about 18% of all Google Fonts families being variable fonts. But now it is at 19% (ok, 19.13% to be exact). This includes some of the most popular fonts available through Google Fonts, such as Open Sans, Montserrat, Oswald, the various Roboto families, Raleway, Inter, Nunito, Playfair, Rubik, Work Sans, etc.
The fact that "I have no information about how the perform on apps" is actually a GOOD indicator that they work fine in apps too. Because when thing don't work as expected we usually get complains very quickly (fox example when style linking fails in MS word, or things like that). So far no one ever complained to me about VF's on apps, so its pretty safe to assume they work pretty well everywhere. However: when developing you VF's: follow the Spec and test as much as you can before releasing, so you are in the safe side. And if something fails on a certain specific app, you can blame the app developers
(Not aiming this at anyone in particular )
I'm hoping that distributors will step up this year. Even if they don't allow users to adjust the sliders, they could at least allow animated GIFs to demonstrate the capabilities. Some distributors, like FontSpring, FontBros, and Creative Market will accept variable submissions, even though they’re not currently displayed correctly. Monotype’s tool flat-out rejects them. At the very least, it should detect that it’s a variable font and override the overlap warnings.
Customers' trust when purchasing a variable font from a distributor is currently required to be especially high. I'm presently pricing them low since I don't believe the client should bear all the risk. It may not function with their programs and may cause printing issues, but it should be entertaining to experiment with. While adjusting weights, widths, and optical sizes is useful, there is also a world of gimmicks possible that can drive a designer's imagination, or at the very least provide some amusing dials to twiddle.
Does it make financial sense to release non-variable styles along with variable fonts? Probably not. But with some typefaces, the variable aspect could be the whole point. If all we’re really providing is finer weight and width adjustments, nobody’s going to get excited about this. Take a chance, do something interesting with variable fonts, and push this forward. That’s the only way we can get the distributors to step up and support variable fonts.
There are some typefaces for which doing variable fonts is easy and obviously helpful without being terribly difficult. Maybe it has just a weight axis, or just weight and optical size, or weight and width. In some senses it is a packaging question for the foundry.
Then there are typefaces which are highly impractical without variations technology, because the dynamic range, with so many axes, would just result in too many separate fonts. All my type design work (as opposed to forensic work) the past three and a half years has been solely these kinds of fonts: a four-axis family, another four-axis family, and currently working on something with five axes, as a semi-background project.
In related news, Adobe Fonts finally added variable font support today, along with their first 122 variable font families, including 10 or so from the Adobe Originals (yes, the full variable releases of Myriad and Minion, . The interface has sliders and the usual sorts of things. Aside from an oddity about defaulting to the minimum on every axis, instead of the settings of the default instance, it looks pretty good. (OK, it also has the frickin’ stupid idea that each slider is on a pop-out, only one can be popped at any given time, and it obscures the current setting of the axis below it. Sigh.)
We (at Type Network) accept them and have a nice UI for trying out the axes. I’m sure there’s a better version in our future, but we like it. We just need more people to notice!
Now, it it possible to insert intermediate sources at a more reasonable spot in the design space (and make that the default), however this comes at the expense of added file size. Many projects based on older source data (like Kepler, Myriad, etc) do not have intermediate sources, therefore the default, representative style is – for better or worse – Light Condensed.
You also said “yes, the full variable releases of Myriad and Minion” — I wish this were true.
Recommended or required “Regular” value: 400 is required.
And below that it says
In a variable font that implements 'wght' variations, the value in the usWeightClass field of the OS/2 table must match the default 'wght' value specified in the 'fvar' table.
None of that says the wght axis default is 400. The default is whatever you want it to be. To be compliant you must also define a so-called "Regular" instance at 400 which is something fontbakery checks for, but nothing says that 400 must be the default.
I think I was also imprecise about the difference between default and regular, and not communicating the clarity I kindly think you are missing
The default master ending up in the glyf table is a technical detail of implementation.
What users expect is the Regular weight 400, Regular width 100, etc. That isn't necessarily any master location. But it is what users expect to see as the style rendered when nonaxes value are input.
It's possible that Glyphs automatically adds a master at the location when you use the "Variable Font Origin" custom parameter. You should notice a difference in file size. Correction: In Glyphs, you can only point the "Variable Font Origin" to masters that exist in the file. So you couldn't set a Regular origin if your only masters are wght=100 and wght=900.