[css4-fonts] support for OpenType font variations

[nattokirai]

A new version of the OpenType spec defines a new font type, OpenType Font Variations, that includes not only glyph outlines but data that indicates how those outlines change by weight, width or other custom font axis. This allow a single font file to effectively serve as an efficient container for a wide variety of font instances within a single font family.

Background description:
John Hudson's blog post on variable fonts

Spec reference:
OpenType 1.8 spec

For these fonts to be available within web content, adjustments are needed to the CSS Fonts spec, possibly including new properties. The new OpenType spec defines a number of "standard" axes along with the ability to support custom axes created by a type designer.

Design goals for CSS changes to support variable fonts:

• support existing content that uses a font family containing variable fonts
• allow efficient use of variable fonts as downloadable resources
• allow author access to the custom axes that a type designer includes in their design

[litherum]

There is a draft for a proposal which we will discuss at TPAC at https://github.com/litherum/csswg-drafts/commits/variationfonts

Any comments would be greatly appreciated.

[svgeesus]

Good summary. I agree that we need access to both the standard axes (weight, width, slant, optical) and also to custom axes (perhaps using CSS custom properties, but maybe that needs custom descriptors too?)

One additional benefit of variable fonts for the Web is reduced download size. Instead of two or more separate downloads (one for each weight) a single font provides a range of weights. So implementers more focused on performance than on typographic excellence should still be interested in this new capability.

[nattokirai]

Based on what Myles has already written up, here's my summary of what I think needs to be added.

The first step is to expand the range of values allowed for font-weight, font-stretch and define how to map font-weight, font-stretch and font-style to the axes present in a variable font. With an existing font family, these values would be used to select a specific face within a family. With a variable font family, these will be used to indicate values along standard font axes.

The OpenType spec defines five standard axes:

'wght' : weight
'wdth' : width (i.e. font-stretch)
'ital' : italic
'slnt' : slant
'opsz' : optical size

Basic font property definitions

The changes below attempt to map basic font properties into values along these axes.

font-weight: normal | bold | bolder | lighter | <integer>

The <integer> is a positive number in the range [1..1000]. Values outside this range are invalid. For variable fonts, the weight values map directly into value along the weight axis. For values outside the defined range of weight axis as specified in the font, use the appropriate min/max value. For OpenType fonts, see the description in the 'fvar' table for the definition of the standard 'wght' axis.

font-stretch: normal |
              ultra-condensed | extra-condensed | condensed | semi-condensed |
              semi-expanded | expanded | extra-expanded | ultra-expanded |
              <percentage>

The <percentage> value indicates the percentage relative to what a type designer has defined as the normal width. The <percentage> must be greater than 0 and other percentage values are invalid. For variable fonts, if the font defines explicit values for the keywords above, those values are used to map onto the width axis values. For OpenType fonts, these are defined in the 'STAT' table. When the font does not define explicit values for these, keyword values are mapped onto explicit axis values (TBD: mapping values and/or algorithm, better for this to be explicitly stated in the OpenType spec). See the description in the 'fvar' table of the standard 'wdth' axis.

font-style: normal | italic | oblique

This is the same as the existing definition. Unlike what Myles has sketched out, I'm proposing this remains the same. For variable fonts in OpenType, two axes have been defined, the 'ital' axis and the 'slnt' axis (for slant). The value of 'italic' should map to the value defined in the 'STAT' table. The value of 'oblique' should map to the value defined in the 'STAT' table. If the value is 'italic' and the 'ital' axis does not exist, look for the value of 'oblique' and use the 'slnt' axis instead. Similarly for when 'oblique' is specified but no 'slnt' axis exists. If neither axis exists, use synthetic oblique. Other combinations of values along either the italic or slant axes can be expressed using the font-variation-settings property defined below.

Custom variations

Variable font families are not limited to only using the existing axes, they can also include custom axes that a type designer creates specifically for a given design.

font-variation-settings: normal | [ <string> <number> ]#

Similar to how font-feature-settings work, the values for this property specify the specific coordinates to be used with a variable font family. The value of normal implies used the default axis coordinates defined in the font data. The <string> value specifies the axis name specified in a variable font and the <number> indicates the coordinate along that axis. For OpenType fonts, these are defined in the 'fvar' table. Axis values specified for standard axes override the value implied by font-weight, font-stretch and font-style.

Examples:

/* heavy weight, expanded width */
font-variation-settings: "wght" 850, "wdth" 120;

