Variable fonts, axes values

María Ramos

Hi!
While working on variable fonts and looking at examples I was wondering if it is possible for font software and apps that support the format to identify steps in the variable design. I’ll try to explain it better. We use standard values for the weight axis, so standard weights can be easily used and identified on the web. Does it make sense to give the font user 900 unit variations for the font? Could we –type designers– select the values available in the variable font? Let’s say every 50 units in the weight axis, so there is a real and visible change in weight.
Are there any standards in units for other axes?
Many questions and doubts when handling units for axis... It just seems there is not enough thought on how to handle this and make variable fonts easier to use and also work better. Are we missing quality in those 800 variants? 

Craig Eliason

I may be misunderstanding you, but what you're describing sounds like named instances which can already be included in variable fonts. Or at least, named instances seem like they'd accomplish what you want, without taking away user access to custom instances in between. 

jeremy tribby

I was just having this conversation with georg in the glyphs forum in a different context because I'm a bit confused about it as well. I thought named instances were less generic than what is being asked about here (edit to clarify: named instance = specific locations in the font, what we are talking about = specific locations along a single axis?). if I understand the question right, we are talking about userspace names of single points on an axis.. which I think are are part of the axis value table, which correlates to an AxisLabelDescriptor in designspace format 5. whereas I thought the LocationLabelDescriptors were the named instances. but I'm still wrapping my head around it, it's pretty new to me.

Dave Crossland

Maria, if you want five steps in an axis, why not make it's range 1 to 5?

Erwin Denissen

Each axis is defined by a numeric range, using fractional values, so even within a 1-5 range there are unlimited values, like 2.753906.

From what I understand you want to provide information per axis. In that case you need to add Axis Values which can be used in a user interface to select a particular value for the given axis. Here is how it looks like in FontCreator:

You can even add multi-axis value combinations, so it is pretty flexible.

Simon Cozens

What you're talking about is indeed named instances. But locking the font to named instance steps with an avar table as Erwin suggests is really user-hostile. If the user asks for a 721 weight, just let them have it; they might, after all, know what they're doing.

Erwin Denissen

I don't think Axis Values limit the user, they just are a way for a user interface to cope with axis values.

In my opinion a variable font should contain both named instances and axis values.

María Ramos

Not talking about defined instances but the steps in a variable font (the number of variants). I’ll give you an example, the difference between 200 and 210 or even 220 in a variable font with a weight axis (100–900) is unnoticeable, so we are not giving more options to the font user but variants that have no value.

Eg. 200, 210, 220 weight axis (no particular order) can someone tell me at first sight what is the value in each column? And there are other 20 variants in between
If we do steps every 50 units instead, we start to see the difference. Still subtle in smaller sizes, but enough to make a difference and add value as a design variant.

Simon Cozens

María Ramos said:

I’ll give you an example, the difference between 200 and 210 or even 220 in a variable font with a weight axis (100–900) is unnoticeable, so we are not giving more options to the font user but variants that have no value.

In a variable font, there are infinite options for the font user by default; you are talking about taking them away and restricting them to a smaller subset.

