Are customers buying or using variable fonts?
Comments
-
Thank you for clarifying Jens! I think I misunderstood based on Frank's use of the word instance vs master (and my personal bias towards having masters at or around regular weights). Still, in the scenario described (Light Condensed as an origin) there may be a better if unindeal master (e.g. Light regular width) in the font to pick from
0 -
I found this wording odd, since I don't think it's common to use "origin" in this way. It would be reasonable to think of the default instance as "origin" but only if thinking in terms of normalized axis values, which is not often how people think about the design space. I had to search in the OT spec to be reminded of one place in which this terminology is used:Frank Grießhammer said:I would like to put this statement in context. First, it is important to understand the technical setup of Variable Fonts. Every VF will have an “origin”, which is the drawing from which every other instance is derived, by way of deltas. The origin (or default instance) is the place at which all axes intersect, consequentially this default will often be an extreme style like “Light Condensed” or similar.Design-variation space: An abstract, multi-dimensional space defined by the axes of variation used by a font designer when designing a font family. In the context of a variable font, the variation space refers to the n-dimensional space defined by the axes of variation specified in the font’s 'fvar' table.
Note: A variation space can have one or more axes. In a variable font, the variation space is bounded by minimum and maximum values specified in the 'fvar' table. The zero origin has no special significance within a design-variation space. Within a variable font, however, the zero origin (using normalized coordinate scales — defined below) is a marked position since it corresponds to the font face represented directly by the font resource’s name, glyph and metric tables without reference to any variation tables or other variation data.
0 -
......but, taking any VF with only a wght axis, the OpenType spec says that the wght axis default is 400, so even if the font has only 2 masters at min and max, the default value must be 400, not whichever master is in the glyf table?https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_wght literally does say that as quoted, except it uses the word Regular instead of default.
Dave, swapping "Regular" with "default" is significantly changing the meaning from the intent of what the spec is saying. The intent is definitely not that the default instance wght value must be 400. The intent is only that the wght value for "Regular" must be 400.0 -
If you have a font development workflow that is based around a variable design space, then anywhere within that design space can be designated the default instance (i.e. the set of outlines written to the glyf or CFF2 table), but how this is done is going to depend on the tools you are using. The easiest way to do it in higher level design tools like FontLab and Glyphs is to instantiate a master at the desired location and then designate that master as the default instance, or what Glyphs calls the ‘Variable Font Origin’.
_____@Dave CrosslandWell stated. Variable fonts should only default to the default instance when no variation support is available in software and there is no other option, i.e. when the variable TTF ends up behaving like a single instance TTF. In any remotely variation-conscious software, the default state of any typeface presented to the user should be the nominal Regular, just as it is in any non-variable family.
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.
1 -
The decision about where in the design space to locate the default instance may be informed by one of two of considerations:
1) Data efficiency and size (which tends to favour a default instance at the extreme of one or more axes, i.e. in a corner, as noted by Frank).
2) What you want users to see if variation support is unavailable (which tends to favour the Regular named instance location, i.e. usually somewhere in the middle region of the axes interactions.
These considerations may be entirely separate from how you go about creating your type design and defining your design space in your font tool. Indeed, if the data efficiency and size consideration is paramount, then there is a strong argument to be made for tools that optimise the default instance location during generation of the variable font. In that case, the default instance may not correspond to any named instance in the font, and could be something neither the user nor even the designer ever sees unless cracking open the glyf table or using the font in a legacy system without variatioms support.
These considerations should be entirely separate from how the font is presented to users in a variations-aware environment. Regular is Regular, regardless of whether a font is variable or a family of non-variable fonts, and should be the default state of a font in an application.0 -
@Peter Constable
Thank you for clarifying my use of the word “origin” :-)
In my opinion, a thing that is missing from VFs is a semantic (i.e. non-mathematical) way of describing what a “representative” style for the whole family should be. Of course it will be “Regular” in many cases, but definitely not always.
I hope “What you want to see if variation support is unavailable” become less of a concern, especially as VFs become more established.1 -
@Frank GrießhammerThis is certainly something that becomes more ambiguous depending on the number of axes involved, and especially in the case of custom axes or an axis that might be particular to an individual design.
In my opinion, a thing that is missing from VFs is a semantic (i.e. non-mathematical) way of describing what a “representative” style for the whole family should be. Of course it will be “Regular” in many cases, but definitely not always.
The wght and wdth axes have Regular and Normal positions that are pretty obvious choices for the ‘default state’ of the typefaces—which is not the same as the default instance in the OTVar technical sense—i.e. what the user should initially see when selecting the typeface but not specifying any styling or variation. And a good case can be made that the default state of the opsz axis should correspond to the nominal type size automatically. What if the software does not support automatic opsz selection, though? What should the dflt state of opsz be in that case? At one or other extreme of the opsz axis? Or at a common text size e.g. 10pt?
As for the custom ‘basp’ axis that morphs between ball and and spike terminals in your funky display font, there is no obvious answer to what the dflt state should be, but it almost certainly is not in the middle of the axis. Closest axis extreme to the default instance?0 -
The STAT table needs a new attribute for named instances, for a subset of "star", "starred", "highlight", "exemplar" instances, and some sort order; the first in the list can be what frank describes0
-
STAT or fvar? Seems like this might be a possible use case for fvar Instance flags which are currently "reserved for future use". Define REPRESENTATIVE_INSTANCE or some such which can be used to indicate the instance apps should use when no specific variation information is supplied.Dave Crossland said:The STAT table needs a new attribute for named instances, for a subset of "star", "starred", "highlight", "exemplar" instances, and some sort order; the first in the list can be what frank describes2 -
I think fvar is a legacy format for naming instances, and fundamentally broken; its only value is for legacy systems that haven't been updated to deal with STAT.1
-
Define fundamentally broken.
In fvar there is sfntVariationAxis which has defaultValue.
fvar is beautiful. STAT not so much.
0 -
Dave's talking specifically about naming instances. fvar is still needed to define the axis ranges. STAT is admittedly horrible to work with, but it's much richer in terms of being able to define names and relationships.1
-
I got that. I just don’t see how fvar is broken, fundamentally broken, in this respect.
The discussion, after Thomas’ post, was about what to show as default. Named instances came up, in this context, but are more of by-the-way if not off-topic as to the question of default. My point was that data points needed already exist.
STAT is a joke. Strictly speaking it should not even exist. The advantage of variable fonts is that they are variable. There is no need for anything like named instances, simulating static fonts. I understand the desire to have those, from a MS point of view, yet it is based on a misconception – looking at variable fonts from within a conceptual framework still stuck with static fonts. Practically speaking: An environment that can handle variable fonts sure has a variable font affine way to navigate variable fonts’ content, there is no need for named instances. In an environment that cannot handle variable fonts, named instances won’t help much, and there is no way around providing static fonts. There is no need for variable fonts to mimic static fonts’ behavior in too an elaborate way.
0 -
While named instances have the effect of mimicking static fonts in the way in which they are presented in font menus, I think of them more as navigation signposts or like pins on a map that indicate the location of something interesting or useful. A complex variable font with multiple axes is difficult to mentally conceptualise, and the design space needs to be learned through navigating it: some users may just want to wander in it, discovering things for themselves; others may appreciate some signposts.3
-
BTW, the STAT table is not something specific to variable fonts. It is designed to capture relationships based on attributes, so can also be useful in complex families of static fonts. One of the principal goals of STAT was to get away from the name table model in which every new way of conceiving relationships between font styles at the software level led to a new table version with new name IDs. I had suggested something like the STAT table to Microsoft a few years before variable fonts, to be able to capture optical size or other attribute relationships between static fonts in a way that was flexible and extensible (and also opened the possibility of attribute-based dynamic font menus that could be sorted according to what the user considered the most important attributes).
0 -
Whether or not users rely on a name or a number to identify “how bold is the heaviest weight of this typeface?” the alignment of those descriptions is at the discretion of the type designer.
As a type designer, I would likely make Ultra = 900.
The word ‘signposts’ are necessary for weight, certainly, as most users conceptualize that quality in words (tradition plays a role), and have not yet associated the weight of a typeface with numbers, as we have learned to do.
And most crucially, the InDesign interface shows the weight control field by name at a higher level than by slider—reinforcing the traditional identification of weight by name.
1 -
John: ‘One of the principal goals of STAT was to get away from the name table model etc’ – but sadly none of you noticed that variable fonts, because being variable fonts, allow to get away from the name table model by sticking to the name table model while getting rid of anything past NID 1+2. All that variable fonts need is a family name and, optionally, a Regular vs Italic distinction. Everything else is ... variations.
What you preach removing clutter, what you practice is adding more of it. All of which needs to be kept in tune as name won’t go away anytime soon.
STAT not being specific to variable fonts is the most upsetting part about it.
Nick: With variable fonts you are free to define where the upper end is, of anything, yet a notion of ‘Ultra’ does not make sense in that context any more.
What I said about a variable font’s default I could say about ‘signposts’ too. There is no need for STAT to define these. fvar allows to define them.
0 -
K.L.Yet a notion of ‘Ultra’ does not make sense in that context any more.
Well then, what do you propose for the names of the weight-axis poles— “Lightest” and “Boldest”? Wouldn’t that be confusing to the user, as some fonts would have a Boldest weight of 700, and others 900?
The thing is, the word-name field is not going away any time soon, as long as there are so many non-variable fonts in the menu, so there have to be names, designated by the font, for the different weights, so why not make them correspond to the present convention, as used by CSS etc?0 -
@Nick ShinnI think Karsten’s point is that you don’t need to name the axis poles anything. In font development tools, you need to have labels for masters, but those names are arbitrary and not part of the naming scheme for the output fonts (just as the locations of those masters in the design space do not necessarily correspond to any named instance),
Well then, what do you propose for the names of the weight-axis poles— “Lightest” and “Boldest”? Wouldn’t that be confusing to the user, as some fonts would have a Boldest weight of 700, and others 900?
The wght axis has a mapping to an external naming system (CSS weight class), so perhaps even less than any other axis needs named instance locations. ‘Bold’ is wherever the weight axis maps to 700; ‘Medium’ is wherever the weight axis maps to 500; and so forth.
I still think signposts are useful, however, and also informative about how the designer thinks about the typeface. 900 = Black in the CSS weight class, but if Nick thinks of it as ‘Ultra’, that is in a sense part of the concept of the typeface design. Standardisation of style naming and relationships destroyed some of the unique identity of metal type in the transition to digital—Arrighi became Centaur Italic; Felicity became Perpetua Italic—which I think is a pity. Naming is part of making.
2 -
John:
900 = Black in the CSS weight class, but if Nick thinks of it as ‘Ultra’, that is in a sense part of the concept of the typeface design.
I use the weight/number table in FontLab, which assigns 900 to both Black and Ultra.
It might be better to use the CSS designations.
As you discern, the naming is part of the design, and I have in fact used different “naming scales” in different typefaces.0 -
FontLab and CSS both reflect the OpenType specification. https://learn.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass
There are only two named steps beyond bold. With parentheticals it gets weird as the spec arguably reverses the meanings of ultra-bold and heavy by making heavy the heaviest weight and equivalent to black. (My expectation here is like Nick’s, but unfortunately the OpenType spec disagrees.)
700: Bold
800: Extra-bold (Ultra-bold)
900: Black (Heavy)
In my mind, the sequence ought to go:
Bold
Extra-bold
Heavy
Black
Ultra-bold
But it is too late for that, the ship has sailed as far as standard usWeightClass usage goes.0 -
Hello Nick, what I am saying is twofold. Partly technical:
1a) As to the question whether a new table, or a new data point therein, is necessary so applications know what default to present, I pointed out that such a data point already existed in a table that already existed.
1b) As to the question whether a new table was necessary to provide applications with predefined named instances, same.
Partly conceptual:
2) Do we really need named instances following the same model as known from static fonts? I do not think so. Or only modestly so.*
I am not, as your example suggests, discussing which specific numbers or specific words/terms you may or may not use. This is up to you.
* I wonder if another approach wouldn’t be more useful thinking of real world use cases. Why not define such instances in a text file that may or may not accompany the font, user editable, with a text editor or with their favorite design application’s interface. Say a design firm has decided on a select number of fine tuned styles to be used as part of a corporate design, or a designer exchanging settings with collegues. Styles would be defined in whatever application, then saved as ‘snapshots’ – which are nothing but user defined style names plus values in user defined order – in a text file next to the font. Every other application would look for such a file first and present its styles in a list. Type designers too might define a few default styles – with an emphasis on ‘a few’.
0 -
Hi K,
From the user’s perspective, named instances for sans serif weight are very necessary.
Suppose that you are designing a periodical with body text and subheadings which are bolder.
Remember the last time you used this typeface? You developed a setting with the body in the default Regular weight, and moved the slider for the subheadings to a particular point that looked good. But what was that “Bold”? Was it 650 or 700? OK, it was 700, because you have learned that 700 is Bold, according to the standard, and you like to have benchmarks to organize your workflow, rather than reinventing the wheel every time you want to go somewhere.
So why not have a pre-set named instance or “signpost” and name it Bold?
I don’t think named instances are necessary for other design axes such as x-height or horizontal scaling.
0 -
Hello Nick, it is possible to do this so we do not need to discuss it, also see the footnote in my post above which goes even further, suggesting a solution that would allow users to store and share instances they defined on their own, across applications.
0 -
Nick Shinn said:
Remember the last time you used this typeface? You developed a setting with the body in the default Regular weight, and moved the slider for the subheadings to a particular point that looked good. But what was that “Bold”? Was it 650 or 700? OK, it was 700, because you have learned that 700 is Bold, according to the standard, and you like to have benchmarks to organize your workflow, rather than reinventing the wheel every time you want to go somewhere.
So why not have a pre-set named instance or “signpost” and name it Bold?
Surely the numeric value is the MOST clear and least fuzzy way to specify it?
Not that I am against named instances. I like them. Labels are handy.0 -
Surely the numeric value is the MOST clear and least fuzzy way to specify it?In theory, but not in practice. At least, not unless you show me a weight menu that is entirely numeric, which is more user-friendly than a menu that uses names, listed according to weight, as in this screen grab (Fig. 1) of InDesign. Now, my name order might be open to debate, but the application is correct, in that it lists them according to actual weight progression.
Fig. 1. Present InDesign menu.
Fig. 2. Numbers only, according to present menu design.
Fig. 3. Suggestion for “Numbers Only” menu, with slider “notched” for Regular and Bold.
Dispensing with the concept of naming the two most basic weights Regular and Bold seems impossible.
2 -
My customers haven't even figured out stylistic sets yet
8
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 800 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports