Variable fonts, axes values
Comments
-
Hmmm. I also wonder if there's a problem with many VF UIs simply being too small. Eg...
As a picker, is the above better than the below?
0 -
Maybe show the small grid with a “+” button to expand the grid.0
-
1
-
See also the ideas in Intuitive Design for Variable Font Specimens.3
-
Both should be provided and even more. A slider is nice for a rough choice, look and feel. But maybe one thinks in numbers and proportions, or wants the same exact value in another place. Maybe in some situations it's more suitable to stepwise increase or decrease. Or fit to a "grid", i.e. precomposed intervals, which also could be named (regular, semibold, bold ...).Mark Simonson said:I wonder if a numeric input field without a slider might be a better UI for variable fonts.
The problem is not new and in most graphical applications it is solved. E.g. scaling an image provides most of the above options in the user interface of a good image software.0 -
They only have increment up or down for the matrix size in two dimensions. Compare it with a interfaces for product search, where you can specify for some features an upper and a lower limit (price, size, power etc.) This can be done with a slider, which also has incremental decrease/increase and an input field for an exact numerical value.Dave Crossland said:
There are ready to use widgets for it:
0 -
There is also a lot of experimental exploration by Underware: https://youtu.be/37fa5_zz-zw?t=19180
-
@María Ramos Is your concept of "steps" about standardisation within axes by the type industry? In the same way that we all roughly have an understanding of what "12pt" means in digital type?
Not sure I've understood, so let me try to explain in my own words.
When working with a type superfamily, a design "best fit" will rarely be perfectly fulfilled by an instance preset, and so we adjust this manually.
Example 1: The weight doesn't quite align with its alternate in a font couple
Example 2: The wordmark of a logotype is slightly too angular for its icon
Making this manual adjustment is fine for a one-off, but might be frustrating and cumbersome to calculate in the context of type hierarchies. In contrast, the distinction between each step in the axes of a superfamily is invaluable.
For example, what distinguishes a regular from a bold? In CSS standards, 'normal' is synonymous with '400', and 'bold' is synonymous with '700'. The difference is equivalent to a "step" of 300.
Let's say a typographer (in software like InDesign) would like to set the regular weight (redefine the default) to 450, which means the bold should step to 750 automatically. With steps, designs can approximate the intended distribution (e.g. the difference between each weight) whilst finding the optimal fit for each step in the axes.
Am I making sense? Does this align with your original post?0 -
Hi @KP Mawhood
By steps, I didn’t mean to be predefined by the type industry. I mean the type designer should be able to define how long the steps should be in each variable font. In your example the step would be 50 units, so for every 50 units, there is a font variant the user can choose. The step could be 30 units or less if the design space allows for more fine-tuning.
My original question was something like... why do we have 800 units (possible chosen variants) in a variable font (weight axis range 100–900) when more than 500 of them do not show any noticeable difference to the user?1 -
Got it, thanks! So, a type designer would define the variable steps in the same way a type designer can choose other metrics (e.g. UPM, defined instances, etc). This then translates over to end user UI so the graphic designer doesn't need to cycle through excess variations unless they specify this (e.g. as a fractional value).María Ramos said:I mean the type designer should be able to define how long the steps should be in each variable font. In your example the step would be 50 units, so for every 50 units, there is a font variant the user can choose. The step could be 30 units or less if the design space allows for more fine-tuning.
You're right, the values of the UI should be meaningful – and the present default seems like overkill for all but a handful of edge cases (which could then be specified by the type designer). I'm guessing there's a legacy rationale for this default, rather than a user-centred decision. Not sure why it's such a contentious topic.My original question was something like... why do we have 800 units (possible chosen variants) in a variable font (weight axis range 100–900) when more than 500 of them do not show any noticeable difference to the user?Simon Cozens said:
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.Surely, variable type is finite in terms of binary computing? By way of analogy, 255 variants for each RGB colour is more than sufficient for most use cases, even though it misses the granularity to fully cover ~16.7m colours. (strikeout due to misinformation).
I don't see why smaller iterations (steps of 50) would change the overall degree of variation presented by the slider, which could be accessed in a separate panel (e.g. paragraph style options). Big numbers confuse, that's why we simplify.
Rarely does a person pick out the right shade of green via a hex number.Alex Visi said:#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.0 -
My original question was something like... why do we have 800 units (possible chosen variants) in a variable font (weight axis range 100–900) when more than 500 of them do not show any noticeable difference to the user?Because the CSS weight range is defined as a number between 1 and 1000, so within the defined weight range of a given variable font as mapped to the CSS weight scale, any number is meaningful at the text specification level, even if it is not meaningful in terms of a noticeable difference to the reader.
I don’t disagree that steps are a useful concept in working with variable type, but as I suggested earlier it isn’t clear to me that they belong at the font level. You give the example of different fonts having different steps, e.g. 50-unit steps or 30-unit steps, but that won’t work. Apart from a series of 30-unit steps not aligning with the 100-unit steps of the nominal CSS weight instances, if different fonts have different steps, it becomes impossible to specify text and know what you are going to get if you change fonts. So e.g. if text is specified at a weight of 535, that could clip either up or down depending on how a particular font has its idiosyncratic steps defined. To be useful, steps either have to be standard or left to higher level definition. As others have pointed out, defining steps at the font level undermines the flexibility of the variable font format, which, given the quantity of fractional units available along any axis, is effectively that of a continuum rather than a stepped progression. Sure, one can say that a weight value of 535 might be indistinguishable from 525, but if it isn’t indistinguishable from, say, 505 then it is still useful, because the continuum means that no one is limited to predefined instances, and text can be spec’d on sliding scales.
1 -
8-bit color is not sufficient. All you need is a gradient or a dark area and you will immediately start to see “stair step” artifacts. Also, 0–255 for each RGB component does fully cover 16.777.216 different colors.KP Mawhood said:By way of analogy, 255 variants for each RGB colour is more than sufficient for most use cases, even though it misses the granularity to fully cover ~16.7m colours.
For many axes, the visual difference differs greatly between one end and the other. For example, on a weight axis, a step of 50 from 650 to 700 might not be all that impactful, but a step from 200 to 250 might be much more noticeable.KP Mawhood said:I don't see why smaller iterations (steps of 50) would change the overall degree of variation presented by the slider, which could be accessed in a separate panel (e.g. paragraph style options). Big numbers confuse, that's why we simplify.
So why impose such a restriction? There is no benefit to the font designer/vendor in limiting what axis positions are accessible by font users. Envisioning potential benefits for font users is a nice thought, but as discussed above, you cannot foresee all possible use cases. There are already use cases, again outlined above (legacy documents, animation …), that suffer from such a restriction.2 -
You're right, my bad. Thanks for pointing that out. 👍Florian Pircher said:
Also, 0–255 for each RGB component does fully cover 16.777.216 different colors.
Ease of use. Cartographic maps could hold much more information than they do, but it would render them less practical. Instead, consider the user level. Undoubtedly, some use cases will specifically benefit from more information.Florian Pircher said:So why impose such a restriction? There is no benefit to the font designer/vendor in limiting what axis positions are accessible by font users. Envisioning potential benefits for font users is a nice thought, but as discussed above, you cannot foresee all possible use cases. There are already use cases, again outlined above (legacy documents, animation …), that suffer from such a restriction.0 -
If I am not wrong, that is already happening. If you change a variable font with specific values to another variable font, the values change and you need to set those again. In desktop apps, I think they change to a default value. On the web, the values can also differ from one font to another, as they may cover different ranges.John Hudson said:
if different fonts have different steps, it becomes impossible to specify text and know what you are going to get if you change fonts. So e.g. if text is specified at a weight of 535, that could clip either up or down depending on how a particular font has its idiosyncratic steps defined.
I can see some of the disadvantages you mention but still see more benefits in allowing to refine/clean the design space.0 -
It seems to me we’re still talking about problems of interaction with design spaces, not problems of design spaces.2
-
Cartographic maps could hold much more information than they do, but it would render them less practical. Instead, consider the user level. Undoubtedly, some use cases will specifically benefit from more information.
Indeed. Thinking about this in terms of ‘user level’, analogous to zoom level in a map or in an image is useful. There are always going to be situations in which less data is more practically useful than more data, and where selectively constraining displayed data is helpful to the user. But the way to do that is to provide better interaction experiences, not to handicap the underlying data.1 -
María Ramos said:... If you change a variable font with specific values to another variable font, the values change and you need to set those again. In desktop apps, I think they change to a default value.
I have seen this happen. I consider it a bug in said apps.0 -
Maria initially described her concern as variable fonts providing too-fine distinctions most of which are, in practice, not useful distinctions. But I think it's would be better to characterize that as a human user interface issue rather than an issue inherent to the font capability itself. The reason is that a judgment of something being "not useful" necessarily assumes a context: not useful for whom? As Simon and others have pointed out, fine distinctions that don't provide much value for most users might still be useful for certain users, or useful for automated processes.
For the latter, I don't see what downside there is to allowing finer distinctions. Consider auto optical-size selection: suppose for sake of discussion that a 1 (or 0.1, or 10 or...) unit difference will never be important from a typographic design standpoint. But what harm is there if an application is able to select optical size variation at a 1 unit level? None that I can think of.
It's only for some segment of human users that this might be an issue.
And what is that segment? Is it the majority of users? My guess is that the largest segment would be those that simply use named instances.
That means we're looking at some segment of human users who want more palette and control than is provided by the named instances, but for whom the fractional unit granularity that the format allows is far more than they need. Who are those users, and what would best meet their needs? Is the best thing for those users that a font designer impose (say) 50 unit steps --- one size for all customers?
(Btw, that can already be done using an avar table.)2 -
Another simple solution: let the user stretch the slider, changing the step size.
By the way, Florian has a very good point that axes are not always linear.2 -
Refining the default of the design space should not handicap the data.John Hudson said:
There are always going to be situations in which less data is more practically useful than more data, and where selectively constraining displayed data is helpful to the user. But the way to do that is to provide better interaction experiences, not to handicap the underlying data.
Good to know it can be done using an avar table.Peter Constable said:Maria initially described her concern as variable fonts providing too-fine distinctions most of which are, in practice, not useful distinctions. But I think it's would be better to characterize that as a human user interface issue rather than an issue inherent to the font capability itself.
…
Is the best thing for those users that a font designer impose (say) 50 unit steps --- one size for all customers?
(Btw, that can already be done using an avar table.)
I'm not clear what confines a default option as a "one size fits all", since advanced users of type will figure out how to break the mould providing the tools are available (sometimes, as plugins).
It makes sense that the optimal number of steps would be defined by the type designer, in the same way that instances are defined at the type design level. This brings the distinctions back into the font capability, rather than a purely human interface issue.
Maybe I'm missing something.
0 -
Refining the default of the design space should not handicap the data.Think of it like resolution. If the font specifies that a wght axis has 20 discrete steps instead of a near-continuum of fractional values between 1 and 1000, that is a lower resolution. Yes, the underlying data of the default instance and delta sets in the gvar table is the same, but the font is only allowing access to part of that data, rather than to all of it.I'm not clear what confines a default option as a "one size fits all", since advanced users of type will figure out how to break the mould providing the tools are available (sometimes, as plugins).Does requiring ‘advanced users’ to figure out ways around the handicapping of access to the font data make more sense than having better interaction tools to simplify how all users engage with the font data? Bringing idiosyncratic step models into individual variable fonts doesn’t make the human interface issues in software go away, it just complicates them. We could have font-specific axis scale resolution, and still have lousy UI for working with variable fonts, and that UI would have to be able to handle juggling fonts with different step values.0
-
John Hudson said:
Think of it like resolution. If the font specifies that a wght axis has 20 discrete steps instead of a near-continuum of fractional values between 1 and 1000, that is a lower resolution. Yes, the underlying data of the default instance and delta sets in the gvar table is the same, but the font is only allowing access to part of that data, rather than to all of it.The font is already restricting access to part of that data. In the same way that you could redefine to 50 steps, you could also redefine to 5,000 steps.
I agree it is like resolution, except we're not talking about jagged pixels. Instead, the differences are more similar to 300dpi as the standard of print contexts, beyond which is largely indiscernible to the unaided human eye from a reading distance.John Hudson said:
Does requiring ‘advanced users’ to figure out ways around the handicapping of access to the font data make more sense than having better interaction tools to simplify how all users engage with the font data?Better tools are a matter of innovation, advanced users may well contribute to that innovation. This reminds me of the difficulties Pim first experienced at Brill before Tiro's solution to those difficulties, and I'm sure countless others you've worked with.
As for the innovation of VF's 'advanced users'… on a parallel thread @Dave Crossland posts a video to a plugin for AE, and @jeremy tribby posts from Figma's UI for VF that appears to be using steps… which suggests it has potential as a pretty good idea.
John Hudson said:
We could have font-specific axis scale resolution, and still have lousy UI for working with variable fonts, and that UI would have to be able to handle juggling fonts with different step values.Agreed, it would not solve lousy UI.
IMHO, I think María deserves a little more credit for the effort to promote discussion around improvements for the font user, which was never constrained to a single solution. How else can we innovate?María Ramos said: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.
…
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.0 -
I feel like this discussion is too fixated on the slider interface. A font only offering 300 and 350 axis values but restricting anything in between by specifying a step size for that axis might make some sense for sliders (although I disagree with that), but for different interfaces like number fields, it makes even less sense. A user inputting a value of 325 into a number field would probably expect that value to be set as is, not rounded up or down to the nearest step.
And, of course, one user might use keyboard input with a field while a different user opens the same document in an app that offers sliders. For compatibility, both apps need to support the same range. An advanced user mode is an issue for the same reason: Once an advanced user touches a document, all other users must be able to see and edit the same document in their simplified interface, but that is not possible.
This is a UI issue. Please do not address it in the font (like with the avar table). Regarding the map analogy: A font is like a database storing geographical features and cartographical data, while a typeset piece of text using that font is like an individual map that was drawn based on the database.3 -
IMHO, I think María deserves a little more credit for the effort to promote discussion around improvements for the font user, which was never constrained to a single solution.
Absolutely! And her 2018 Alphabettes article is still one of the freshest pieces of thinking about possible ways to present multi-axis design spaces to users. The spider’s web visualisation is a great translation of multi-dimensional space into a flat representation in a way that actually produces visually useful cues to learning to navigate that space. It is also a visualisation that lends itself to a step model of axis interaction, because that produces nice and tidy webs, but it still isn’t necessary for the font data to define those steps (and, speaking as a font maker, I am not convinced that I am always going to be the best person to define what the steps should be, since I can’t anticipate what users want to do with my fonts).
This thread has been a very useful discussion, I think. As it happens, it has confirmed my thinking that this is best understood and addressed as an interaction issue, but only through engaging Maria’s ideas.3 -
If stepped avars became common, I'm sure that user tools to redefine avar data on the fly would become common too.2
-
Truly, it is a problem when files with advanced OT features short-circuit the machines of amateur type users.Florian Pircher said:An advanced user mode is an issue for the same reason: Once an advanced user touches a document, all other users must be able to see and edit the same document in their simplified interface, but that is not possible.
That'd be awesome. I downloaded Roboto Flex, very fun to explore online although InDesign is sadly overwhelmed by the variable axes. Personally, I am befuddled by ID's use of a single pop-up for multiple axes, when every other feature has its own space.Dave Crossland said:If stepped avars became common, I'm sure that user tools to redefine avar data on the fly would become common too.
Would be nice to have a way to find the multiple masters on each axes, so that typographers can select those designs that have had the most attention to detail. Not so different from choosing metric kerning over optical.
How did the team decide on the variants for each axes (e.g. 25–135 for thin stroke)?
0 -
Would be nice to have a way to find the multiple masters on each axes, so that typographers can select those designs that have had the most attention to detail. Not so different from choosing metric kerning over optical.Except the masters don’t actually exist in an OT variable font, other than the default instance outlines. Everything else is expressed as deltas from the default instance, so while one can presume the existence of source masters for the extrema of each instance, delta sets occuring elsewhere in the design space may or may not correspond to your idea of multiple masters. Some delta sets represent particular masters within a design space, in which case there is a strong likelihood that they are also named instances, but some delta sets—especially partial ones that only cover a subset of glyphs, or even just a single glyph—are created to influence an area of the design space.
A lot of variable fonts, especially in this early phase of OT variations technology, are cobbled together from multiple master sources, very often involving pre-existing static font master sources. But the format is much more interesting than the old Adobe PS MM format, in that vast areas of a design space can be masterless in the sense that no individual delta set sits at the corner between two or more axes. This leads to a different kind of design procedure where, instead of designing masters for all the corners of a design space, one can proceed in phases, gradually building up the delta sets where they are needed and deliberately letting other areas of the design space ‘float’. That’s a different kind of type design, and the presence of ‘masters’ in that kind of design doesn’t imply ‘most attention to detail’, but rather a management of influence to achieve details elsewhere.2 -
This is the design space of one of my current projects. The nature of the design and of the variations mean I am able to avoid any intermediate or corner masters, so almost the entirety of the three-dimensional design space is extrapolated between the axes.
3 -
These are "per mille of em" values, so if the VF is drawn on a postscript standard 1,000 upm then it's the font units, although iirc Roboto Flex axes are scaled.KP Mawhood said:
How did the team decide on the variants for each axes (e.g. 25–135 for thin stroke)?
The exact value is a specific distance on a specific glyph, described at http://variationsguide.typenetwork.com in 2017 and in the http://github.com/typenetwork/parama-roundup code DJR developed maybe 2 years ago.1 -
Radical question. Apart from their utility as a transitional tool and backwards compatibility for non-OT Var outputs, what is the advantage of "named" instances over "unnamed" instances?John Hudson said:
Except the masters don’t actually exist in an OT variable font, other than the default instance outlines.
With instances that mimic previous technology it can be tempting to rely on past methods to create a type system, rather than explore new strategies. The presence of named instances suggest that there is an ideal, which you rightly point out may not reflect the design procedure.
I appreciate the intricacy of this, and it raises a question for me.…rather a management of influence to achieve details elsewhere.
Besides instances, is there a way to encourage the inexperienced type user towards (1) harmonious type scales that (2) work well together within a single type system?
If many axes graduate towards an interface that revels in a fluid interaction (with neither breaks, nor guidance) then it hands over responsibility to the type user who must then deliver hierarchy by visual interpretation. Even when cutting one's teeth in type design, it's very easy to make (1) the "bold" too light, (2) the "cursive" too upright and (3) the "condensed" too wide. Contrast is fundamental to the very essence of typography that is easy to navigate and communicates effectively. This is before we consider unfamiliar scripts… how would a reader of Latin script adjust axes for Arabic and vice versa?
To make another analogy… with very little experience, it is easier to play tunefully on fretted guitar (albeit, with poor technique) than it is to deliver the right notes on a cello where the position of each note must be memorised.0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 803 Font Technology
- 1K Technique and Theory
- 622 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 485 Typography
- 303 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 270 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports