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?
2
Comments
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
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.
@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.
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.
The question is, does the user need unreal 800 variants? Wouldn’t be easier for them to choose between 50 real variants?
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.
#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.
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?
Talking as a font user, I find working with variable fonts tedious and slow. UI is probably part of the problem too.
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.
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.
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
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.
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/
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).
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....