/* specify number of bullet holes in custom Western slab-serif design */
font-variation-settings: "BLTH" 4;

/* light weight, font-variation-settings overrides font-weight */
font-variation-settings: "wght" 320;    
font-weight: 850;

For brevity, I'm omitting the font-optical-sizing property as I think getting the basic handling of font axes is important to work out first.

Format hint for webfont use

One of the big advantages of variable fonts for web usage is that a wide range of weights and widths can be stored in compact form. But to allow use with older user agents on platforms that don't support variable fonts, some sort of new format hint is needed.

Standard webfont font family with variable fonts, using a new woff2-variations format hint:

@font-face {
  font-family: BodyText;
  src: url(fonts/bodytext-variations.woff2) format("woff2-variations"),
       url(fonts/bodytext.woff2) format("woff2");
}

@font-face {
  font-family: BodyText;
  src: url(fonts/bodytext-variations.woff2) format("woff2-variations"),
       url(fonts/bodytext-italic.woff2) format("woff2");
  font-style: italic;
}

@font-face {
  font-family: BodyText;
  src: url(fonts/bodytext-variations.woff2) format("woff2-variations"),
       url(fonts/bodytext-bolditalic.woff2) format("woff2");
  font-style: italic;
  font-weight: bold;
}

@font-face {
  font-family: BodyText;
  src: url(fonts/bodytext-variations.woff2) format("woff2-variations"),
       url(fonts/bodytext-bold.woff2) format("woff2");
  font-weight: bold;
}

For a given set of property values of font-weight, font-stretch and font-style, the font matching algorithm would choose which font to download. In the example above, a user agent that supports OpenType variable fonts would download the font data once, since all @font-face rules use the same URL for the variable font case. Once the font had been downloaded, for variable fonts the user agent would apply the values of font-weight, font-stretch, font-style, along with font-variation-settings, to select the precise font coordinates to use.

Example:

font: 820 condensed italic 100% BodyText, serif;

For user agents supporting variable fonts, this would download the variable font data and use a value of 820 for the 'wght' axis, lookup the mapping of 'condensed' in the font data for the 'wdth' axis and lookup the mapping of 'italic' in the font data for the 'ital' axis to determine the precise font instance used. For user agents not supporting variable fonts, the user agent would download the bold italic face and use that.

[AmeliaBR]

Would there be a value in allowing the font-face descriptors (e.g., font-weight, font-stretch) to take two values, defining the range available from the file?

If you use range descriptors, then the non-variable fallbacks no longer match the descriptors, and would need separate font-face rules. However, I'm pretty sure that still works with @font-face as currently defined, just need to watch the ordering:

@font-face { /* fallback normal weight face */
font-family: BodyText;
font-weight: normal;
src: url(something) format(woff);
}
@font-face { /* fallback bold weight face */
font-family: BodyText;
font-weight: bold;
src: url(something-bold) format(woff);
}
@font-face { /* variable weight font */
font-family: BodyText;
font-weight: 200/700; /* min and max weights */
src: url(something-variable) format(woff2-variations);
}

So user agents that recognize the range descriptor and variable-font format would download the final file, others would download one or all of the backups (depending on which weights are required).

EDIT: I initially had the range descriptor using comma to separate the values. But it would probably be best to reserve commas for a list of distinct values (not a range). So, for example, if a user agent supported OpenType collection files (multiple distinct faces in one file), that could be font-weight: 300, 500, 800, while a variable-weight font with a continuous range would be font-weight: 200/800.

[nattokirai]

Would there be a value in allowing the font-face descriptors (e.g.,
font-weight, font-stretch) to take two values, defining the range
available from the file?

Yes, that's another possibility and others have suggested this for @font-face font descriptor values. It would make the font matching algorithm a bit more complex and I was hoping to avoid making it any more complex than it already is.

My hunch is that with variable fonts we don't need to make the font descriptor syntax more complex. Once all user agents support variable fonts the set of @font-face rules will boil down to one or two rules per family. All the variations will be defined within the font itself. The @font-face would just look something like:

@font-face {
  font-family: BodyText;
  src: url(something-variable);
  /* no need to define additional descriptors for a variable font */
}

[litherum]

The biggest problem with a no-range solution is that a single @font-face block cannot service requests for weights of both 300 and 700. It will (likely) be the common case that a single variation font will support weights covering most of the 1-999 scale.

[litherum]

It we do go with a range solution, I recommend using syntax similar to unicode-range (so it would use hyphens).