A good example for why this is a bad idea is headline fitting. If a user is fitting a headline to an exact layout width, they might find that a weight of 700 is slightly too narrow and a weight of 750 is slightly too wide, but the typesetting software can automatically determine a width (let's say 732) that fits the available space perfectly. That's a good thing to be able to do. Don't disallow it.

María Ramos

I am talking about offering users a thoughtful type palette, instead of a huge number of options with no real value.

@Simon Cozens in your example there are other options. Look for example, line 2 and 3, 732 and 750 weight value, same width.

Open to hearing what are the real advantages of the system we have for variable fonts, in terms of unit-variants, as it is at the moment. I think we can improve it. It would be great if type designers and font developers can decide what are the type variants they are offering, adding a step value for each axis. I really think we would be helping users. 

Simon Cozens

You offer users a thoughtful type palette through named instances. You don't do it by taking away choice.

Florian Pircher

Say OpenType did add a ‘stepSize’ parameter to variation axes. Then, a font vendor could specify that the weight axis should only be selectable at intervals of, say, 50: 300, 350, 400, 450, …

The underlying mathematical model of variation in OpenType would still allow to compute a style with a weight of 379 or 536, but the stepSize parameter would instruct user-facing apps to prohibit the selection of such values. Some apps will be updated to respect this stepSize parameter, some will not, and some apps will deliberately never impose such a limitation.

Now you have to deal with legacy documents that use intermediate values that can no longer be selected. Or style guides that specify design space locations that are no longer selectable. Worse, because some apps will not respect the stepSize parameter (deliberately or simply because the developers consider variable fonts implemented and never change that part of the app again), new documents will be created that cannot be edited losslessly by apps that respect the stepSize. So now there is pressure on app developers to drop the support for stepSize since supporting this parameter puts users at a disadvantage compared to users of apps that don’t support the parameter.

Alex Visi

María, what makes you think that you restricting the users’ choice is good for all of them?

María Ramos

You are not giving users real choices, variants that do not make a visible difference are not a real choice, just a fake sense of choice. Those 800 unit choices are no real variants, as there is no difference for our eyes, printers and screens.

The question is, does the user need unreal 800 variants? Wouldn’t be easier for them to choose between 50 real variants?

María Ramos

@Florian Pircher of course this could be problematic for software support. The support of variable fonts is still an ongoing process, if we are proposing improvements is better now than later. 
Good to create debate around all these things. At least think about it, what are the pros and cons. And I am thinking of the pros and cons for the font user not for us as font developers or software engineers.

Alex Visi

I’ve never heard anyone complaining about color pickers faking choice by giving 1 px steps which look identical:



#0500FE is indistinguishable from #0500FF, but I haven’t seen anyone asking to ban one of them. Choice (even if it’s so granular you feel it’s “fake”) is never a problem, but restrictions are.

There are too many conceptual cons to this problem solving, especially with such not standardized thing as variable values: 5 units can be a good small step in one font, but too big or too small in the other. The axis can go from 100 to 900, but also from 200 to 400, depending on the design. Also, each axis has a different scale, italic can go from 0 to 12, for instance. Using a “relative” step is no better because it leads to float values (I want my 400, not 389.43432!), and if you decide to round them, that’s a whole other rabbit hole.

Adam Jagosz

@María Ramos Stick to static fonts if you hate variable fonts so much. Thanks for coming to my TED Talk.

John Hudson

The question is, does the user need unreal 800 variants? Wouldn’t be easier for them to choose between 50 real variants?

The user doesn’t have 800 variants. The user has a continuum of fractional values across a design space. The font maker can choose to label locations in that design space in meaningful ways, but can’t constrain the way the user interacts with the design space to discrete steps. That’s something that higher level software could offer to users, e.g. clipping variation instances to unitised values, which I can imagine being useful in a large organisation where lots of people are creating documents and you want to normalise the instances.

Thomas Phinney

To be fair, I think María does not hate variable fonts, she just has a different idea about how she thinks they are best used/implemented.

Like most of the people here, I am a big fan of the continuous-variation capability with very small increments.

My single most common use for it is, when setting a sans serif without an opsz axis, I can vary weight to make different sizes of text appear to be “the same” weight, regardless of the particular point sizes and exact ratios involved.

This would not work as well with 50-unit weight increments.

Also, I note that most users of variable fonts just stick with the standard instances supplied in app menus—or in the case of web fonts, common/large increments such as 100-unit increments for weight. So this question would not affect them, nor change their design practices. It is the minority who are doing more sophisticated things, and going out of their way a little bit to do so, who would be affected.

I am still struggling to understand the actual benefit of this restriction. We can already see that the status quo is not, in fact, creating some sort of awful chaos or problem. Or is it, and I just don’t get it?

María Ramos

Of course, I don’t hate variable fonts, just the opposite. I think they are great and open the path for much more experimentation in type design.

I may be the only one seeing the benefits (quality, functionality) of defining a proper design space, so the designer not only defines the extremes and instances but also how many variants (called it values is you want) are needed for a particular font. 

Talking as a font user, I find working with variable fonts tedious and slow. UI is probably part of the problem too.

Simon Cozens

For me, there's another philosophical issue here: creative progress often comes by using tools in ways that the manufacturer of the tool did not imagine, and by doing things that are "not allowed".

Alex Visi

María Ramos said:

UI is probably part of the problem too.

Adobe checked variable fonts off the list by giving you the sliders and went playing with iPads.

Thomas Phinney

Yes, many of the interface decisions have been… less than optimal. Ugh.

Some thoughts/background that you (María) doubtless already know, but for the benefit of less variable-font–experienced readers… and maybe you have not considered using the existing mechanisms in this way. Or you have and discarded the idea.  

The font designer can define both specific predefined instances, and known “stops” on each axis to present to the user. The predefined instances may well be a subset of all standard stops.

For example, in a font with four axes, one might have standard stops on all the axes. But showing all combinations of those as standard instances would be overwhelming, so a font developer could choose to only present (for example) the 9 weight variations as standard instances, times three widths, and nothing from the other axes. But on the individual axes, one could display not only standard 9 weights, but also the half-weight increments between. So that would display and encourage use of the particular weight stops María likes, at least in apps that provide that kind of interface.

Now it would not restrict apps from allowing access to the full range of values. So in some ways maybe it is the opposite of the “desired” outcome. But putting those stops actively in the UI might encourage their use, and obviate the need to actually use sliders or type other values? Just a thought.

This is all I can think of doing that is within the current OpenType spec.

Matthew Smith

If I am reading everything correctly, it seems that María mostly has an issue with the slider UI most commonly used to navigate the design space in variable fonts. In which case, I agree it’s not ideal but I don’t necessarily have a problem with it because I typically make adjustments in increments of ten by simply pressing Shift + ↑ or ↓ instead of using the slider.

André G. Isaak

I'm not a big user of variable fonts and I've found that whenever I have used them I've always stuck to the named instances rather than making use of the finer-grained control allowed by manually setting values.

In that sense, perhaps I share María’s view once you offer too many choices, the user is simply not likely to take advantage of them.

However, I think variable fonts have great potential if a large set of variation is available for tasks that can be automated by the application, such as line-fitting where the application automatically selected the best variant rather than requiring the user to experiment with a large design space.

Adobe briefly provided some support for this for Multiple Master fonts with optical size axes in a small handful of applications, and this is really the sort of place where a very large design space might be desirable and where I think the possibilities are currently underutilised.

Meanwhile, people like me can continue to just select from the named instances and ignore the sliders altogether.

Dave Crossland

The way I see it, there are 3 benefits of variable fonts. To compress, to express, and to finesse.

To compress a set of static fonts into 1-2 files, infinite choices are irrelevant. The only goal is replication of the original static fonts.

For the second, Maria is right that sliders offer a devil's bargain for many axes, the "paradox of choice" for which there is a real non parody TED Talk 15 years ago

https://youtu.be/VO6XEQIsCoM

Erwin has it right that the STAT table was made to solve this, and Maria has is exactly right in my book that poor UIs are a big problem for this, because often those that do offer access to named styles use only the flat list in the fvar table, not the nice per axis matrix of names STAT offers.

Eg, instead of a slider and at the end a little button to pop open a list of names styles along that axis, inverting it and having a wide list widget of named styles with a little button at the end to pop open a slider, might be way better for some axes.

However, I am wary of that because I think it invites "instance based thinking" to persist, which is a huge problem for me because I believe somewhat mystically that it fetters everyone's imagination as to new ways of using the new "mcluah medium". 

Which is mainly about the 3rd benefit, indeed, and which Simon has explained well here in detail.

For these second and third benefits, then, a stepping avar table that fetters access to the continuos space is something that I see as a nail in the wheel of the bicycle for the mind. 

María Ramos

Thank you all for sharing your thoughts. I can see the step idea can be a problem for the mind but not really for the continuum or finesse benefit. The steps would be defined not to show jumps but subtle changes.

IMO, one of the issues with UI for variable fonts is not actually the slider but how it’s displayed. Hidden at first and showing every axis as independent space. A few years ago, I shared some ideas on how to connect the sliders, represent the design space better and allow to scale one or several axes at once. Probably not ideal but there is indeed room for improvements https://www.alphabettes.org/design-space-variable-fonts/

Alex Visi

What I see as the biggest problem is a lack of convenient mechanism for reusing variable settings. No surprise most users stick with instances, who wants to set and maintain the values each time.

Saurabh Sharma

Maria's concern is close to the Hick's law, which says that the more choices you present your users with, the longer it will take them to reach a decision.

In CSS markup, there are no UI sliders. So a user will set the axes value directly by inputting a number in the font-variation-settings property. There is no provision of steps here. Step restriction is something which individual softwares can implement in their UI. (as Sir @John Hudson said).

Mark Simonson

I wonder if a numeric input field without a slider might be a better UI for variable fonts. Font size has long been variable, but font size sliders are rare in apps. Instead, there is a popup with "size instances" (typical point sizes) with the option to type a value. With variable font axes, maybe the value for each axis can be shown in each axis field when you choose an instance, just as the size field shows the currently chosen point size. Keyboard shortcuts for increasing and decreasing axis values would be nice, too. I often use keyboard shortcuts to increase and decrease font size.

Thomas Phinney

Riffing on what Mark wrote: I like that idea in some ways, but one advantage of the sliders is that it can visually show the available range (and potentially also show the default) as well as where one is relative to those things.

Size didn’t have a problem like that, as it is pretty obvious that the smallest size is somewhere near zero, and the largest… well, is technically unlimited, but the app or the design area may impose some limit.

Now, I do like the advantages of that approach as well....