[OTVar] Defining instances in the font vs. defining instances in CSS
Gustavo Ferreira
Posts: 8
Another consideration which may have implications on font size and licensing:
Variable fonts may contain “named instances”, which correspond to the static font styles we have today: ‘Bold’, ‘Light Condensed Italic’, ‘Serif Caption’ etc.
But with access to font variations in CSS, there will be no need to include named instances in webfonts: they can be defined directly in the CSS. The foundry can deliver a small variable font (masters only) and a CSS snippet with the instance definitions (mapping of names to coordinates). Web designers can then fine-tune instances directly in CSS, if needed.
Tagged:
2
Comments
-
The foundry can deliver a small variable font (masters only)
The named instances use almost no space, a few bytes only. So no harm done by adding them.
1 -
Named instances serve two functions:
1. They provide individual font-like behaviour in applications, i.e. appear in font menus as if discrete styles of a family.
2. They provide font makers with a way to express how they think of the family in terms of discrete styles (which may well correspond to design masters), and to do so in ways that are compatible with non-variable versions of the same family.
Yes, if one is making fonts purely for use as webfonts, then it will be possible to use CSS to define what I think of as nicknamed instances (i.e. the name is something particular to that CSS, not provided by the font maker), and the font doesn't need to contain any named instances. But as Georg points out, the named instances take up very little space in the font — they're just mappings from a X,Y location in the normalised design space to a name ID —, so there's very little point in not including them.
2 -
Yes, the “savings” from omitting pre-defined instances is negligible. Also, web designers will benefit from knowing what the type designer considers to be useful defaults.
This discussion brings up an interesting related topic, which is whether type designers should try to carefully calibrate their weightclass values so that their preferred "regular" weight falls at exactly 400 and their preferred matching "bold" at exactly 700. I would say that while not technically required, it's a very good idea, as otherwise they will find that web designers will use their fonts in ways that the original font creator thinks are less than ideal.1 -
"...an interesting related topic, which is whether type designers should try to carefully calibrate their weightclass values so that their preferred "regular" weight falls at exactly 400 and their preferred matching "bold" at exactly 700..."
I don't like the idea of a constant "regular" to "bold" ratio. To me actual point size of the typeface used makes a difference. If what i am setting is 12 point text, I want my stem weight to be lighter than say 8 or 9 pt text. The ratio of bold to base weight of what you are calling "regular" should vary as well. I might prefer a "Light" weight paired with a semibold compared to a Medium weight paired with a bold. I don't even like the idea of only one regular text weight. Go ahead and make an array of near "regular" weights [extralight, light, regular, medium,..]. I would hope the typeface designer does not overthink what he assumes the user might want. I would hope we would just make good tools and allow the user to make good decisions with them. Sure, an uneducated user may make bad pairings but they will learn.3 -
@Thomas Phinney
When I'm using masters in FontLab, the weight transition is linear. I dial in whatever I think would have a good regular and that arbitrary transition number becomes regular. With OTvar, would there be some kind of curve handle that could be adjusted to nail the regular at 400?0 -
In the current situation, there is no constant “regular” to “bold” ratio. Moreover, there is no exact meaning for “Regular”, “Bold”, “400”, “700”—in the sense of determining the exact weight of a font (like an exact stem width). Both “Regular” and “Bold”, and “400” and “700”, are members of an “ordered list of labels”, giving information about the weight order of font styles—not about their exact weight. The exact meaning of “Regular”, “Bold”, “400”, “700”, etc., is now a decision of the font designer—and I expect it will stay like that with variable fonts. (When I replace “500” by “550” in a Medium font, I do this to prevent a problem—not to indicate a change of weight.)
When the exact meaning of both “Regular” and “400”, is a designer’s creation—this sounds weird:
type designers should try to carefully calibrate their weightclass values so that their preferred “regular” weight falls at exactly 4001 -
Variable font instances seem to make sense in some situations (Microsoft Word / basic typesetting environments), but its an imitation of former technological limitation. If you want to encourage fine typography, why not normalize the variation – it'll be adopted quickly by the next generation.
Benefits as mentioned by @Chris Lozos for point size, also usage (captions, footnotes), as well as harmonization / contrast between different fonts and for different scripts.
@Ben Blom exactly this, there is no exact meaning – it is a decision of the font designer. As far as I'm aware there's no technological means to impose an exact "400"; which means that any implementation of such a standard is a soft-skill problem.
This sounds really great, to what degree could the variations be fine tuned? Would it need to operate as floating point numbers, or is there another mechanism that would be appropriate?Gustavo Ferreira said:But with access to font variations in CSS, there will be no need to include named instances in webfonts: they can be defined directly in the CSS. The foundry can deliver a small variable font (masters only) and a CSS snippet with the instance definitions (mapping of names to coordinates). Web designers can then fine-tune instances directly in CSS, if needed.
0 -
@Ray LarabieWith OTvar, would there be some kind of curve handle that could be adjusted to nail the regular at 400?
Axis Variations table2 -
Katy Mawhood said:
@Ben Blom exactly this, there is no exact meaning – it is a decision of the font designer. As far as I'm aware there's no technological means to impose an exact "400"; which means that any implementation of such a standard is a soft-skill problem.
This is one example of how multiple masters in design differs from variable fonts. When you use multiple masters to design a static family, nobody knows what the coordinates are for each instance in that family. However, in variable fonts, those axis coordinates are open to the world. Not only that, they're how people request specific weights. I.e. when a web designer puts "font-weight: Bold" in CSS, this coordinate value (i.e. 700) is how the browser and operating system choose which instance in a variable font to display.
[More specifically, the OpenType 1.8 spec ties the values in the weight axis to the values of the OS/2 table's usWeigthClass, which gets propagated throughout the system to the browser]
Designers are free to draw outlines however they wish, as long as what the designer chooses to be Regular is located at wght=400, and what the designer chooses to call Bold is located at wght=700 (and similarly for Light, Black, etc). That way software, websites, etc, can address specific weights using the common names. This is particularly important on the web for preserving relative weight in fallback situations when the browser has to use a different font-family.
As @John Hudson pointed out, you can use an Axis Variation (avar) table to put a curve on your axis so that it doesn't get interpolated in a straight-line linear fashion.3 -
Rob McKaughan: Designers are free to draw outlines however they wish, as long as what the designer chooses to be Regular is located at wght=400, and what the designer chooses to call Bold is located at wght=700 (and similarly for Light, Black, etc). That way software, websites, etc, can address specific weights using the common names. This is particularly important on the web for preserving relative weight in fallback situations when the browser has to use a different font-family.
There may be an OpenType specification about the names of weights, and their accompanying number—but in practical reality, there is no standard most designers adhere to, and there are no “common names”. See, for instance, here and here. Should this change now, with the introduction of variable fonts? (Can I continue to use the number “550” for “Medium” fonts, instead of "500"?)
0 -
(maybe ‘weight class calibration’ can become a different thread?)
@JohnHudson
What you called ‘nicknamed instances’ are custom instances defined from scratch by the CSS author (font user).
I was suggesting something else: a scenario where the font maker provides the ‘official’ instance definitions (names-to-coordinates mapping) as CSS, along with the variable font.
In this scenario, a ‘font-family’ becomes: 1. one or more variable fonts (actually font-making machines) 2. the font definitions in css (recipes for single font styles).
0 -
@Gustavo Ferreira
I understood your proposal, but I don't see significance in whether the CSS defined instances are defined by a font user or a font maker: they're both the same mechanism of instances defined externally to the font, which I call nicknames.In this scenario, a ‘font-family’ becomes: 1. one or more variable fonts (actually font-making machines) 2. the font definitions in css (recipes for single font styles).
There's nothing to stop you providing users with CSS 'recipes' for instances, and if users might want to be able to easily edit those instances, this might be a useful thing. I don't think it's a viable substitute for named instances per se, though, because those are of use outside of CSS, in displaying instances on application font menus. What you propose might be okay for web-only fonts, but as pointed out, the named instances are a tiny amount of data, so nothing is really gained by not including them.
I also don't like the idea of the 'official' instance definitions being defined externally to the font in a format whose virtue is that it is easily editable. The whole point of named instances is to reflect what the font maker considers the default styles. Having these defined only in CSS effectively means there aren't stable default styles any more, since the CSS is so easily overwritten or, indeed, easily separated from the font.
0 -
Trying to imagine how the CSS code for both situations could look like:
The second is a lot shorter and more elegant.
0 -
Ben Blom said:Rob McKaughan: Designers are free to draw outlines however they wish, as long as what the designer chooses to be Regular is located at wght=400, and what the designer chooses to call Bold is located at wght=700 (and similarly for Light, Black, etc). That way software, websites, etc, can address specific weights using the common names. This is particularly important on the web for preserving relative weight in fallback situations when the browser has to use a different font-family.
There may be an OpenType specification about the names of weights, and their accompanying number—but in practical reality, there is no standard most designers adhere to, and there are no “common names”. See, for instance, here and here. Should this change now, with the introduction of variable fonts? (Can I continue to use the number “550” for “Medium” fonts, instead of "500"?)
Quite right. Designers use all kinds of names for different styles (I called one of my test fonts "Sorta bold kinda condensed"). These names all end up in the name table in name ID 1/2, 16/17, 20/22, or in the string for a named instance in a variable font. You can put whatever you want in there. If you want to have your wght=550 instance called "Medium" or "Rob is weird", or whatever you'd like, that's fine.
But, that's not the problem I was trying to describe. The issue I was pointing out was this: how does software find the right instance in a variable font, given a request that doesn't include a name? The result of that has implications on how you design your axes (but not your names or outlines).
For example, CSS allows keywords for the font-weight property. These are not names, but keywords that correspond to numeric values. E.g. "Normal" is 400, "Bold" is 700. Similarly, as far as I know, all operating systems have style attributes for fonts like Bold, and Condensed (CoreText, DWrite). These are not names, but properties. So, when CSS specifies weight with a keyword, or an application asks for a font with style attributes, what instance should software choose?
In the past, there was no standardization in terminology (as you rightly point out) and no reliable metadata, so operating systems dug through the name table, guessing. Windows has a list of synonyms of "bold" in it and it looks for these in name IDs. As you can imagine, this is a rough heuristic that is easily thwarted. This is why type designers either use fairly common words in their name tables, or risk software not finding an instance, and turning on automatic bolds, italics, etc. That's not pretty and we want to move beyond that.
So, with a variable font, it's more straightforward: the usWeightClass (and thus font-weight in CSS) for an instance is the coordinate on the weight axis. So, when CSS requests "Bold" (equivalent to weight=700), the operating system will use the instance with coordinate wght=700, no matter what it's called (you can call it "megadark" if you'd like), and no matter whether the designer had a named instance at that location.
E.g. Let's say I have a font family called "Marx Bros" with an instance called "Harpo" at wght=300, "Zeppo" at wght=400, and "Groucho" at wght=900. "Harpo" is drawn really light (maybe with curls), "Zeppo" is really boring and normal , and "Groucho" is drawn with the same vertical stem widths as "Zeppo", but really thick horizontal stems. Then, a user of my font uses font-weight: bold in CSS. The OS/browser will generate an instance at wght=700 and display that. Or, if an application requested a font family member with the property DWRITE_FONT_WEIGHT_HEAVY (correlates to 900), the OS would return the "Groucho".
The implication of this, which is why I started the comment, is that type designers should be aware that, regardless of how they name fonts or draw outlines, when web designers use font-weight: normal, the OS will render whatever is at wght=400, and similarly for font-weight: bold, and wght=700. It's just something to be aware of.
Sorry for the overly-long explanation of what really is a minor clarification (but one I don't think is obvious from reading the specs).
4 -
If I have a Bounce axis, with styles named None, Mild, Lively and Vigorous, would these names appear on a user menu? Could “font-bounce:lively” be a thing?0
-
@Nick Shinn :
Named instances (listed in the fvar table) are listed in font menus just as if they were static fonts.
Names for points along an axis are in the STAT table. This enables applications (that choose to do so) to show UI for each axis, with named points along them, in the right order.
The main benefit, though, of the STAT table is to give software a way to map names (in named instances, or family/subfamily names in static families) to those points. E.g. for "NickFont Strong Narrow Lively", to know that "Strong" refers to particular weight, "Narrow" to a particular width, and "Lively" to a particular bounce. That enables applications and operating systems to more sensibly organize large families or variable fonts with lots of named instances (imagine a variable font with weight, width, optical size, and some number of foundry-defined axes like Bounce, Serifness, ...). In the case of big static font families, it enables more sensible font substitution because if you have a reference to a missing font, you know what axis values are missing, thus the nearest family member to the missing font.
For "font-bounce:lively" to be a thing, the CSS working group of the W3C would need to ratify bounce as a standard, industry-wide axis, as would the fvar section of the OpenType spec. Both spec groups would also want to standardize on the numeric values for the axis and the semantics for them. It sounds like a bit of bureaucracy, but I believe (at least in OpenType) the intent is to be able to add new standardized axes in the future.
Personally, I hope that designers experiment a lot with different axes, and if there is consensus on a set of axes many designers use, formalize those as a standard. (e.g. I'd be curious if a Formality, x-height, or Serif-extent axis takes off).2 -
Forgot to mention, the CSS draft spec enables CSS to directly address any axis directly. So, if the tag for your Bounce axis was "BNCE", then you could put "font-variation-settings: 'BNCE' 10" in your CSS. Downside: your users need to know the numeric value to use.
Hmm... It would be cool if browsers could use the STAT table to enable users to use named values... I think I'll suggest that. Done.
0 -
@Rob McKaughanLet's say I have a font family called "Marx Bros" with an instance called "Harpo" at wght=300, "Zeppo" at wght=400, and "Groucho" at wght=900.
I'm sorry, but general agreement is that Zeppo was the lightweight.6 -
Thank you @John_Hudson! I needed that right now!0
-
Here’s a more compact example (warning, this is CSS fiction):
1. using named instances in the font@font-face {<br><span> font-family: "MyFamily";<br></span><span> src: url("MyFamily.woff#Bold-Condensed");<br></span>}2. defining instances with CSS<div>@font-face {<br><span> font-family: "MyFamily";<br></span><span> src: url("MyFamily.woff");<br></span> font-variation-settings: 'wght' 700, 'wdth' 80; <br>}</div>@KatyMawhoodThis sounds really great, to what degree could the variations be fine tuned? Would it need to operate as floating point numbers, or is there another mechanism that would be appropriate?Both examples above refer to the ‘Bold Condensed’ design. But in 2 you can say ‘I want this a little heavier and less condensed’. (The numbers are axis coordinates as defined in the fvar table.)
@JohnHudsonI also don't like the idea of the 'official' instance definitions being defined externally to the font in a format whose virtue is that it is easily editable. The whole point of named instances is to reflect what the font maker considers the default styles. Having these defined only in CSS effectively means there aren't stable default styles any more, since the CSS is so easily overwritten or, indeed, easily separated from the font.Default font styles are always a compromise, because a font cannot know about the document in advance. Being able to easily edit and fine-tune default font styles per document (and per context, via media-queries) is a very useful feature, I think. That’s what responsive typography is all about, no?0 -
@Rob McKaughan So, in the future, with variable fonts and CSS, the usWeightClass number is more than just a way to order weight styles of a font family. You say that I can continue to use “550” for a Medium font, but at the same time you suggest that I cannot continue to do so—because the OS might render something that I don’t want it to render.
Now, if a font family contains (among others) the styles “Regular (400), Medium (550), Demi (600), Bold (700)”, and if these styles are “embedded” in a variable font—what will the OS render if it is asked to render a “Medium” style from this variable font? Will it render what is at “500” on its weight axis (= a lighter weight than the original Medium), and not what is at “550” (= the original Medium)?
If it would render what is at “500”, can I prevent this to happen—by making the variable font a “restricted variable font” as John Hudson would call it, or a “discrete variable font” as I would call it?
0 -
@Ben Blom
It depends on whether the font request was made via name or via keyword.
If via name (like in font pickers, or via the font-family property in CSS), then the search is done by the name table. If the name request is for "MyFont Medium", then it'll match by the name Medium, whatever axis coordinate that corresponds to. (550 in your example, but you could have just as easily defined a named instance at 999 called "medium" and it would have been used).
If the request is by keyword or property value (e.g. the font-weight property in CSS, or style attributes in APIs), then it will match by the numeric value of the axis that corresponds with that keyword or property value. CSS doesn't have a "Medium" keyword, as far as I know. DWrite does have a property value of DWRITE_FONT_WEIGHT_MEDIUM, which correlates to 500. So, if an application searched for a style of "MyFont" using DWRITE_FONT_WEIGHT_MEDIUM, they'd get the instance at wght=500, not wght=550.
If you want, you can use an avar table to tweak the coordinate space so that a request for wght=500 lands on 550 in your design space, thus making sure you get what you want in all circumstances.
As to "restricted" and "discrete" variable fonts, these are really EULA concepts. From a technology perspective, nothing prevents an application or user from accessing any instance on the spectrum. E.g. if you had a weight axis from 300 to 900, someone could request weight 421.32 (at least via API; I think CSS requires integers).
This ability to pick any instance enables lots of interesting scenarios, particularly with width, as @Indra Kupferschmid rightly points out. With a width axis, you could do headline fitting to reduce wrapping (or at least make wrapping less ugly), or do micro adjustments like the hz-program did to make excellent justification.
With fine weight control, a designer could match the weight between low-dpi and high-dpi devices (fonts often look lighter on high-dpi devices vs low devices), to have a very consistent brand look across devices. This is particularly interesting with lighter weights as low-dpi devices have a hard time with light weights. I'm also curious to see if people animate weights in interesting ways (e.g. click actions).
Now, you could use an avar table with a stair-step function so that requests along the axis continuum get mapped to specific values. E.g. you could map 421.32 to 400. But, that would prevent interesting scenarios like the above.
I think the power of variable fonts is not in merely packaging existing font family sets in a compact format, but in enabling all the interesting dynamic, responsive possibilities of type. Put another way: static fonts are not a far cry from hot metal. They're an unchanging sequence of outlines in unchanging rectangles that best work in a fixed, manually designed layout. Variable fonts enable true digital typography - type that responds to the content and the display surface, automatically changing to best suit the content to the context. (essentially the argument @Nick Sherman makes here). This is the main reason I began advocating for variable fonts. The space efficiency was, to me, merely a bonus.
3 -
Rob McKaughan: As to “restricted” and “discrete” variable fonts, these are really EULA concepts.
@Rob McKaughan According to John Hudson, an EULA-based mechanism for such a restriction is a non-starter. Also, the avar table with a stair-step function that you mention, is a technical implementation of such a restriction.
I think the technical possibilities of variable fonts are very promising. However, people whose livelihood depends on the sale of fonts, might see things from a different perspective than people whose primarily focus is on the possibilities of a new technology.
There is no technical reason to differentiate between a “Standard”, “Pro”, and “Pan European” font. There is no technical reason to differentiate between a “Basic Font Family” package (4 fonts), and a “Complete Font Family” package (16 fonts). There is no technical reason not to put the complete family of 16 fonts in the 4 fonts “Basic Font Family” package. There is no technical reason to differentiate between an unrestricted (continuous) variable font, and a restricted (discrete) variable font. However, there is a marketing reason for such differentiation: to be able to offer less functionality for a lower price, and more functionality for a higher price. If a foundry would limit itself to only selling unrestricted (continuous) variable fonts, it would limit its marketing options.
2 -
There is a technical reason to distinguish a Pan-European font, or a font loaded with OpenType features such as small caps and superior figures—their large file size.0
-
The marketplace will figure this out but I've been thinking about how OTvar could be sold alongside discrete styles. Say I have a 64 style superfamily where singles are $20. That's $1280 if purchased separately. Volume discount it 30% and it's still $900. But if I want the family price to be a more reasonable sounding $200, I have to use about an 85% volume discount. That discount is offered through most vendors in clunky stages. Who'd going to buy 63 fonts? The 64th font is only $3. Customers can't understand the discounting so they probably throw fonts in to the shopping cart and update to see what happens. Who likes this?
However, If I include the OTvar font with the full family price, maybe I can produce fewer discrete styles. Maybe forgo the extra-light and ultra-light. Skip some weights in expanded and condensed. Eliminate semi-condensed and semi-expanded. Now I've got an 16 style family. A 35% volume discount brings it close to $200.
A smaller family could be less intimidating for customers, perhaps easier to use. And the OTvar could serve as an inventive for more advanced designers to buy the full set. Not only will you get infinite intermediate styles but you'll get access to styles outside the range of the discrete family.
Producing fewer discrete styles saves the font designer money too. There's no magic button that burps out discrete styles, ready for sale. At least, there isn't right now anyway. Styles that need naming, interpolation that needs fixing. Zip that needs zipping. SKUs that need individual folders and spreadsheet entries. You just noticed your j collides with the square bracket? Having fun fixing it 64 times.
If OTvar kills the superfamily, it can't happen soon enough for me.4 -
Ray Larabie: There’s no magic button that burps out discrete styles, ready for sale.
Agreed, but it may not be as dire as suggested. If the “j” does not collide with the square bracket in the masters—then such a collision won’t happen in the fonts created by interpolation from those masters (if the interpolation has been done correctly). For my 112 style Aspira superfamily, I used a spreadsheet containing all the meta-information for all its styles. With this spreadsheet and a Python script that reads the spreadsheet, it takes a few minutes to create or renew the meta-information in all 112 vfb files. (It took a lot of time to create the spreadsheet and the script, but they can be reused with any new font family—after changing the family name and some other cell values in the spreadsheet.)
Variable fonts may kill the traditional superfamily (which is living in a big number of files), but will create the superfamily-on-steroids (which is living in just one file).
I can imagine creating a variable font, will go like this. Start with a set of masters, and feed them into the tool that will create the variable font. Then give permissions; and define, for specific styles, the name and position on the relevant axes. Giving permissions concerns whether the variable font will be continuous or discrete, and whether specific intervals of an axis will be “blocked” or not. (It may even be possible for one axis to be discrete, and another axis to be continuous—though this may be hard to explain to a font user.) For the named styles, a list has to be provided containing a style name, a style number (like usWeightClass), and a number which defines the exact position on the relevant axis.
1 -
That's not what John was saying:Rob McKaughan said:
From a technology perspective, nothing prevents an application or user from accessing any instance on the spectrum.John Hudson said:
It is possible to build a variable font in such a way that all the design axes work in discrete steps between named instances, with no intermediary interpolated instances.0 -
If the “j” does not collide with the square bracket in the masters—then such a collision won’t happen in the fonts created by interpolation from those masters (if the interpolation has been done correctly).If my generated instances were ready for shipping, I'd certainly do that. Fix the masters and generate instances again? That'd be wonderful. But I use FontLab in Windows and generated instances require a lot of cleanup and testing. They require removal of overlaps, manual cleanup, deletion and decomposition of disposable composites and more testing. When instances are generated, I still have a couple of days of work ahead of me. It's a lot faster and precise to fix a problem 64 times.1
-
I'll just add that for my part, I would indeed go out of my way to shape the weight space so that my named instances fall at points that match the CSS numbering/names. My regular will be at 400, my medium will fall at exactly 500 and my bold at precisely 700.
Just to be clear, I would be keeping my desired designs and my desired labels for the weight as I wish, and tweak the weight axis progression using the avar table to achieve this. Rob describes this as:If you want, you can use an avar table to tweak the coordinate space so that a request for wght=500 lands on 550 in your design space, thus making sure you get what you want in all circumstances.1 -
But I use FontLab in Windows and generated instances require a lot of cleanup and testingBut that is a problem with your tools and not inherent to interpolation.
5
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 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