[nattokirai]

The biggest problem with a no-range solution is that a single
@font-face block cannot service requests for weights of both 300 and
700. It will (likely) be the common case that a single variation
font will support weights covering most of the 1-999 scale.

Not sure what you mean here by "service requests". The font-matching algorithm for @font-face font families serves as a way of determining which font resource to download. If the value of the font-weight, font-stretch and font-style properties are applied to the resulting downloaded font resource then you can provide both 300 and 700 weights, which is what I'm guessing you mean by "service" here.

I think you can definitely come up with complicated, multi-font examples where using the no-range approach is clumsy and awkward but I'm not sure those will ever need to be used in practice, even in complicated scenarios, since the variable font format itself provides so much flexibility to begin with.

We can add additional syntax when there's a practical need for it but I'm not convinced that there is in fact a clear need.

[nattokirai]

Jonathan Kew has also suggested using ranges in @font-face rules:

/* For legacy UAs that don't support variation fonts,
   load individual faces. */
@font-face {
  font-family: BodyText;
  src: url(fonts/BodyText-Regular.otf) format("opentype");
}
@font-face {
  font-family: BodyText;
  font-weight: bold;
  src: url(fonts/BodyText-Bold.otf) format("opentype");
}
@font-face {
  font-family: BodyText;
  font-style: italic;
  src: url(fonts/BodyText-Italic.otf) format("opentype");
}
@font-face {
  font-family: BodyText;
  font-style: italic;
  font-weight: bold;
  src: url(fonts/BodyText-BoldItalic.otf) format("opentype");
}

/* For UAs with variation support: the style and weight descriptors
   cover a range, which means this will override all the preceding
   rules that fall within the ranges. UAs that don't recognize the
   "opentype-variation" support will not load anything here, so will
   fall back to the individual faces above. */
@font-face {
  font-family: BodyText;
  font-style: normal, italic;
  font-weight: 1-1000;
  src: url(fonts/BodyText-Var.otf) format("opentype-variation");
}

So font-stretch would use a percentage range? 50-150%? Hmmm.

[bramstein]

I'm a little worried this is overloading the @font-face syntax too much. Families are created using multiple @font-face rules, one for each "instance". A variation font already contains all variations, so it doesn't map very cleanly to @font-face. The new format hints and range proposals feel a little off to me for that reason.

I know this would be a substantial change, but would it be possible to define a new @ rule for variation fonts? Something like this:

@font-variation {
  font-family: BodyText;
  src: url(bodytext-vf.woff2) format("woff2"),
       url(bodytext-vf.woff) format("woff");
}

This avoids extending the format hints and overloading the @font-face descriptors. As @nattokirai pointed out, most uses of variation fonts won't need weight, style, and stretch descriptors.

@font-face {
  font-family: BodyText;
  font-weight: normal;
  src: url(bodytext-normal.woff2) format("woff2"),
       url(bodytext-normal.woff) format("woff");
}

@font-face {
  font-family: BodyText;
  font-weight: bold;
  src: url(bodytext-bold.woff2) format("woff2"),
       url(bodytext-bold.woff) format("woff");
}

@font-variation {
  font-family: BodyText;
  src: url(bodytext-vf.woff2) format("woff2"),
       url(bodytext-vf.woff) format("woff");
}

This would fall back to the two @font-face rules in browsers that do not support font variations. Browsers that support font variations would ignore the @font-face rules and use the @font-variation rule for everything.

For font-stretch I would prefer an integer range instead of a percentage. This allows the use of calc and makes the behaviour similar to the proposed font-variation-settings.

[khaledhosny]

Standard webfont font family with variable fonts, using a new woff2-variations format hint

There was a discussion during web fonts WG F2F meeting on how the format hints are not adequate to cover the granularity of the fonts. For example we have 4 OpenType color glyphs tables, or 3 different sets of layout tables and browsers support different combinations of them and the only way to get some of these features working across browsers and platforms is to ship the font with all of the tables and let the browser select which it supports (and then you can’t do that for some tables that has competing requirements). So I have been thinking may be we need a new capabilities hint that offers more granularity (can be a space or comma separated list) and leave the format hint for the font container as it is now.

[SergeyMalkin]

So I have been thinking may be we need a new capabilities hint that offers more granularity (can be a space or comma separated list) and leave the format hint for the font container as it is now.

This is one of the solutions we are considering as part of CSS font variations draft.