Phinney on Fonts

Tag: variable fonts

  • Variable Font UI is Broken

    in Adobe CC, Affinity, CorelDraw… & most apps with “live” interactive interfaces

    Many major graphics/​publishing apps have made some poor user interface choices for variable fonts. Given the ongoing steady growth of variable font usage and availability, it seems worth fixing. The biggest problem, and the easiest to fix, is lacking ongoing access to axis settings while working with text. Other issues include maintaining common settings across fonts, and accessing the pre-​set meaningful axis values while using sliders.

    How common are variable fonts, anyway? Variable fonts make up 28% of all fonts available on Google Fonts, but only 7% of Adobe Fonts (as of mid-​2026). The percentage is smaller on MyFonts, but with over 3000 variable font families there is still a dignificant number for those who like the technology.

    Note: I will gladly give app-​specific advice and feedback to any developer who would like to discuss/​improve their application’s behaviors in this area.

    The Variable Font Settings panel

    Ongoing Settings Access

    Variation selection needs to be just as easy to access as selecting a font style, because it is essentially the same thing. But putting the detailed variation settings exclusively on a transient pop-​up/​fly-​out menu, which goes away as soon as you click anywhere else, including on other text is a bad idea. This creates an extra click… Every. Single. Time. …one wants to do this thing that needs to be done constantly.

    The temporary fly-​out in Adobe InDesign; many other apps are similar.

    Do you want to replicate settings from one place somewhere else, or base settings on other settings, without using character or paragraph styles? Too bad.

    A variable font instance is ~ equivalent to a font style. Apps generally let people click in any text to see exactly what font style is currently selected for that text… except when the selected text is in an instance of a variable font, which is set to something other than one of its predefined instances.

    Variable font axes offer continuous ranges to choose from, and often two, three or more of them. Because of this, one often looks at what one has already done, axis-settings–wise, to figure out what to do next.

    Users need to be able to play with and explore variations. When we click in some text or on a text box, we often want to instantly see what the variation settings are for that text. All of these things require an option or route to have the variation settings not be solely a pop-​up that is only active when you move your pointer over and click on it in the character settings.

    It mostly isn’t that the elements within the typical pop-​up settings interface are terribly wrong (modulo some refinments, see below), but the biggest thing is just their transience. Perhaps it could be a part of the same panel that has font selection/​formatting controls, that is available whenever a variable font is selected.

    (Figma almost has this, because its relevant panel does stick around. But… the panel has three mutually-​exclusive tabs, and the “variable” tab goes away when you don’t have a variable font selected, whether it is a non-​variable font, or some other kind of object entirely. And of course, if you come back to a variable font after, then what you get back is the default “basics” tab that is up. Sigh.)

    Making Stop Points Visible

    The other oddball thing is, most apps just pop up sliders, with no indication as to what the values mean. Sure, you have a weight axis, but no indicator as when you are using a slider as to what particular weight is Semibold (for example). Fonts have two ways of indicating such standard values on axes.

    The one people are most used to is a list of static styles, equivalent to a style name or menu name for a single-​master font. Each such style is a specific combination of values.

    On the plus side, when you get all your slider settings lined up with a named instance, InDesign and Affinity Publisher do show you the current instance name. That is nice.

    Integration

    One argument some typographers have with current interfaces is, they still treats variable fonts as some sort of second-​class citizen. These can be the most powerful and versatile fonts your users have access to… if you treat them appropriately.

    One part is making features more visible, as discussed.

    Another is doing new things with existing features. Or even doing old things that have been forgotten. That can mean using the hz justification algorithm with width axis character stretching/​condensing (good) instead of just distorting text (highly questionable and not what Zapf designed). 

    Or another riff on the same idea: offer an auto-​fit-​to-​line-​length option for headings that makes use of the width axis if available—great for some kinds of display typography. (I did this manually last night for a t-​shirt design, and it seemed silly that it was not a built-​in app feature.)

    Menu (or named stop points) per Axis, using Axis Value Tables

    Variable fonts can have a set of specific named instances. That easily enables a single-​menu selection model. But when three, four or more axes are available, naming every reasonable instance combination is a bit unwieldy from the naming end, and even more so in terms of selecting dozens or even hundreds of styles from a single menu.

    Conveniently, variable fonts have a STAT (style attributes) table. This also allows for Axis Value Tables (within the STAT table), that define stops along each axis in and of itself.

    With a slider approach, such stops could be highlighted on the sliders of the variable font settings pane, perhaps with some slight “snap” to make them more easily selected (e.g. if the slider is being moved via drag, and that value is within 1% of the slider range, jump to it).

    For example, in a typical font with a weight axis, the 100-​unit increments tend to correspond to named weights (e.g. Thin = 100, ExtraLight = 200, Light = 300, Regular = 400, etc.), and it would be nice if there was some way to show this on the weight axis slider.

    Menus and Axes

    Further to the above, if there are more than two or at most three axes, the font is not going to even try to put each and every combination into a named instance for menu purposes. My most recent projects for example:

    Google/​Material Symbols: 7 weights x 4 sizes x 3 (or 4) grades x 3 roundness = 336 styles (or “only” 112 if you separate the roundness into separate families) 

    Science Gothic: 9 weights x 9 widths x 3 slants x 5 contrasts = 1215 styles

    An app could consider putting each axis into its own menu and have a style menu per axis. I am not certain this is good and needed, but I would sure love to be able to try it and find out if it is a Better Way.

    The general idea of storing each axis setting as a separate font style attribute, though—that is good and powerful, and a clear way forward for apps in general… see below for what else that might help enable.

    Apps & Axis Settings

    Switching Fonts

    When one switches from one font to another, versions of InDesign, Illustrator, Affinity Publisher and CorelDraw that I tested aren’t smart enough to preserve axis values, even if the other font has the same axes and supports the same values. This may seem like a corner case, but consider that in many variable font families, the upright and italics are separate fonts. (Yes, they are also sometimes in the same family, if it has an “italic” or “slant” axis. But both scenarios are common.)

    Mind you, many apps won’t even let you use their standard keyboard shortcut to swap from regular to italic (or the reverse) when a variable font is in play. Adobe Illustrator does—but all the other variable font settings reset to their default values when you do this. This rather spoils the point of the operation: switching between upright and italic while keeping the other variable font settings the same.

    When you are switching between two typefaces that have at least some of the same axes available, and the same settings available in the second one, the app should maintain those settings. I tried this with many fonts in multiple apps and had no joy from any of them.

    Sure, don’t worry about axes they don’t have in common, but for axes they do… preserve the settings when switching fonts if you can. At least, preserve any axis setting that is at a non-​default value. (OK, that shows that there are potential subtleties and questions here. But that is no excuse to just leave the situation at Maximum Awfulness.)

    Axis Granularity vs Standard Values

    Over in Affinity Publisher, the axis sliders are given a surprisingly coarse granularity. Each slider has a maximum of 21 stops, so an axis with a wide range “jumps” pretty coarsely. This has interesting side effects in terms of one being unable to stop sliders particularly close to desired or standard values. If a font has a weight axis that goes from 100–900, the weight slider is going in 40-​unit increments, one can’t quite get within “can’t tell the difference” range of Regular (400) with the slider, as it stops at either 380 or 420. Instead you have to manually enter the number. Not the end of the world, but a bit weird, and undesirable.

    Adobe does only somewhat better in this regard, with jumps fine enough that they seem almost continuous. But one still can’t land right on the named values, even though 401 or 398 is close to 400.

    Other Issues

    Optical Size

    Every app should offer an option to automatically use the correct optical size setting for the current point size, when using fonts that have an optical size axis. This should be on by default, both with text in new documents, and in the style settings when creating a new paragraph style (and perhaps character style?).

    The more advanced version would be to even let users select relationships 

    Copy/​paste

    I know it is too much to hope that copy/​paste between apps will always maintain variable font custom axis settings. But maybe at least between apps from the same vendor? And certainly within the same app.

    InDesign width axis and hyphenation

    When one has a narrow text block in InDesign, in a language that it knows, with hyphenation on, and adjusts the Width axis on the first couple of words, it can do some truly bizarre things with breaking words via hyphenation, when the whole thing could easily fit. I hit this when trying to put a small variable font showing in the family winter holiday card… it was sufficiently frustrating that I ended up starting this blog post last year, instead of continuing to work on the family holiday card.

  • Why Variable Fonts Will Succeed

    Third time’s the charm? Why OpenType Font Variations (variable fonts) will likely succeed where predecessors failed.

    OK, this is kind of funny: a post I wrote in November 2016 that languished in my “drafts” afterwards when I was busy with work, waiting on illustrations/​graphics that I never did add. Just for fun, I’m going ahead and publishing it exactly as is, showing what I was thinking at the time, just after Variable Fonts were announced. The only other note I want to add is that if you want to play with variable fonts, check out Axis-​Praxis.

    OpenType 1.8 was announced in September, featuring variable fonts. In short, variable fonts allow for packaging an entire family of fonts in a single font file, using master designs and interpolating between them, on what are called “design axes.” The type designer who makes the font can use this for whatever they like, but varying weight or width are among the more common standard uses.

    What makes this exciting is that in a savvy environment, someone using the fonts can specify any in-​between variation they like, within the “design space” (dynamic range) covered by the font. So for example, in a font with weight and width axes, a user could dial in the precise degree of boldness and level of condensing or expansion they desire.

    Font families built as variable fonts are vastly more flexible than before, yet can use less file storage than traditional font families—vastly less if you have large, complex families with a ton of styles.

    More details:

    Which is all very well, but this kind of tech has been tried twice before: GX Variations (the basis of the new tech) from Apple, and Multiple Master from Adobe. Neither ever got very far. Why should this time be different?

    First, I will note that when it comes to traditional design, it is only when there is support for the designer/​user picking their own arbitrary instances from the design space of the font, rather than just relying on pre-​specified instances, is there a benefit to designers. This means that traditional desktop design/​authoring apps need to implement sliders or some user interface to reap the benefits of the technology (although this is not so much of an issue for the web).

    Second, the other benefit of variable fonts, more compact representation of large families, was barely noticed the first time out. But with web fonts being a big deal and file size a huge concern, this is a newly important benefit.

    So, right off the bat, it is clear that it is more work to make this work with desktop apps, and that the circumstances make the web benefit more and get easier adoption.

    Speaking of adoption, it is worth noting that neither all existing nor all future font families need to be delivered as variable fonts for the format to be useful and successful. It may always be a minority of fonts available, yet still be a success with strong niche use in some areas (such as web design).

    Why GX Variations Failed

    Apple introduced what is essentially the same tech back in 1991, as GX Variations, part of TrueType GX. While many other aspects of TrueType GX survived in varying degrees, I can’t even find a good list of GX Variations fonts. I know only three offhand: the OS-​supplied Skia GX (by Matthew Carter), the Monotype demo masterpiece Buffalo Gals (by Tom Rickner), and Adobe’s Tekton GX (by David Siegel).

    GX Variations, in its original instantiation, would have required apps to give up control of their line layout to Apple’s line layout engine. Of course, this would also mean that any such app would have been Mac-​only. Although there are certainly some Mac-​only design apps, the Mac-​only aspect meant that the relevant heavyweights of the era, Quark and Adobe, never supported it.

    Apple supported GX with font dev tools, but they were largely command-​line based and hardly designer-​friendly. None of the font editing tools of the era supported GX Variations, either.

    With only a tiny handful of demo fonts, no major app support, and no major font tool support, GX Variations has never seen much pickup.

    Why Multiple Master Failed

    Adobe developed their multiple master (MM) tech at the same time as Apple did GX Variations, but completely independently. MM is a slightly less sophisticated/​complicated version of the same concept as GX variations, handled as an extension to Adobe’s PostScript Type 1 format. The MM technology was even briefly (1996–98) incorporated in the original OpenType spec, although only for OpenType fonts with PostScript outlines.

    MM did a tad better than GX Variations in terms of real-​world use. There were 27 families offered by Adobe in the MM format, one by Monotype, and about eight free families from four different independent designers. Adobe also used MM internally in Acrobat’s font-​substitution technology. Illustrator added “sliders” for MM fonts, but only just before Adobe pulled the plug.

    And pull the plug, Adobe did, back in late 1998. Adobe was already moving away from Type 1 fonts, and they withdrew the MM functionality from OpenType. The then-​manager of the Adobe type group, Dan Mills, believed that OpenType adoption might be significantly hampered if we were telling people they had to support this major added complication in order to properly support OpenType. Plus, OpenType ally Microsoft had never been very enamored of MM and had no interest in the tech at the time. So, Adobe pulled the plug.

    Why didn’t MM get better traction before that? Well, it was an Adobe invention competing with a similar Apple technology. The folks on the Adobe font team failed to realize early enough how important it would be to actively evangelize this technology to Adobe’s own apps as well as outside apps, and devote real resources to that effort. Because Adobe apps competed with third party apps, this hindered Adobe outreach to third party app developers. And few others were involved and supporting MM, outside the Adobe type team: it was an Adobe thing.

    Axis-​based Fonts Behind the Scenes

    Although development of new MM fonts ceased around 1998, many type designers saw that axis-​based font technologies were very helpful in developing large families. Crude support in Fontographer followed by more sophisticated support in FontLab allowed type designers to use MM capabilities to design fonts. It is simply easier to design two weights and interpolate the rest, than to design three, six or ten weights separately. If one adds in width variations or other axes as well, that can further multiply the savings in design work. One doubts that Robert Slimbach would have designed 156 styles of Kepler individually!

    Even more sophisticated tools emerged in later years, such as Erik van Blokland’s Superpolator.

    As a result, even while MM and GX Variations died off, and only about three dozen families used those technologies, scores more families have since been developed using the exact same concepts—just upstream in the design process.

    Other Lessons

    Two other font technologies have launched later, and were informative in their own ways.

    The Microsoft/​Adobe collaboration on OpenType, which later widened further into an open standard, has done well and become the primary font standard for the future. Many choices made in that process reflected learning from the MM and GX history, and it shows.

    More recently, the addition of color font support to OpenType has been more disjointed; I blogged about that at some length, explaining how this served as a bit of a wake-​up call to the big players as far as the need to cooperate and collaborate on variable fonts.

    What’s Different with Variable Fonts

    Variable fonts are being backed from Day One by a much broader coalition than ever got behind MM or GX. The same four players who came up with four different solutions for color fonts are backing a unified approach to variable fonts. Apple, Microsoft, Adobe and Google made the initial announcement jointly (at ATypI 2016 in Warsaw), with representatives of all four companies on stage and presenting. Every one of the major players in type design tools and related utilities (including my company, FontLab) have already started implementing support, many of us having started that work before the announcement.

    Assuming Mozilla joins in, this stuff is just going to work in all the latest web browser versions in pretty short order.

    Because of the ongoing behind-​the-​scenes role of axis-​based fonts in development of regular fonts over the past 15-​20 years, many type designers already know how to design type families in this way, understand the flexibility and power inherent in variable fonts, and even already have existing type families that could be “relatively easily” re-​issued as variable fonts (with varying degrees of added work).

    There are no guarantees. The variable fonts story still has some weaknesses, notably around formatted text interchange, and of course with desktop app support for an interface to interact with the variability. But the odds are good of at least moderate success. The alliance supporting it is strong. There are significant benefits, albeit not as compelling as OpenType as a whole.

    Some Predictions

    • Variable fonts will see rapid adoption in a few very high-​impact and high-​visibility places, including as system fonts.
    • Variable fonts will take a little time to become popular or widespread on the web, but some sophisticated and design-​intensive web sites will love them.
    • Within three years, variable fonts will become a common format for many new fonts, particularly for large or sophisticated families from major foundries and high-​end boutique foundries. But for (at least) the next few years, the same families will usually be issued as static (non-​variable) fonts as well.
    • Success of variable fonts is partly dependent on app support. Thanks to subscription models for Creative Cloud and Microsoft Office (and live app updates for Google Docs), any support from apps will be rapidly seen by end users, but… these big companies tend to operate in fairly siloed ways. Cool though this tech is, it is unlikely to attract the attention that results in a top-​down dictate from on high that everyone in the company must support it. This means that the Adobe, Microsoft and Google fonts teams’ support for the fonts is no guarantee at all of front end app support by Creative Cloud, Microsoft Office or Google Docs. Such support, or the lack of it, will influence type foundries in their adoption.
    • Because Apple’s existing GX Variations represents a large subset of the variable fonts technology, system-​level and desktop app-​level support for variable fonts is likely easier for Apple than for just about anyone else. Yet I still won’t bet on how quickly Apple will support this in iWork (their Keynote, Pages, and Numbers apps).
    • Very few foundries, and no large ones, will release what Ben Blom calls “static variable fonts” that in essence prevent interpolation and work like a family of old static fonts while preventing user interpolation. It misses on the big advantage of variable fonts, which is the ability to pick arbitrary points in the design space. The sole advantage of such fonts is smaller file size, but potential (or actual) user confusion will cause most foundries and users to avoid this experiment.
    • Variable fonts will not be the majority of retail font revenue ten years from now. They will not completely displace static fonts any time soon, if ever.

  • The Lesson of Color Fonts for Variable Fonts

    Today’s announcement of variable fonts in OpenType 1.8 represents a renaissance of the functionality of multiple master and GX Variations capabilities in mainstream fonts. With the announcement made jointly by Microsoft, Google, Adobe and Apple, it also marks a surprising and new level of multi-​company cooperation in font standards, at a level I for one have never seen in my nearly two decades in fonts.

    The need for increased cooperation has been brought home in the past couple of years with the lurching and dispersed movement towards color fonts. The idea with color fonts is that there are uses for being able to spec multiple specific colors in the glyphs of a font, whether for colorful emoji or multi-​color letters. For color fonts, there were four different approaches that all deployed and are now in OpenType. Microsoft invented one, Apple another, Google a third, and Adobe plus Mozilla a fourth. One can debate the merits of each approach, but clearly developing them in isolation and putting four competing approaches into the OpenType spec has not helped the adoption of any or all of them. (Apple originally said their approach was only intended for internal use and did not submit it for OpenType standardization, but changed their mind and submitted it at the last minute for OpenType 1.8, so the spec just went from three to four color fonts approaches.)

    In the end, although developing separately allowed for the secrecy and control, it did not yield an ideal long-​term outcome. Sure, each vendor can make fonts that work in isolation in their environment, but it should come as no surprise that users and font creators have been slow to embrace these color font solutions that worked with only  platform and limited browsers.It seems clear that the decision-​makers and reps of the companies involved were at least somewhat chastened by this outcome. I believe this lesson helped inspire increased cooperation on variable fonts.

     

    More reading: