[css-fonts-4] Behavior for variable fonts with 'ital' axis ambiguous / underspec'ed

[drott]

@jpamental initially reported this issue discussing font matching and rendering results for a variable font that has an ital axis.

I do not see a clear and interoperable way to make them work described by the spec:

Assume there is a font face declaration as follows:

@font-face { /* Font Face 1 */
font-family: ItalAxisExampleFont;
font-style: oblique 0deg 20deg;
}

for a font that has an 'ital' axis ranging from 0 to 1.

And a style rule as follows:

* {
font-family: ItalAxisExampleFont;
font-style: italic;
}

The font matching algorithm describes that after no match for italic is found, oblique 20deg and above should be tried next, so Font Face 1 is matched.

However, as there is no way of specifying font-style: italic 0 1 the @font-face declaration and the actual font axes mismatch. The @font-face declaration pretends to be able to apply a slnt / oblique axis varying between 0 and 20 to the font. However, the font does not have a slnt axis.

If we really do not want to have a way of specifying a way for italic (not oblique) to be variable, then I am missing a clarification in the spec that would say something about how oblique <angle> <angle> and a resulting matched instance / style like oblique 20deg should be applied as ital 1 in terms of variation parameters to a font that does not have a real ital axis but instead is declared with oblique <angle> <angle>.

CC @behdad @kojii @jpamental

[svgeesus]

The ital axis is a bit weird; as registered, it is more for grouping roman and italic within a family than for a roman to italic variation axis:

The 'ital' axis tag is used within a STAT table of italic fonts to provide a complete characterization of a font in relation to its family within the STAT table. The Italic axis can be used as a variation axis within a variable font, though this is not expected to be common.

The problem is that when it is used as a variation axis, it is not used for matching.

@font-face { /* Font Face 1 has ital = 0.3 */
font-family: Example1;
font-style: auto
}
p { 
  font-style: italic; 
}

Currently, regardless of the value of the ital axis, it will never be matched with auto, only by explicitly declaring font-style: italic in the descriptor:

The auto values for these three descriptors have the following effects:
For font selection purposes, the font is selected as if the appropriate initial value is chosen

The initial value for the font-style descriptor is normal, so even with ital=1.0 it will never match unless explicitly described as italic. Instead, the low-level property has to be used:

i, em {
  font-family: Example1;
  font-variation-settings: 'ital' 0.8; 
}

[jpamental]

There are a few nuances to this that are worth noting.

When using a variable font in two files (one containing upright characters, one containing italics), family grouping works perfectly in all browsers:

@font-face { 
  font-family: ExampleFont;
  src: url('VariableFont_Roman.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-style: normal;
}
@font-face { 
  font-family: ExampleFont;
  src: url('VariableFont_Italic.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-style: italic;
}

This results in every browser I've tested rendering the text correctly, calling the right font file and rendering the proper glyphs, so that

font-weight: 725;

gets you the proper bolder weight;

font-style: italic;

gets you proper italics;

font-weight: 725;
font-style: italic;

gets you the proper italics, set to the bolder value on the weight axis

Where this breaks down is when you have a single variable font file that contains both upright and italics. It's worth noting here that from the type designers' (and OT spec creators') perspective, italics ('ital') is boolean (0 or 1, upright or italic), whereas slant ('slnt') is intended to be a range. And it's highly unlikely that you would have both italics and slant in the same design.

If I understand it correctly, this is why it was implemented in Safari in this way (to use the degree range to indicate the presence of an italic axis). According to @litherum the correct syntax would be something like this:

@font-face { 
  font-family: ExampleFont;
  src: url('VariableFont_Combined.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-style: oblique 0deg 20deg;
}

where the resulting behavior would be that the browser would inspect the font and based on the presence of an italic axis, clamp font-style: normal or font-style: italic to the correct axis value. If there is a 'slnt' axis, it would render at the indicated deg value along that axis.

Currently, if I use that syntax, everything works as @litherum describes. If I omit font-style entirely from the @font-face definition, it will work as expected in all the other browsers, but in Safari it will also synthesize italics on top of the proper use of the italic axis.

Of Note
In all cases, you still get the expected output if you use font-variation-settings

Proposed solution
Given that it is quite possible possible to have both a upright and italic character sets in a single file, it seems better to allow more specific declaration. I would suggest:

@font-face { 
  font-family: ExampleFont;
  src: url('VariableFont_Combined.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-style: normal italic;
}

for when you have upright and italics, and

@font-face { 
  font-family: ExampleFont;
  src: url('VariableFont_Combined.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-style: oblique 0deg 12deg;
}

for when a slant axis is present.

References:
You can see all of this in action on the guide I wrote on the MDN site (it currently uses the syntax that @litherum suggested in the italics section)
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Fonts/Variable_Fonts_Guide

And there's a CodePen of just the italics set up without the font-style declaration so you can see it the other way and edit as you see fit.
https://codepen.io/jpamental/pen/EeOyyZ

[svgeesus]

Related:

• Access arbitrary points on a variable 'ital' axis via font-style
• Support 1 @font-face (1 file) providing both normal and italic font-styles

[davelab6]

What needs to happen to move this forwards? :)

[svgeesus]

@litherum the specification as written conflates the slnt and ital axes, and assumes ital is a boolean. Do we want to fix that? If so how, and if not, how do we handle a font with an actual variable ital axis?

The MDN site to which @jpamental contributed takes a strong position:

The Italic (ital) axis works differently in that it is either on or off; there is no in-between.

Do we want to enforce that? (it is common, but not universal).

[LucianoGrossi]

I don't understand what motivates designers to create 2 fonts "A", "G" and others, for italic letters. I'm just an end-user, but I CAN'T STAND having to keep checking, before downloading a font, if there is only ONE font, for both the ITALIC and NON-ITALIC options...),=

[LucianoGrossi]

I don't know if it was clear, but what bothers me the most is the existence, in the same font, TWO different letters "A", as well as letters "G" and others...),=

[litherum]

(Sorry for not replying on this until now.)

I can't really put replies inline, so I'll selectively pull quotes from above.

The font matching algorithm describes that after no match for italic is found, oblique 20deg and above should be tried next

This has now shifted down to 11deg (though the exact value doesn't affect the argument at hand).

This results in every browser I've tested rendering the text correctly

Right. The idea is that the @font-face block should simply report the capabilities of the font file. No more, no less. In this example, there's a font that supports weights from 100 to 900 that isn't italic, and there's another font that supports weights from 100 to 900 that is italic. So far so good.

Where this breaks down is when you have a single variable font file that contains both upright and italics.

This is indeed the crux of the issue. When I designed this feature, I was assured that it was meaningless to say "0.5 ital", and that italics are, therefore, a boolean toggle. I did, however, neglect to handle the case where a font can support both values of the boolean toggle.

I was also assured that it would be a Bad Thing™ to make it easy for an author to request both oblique and italics at the same time. I think this is an orthogonal concern, though, as it affects the grammar of the font-style property, and not the font-style descriptor within @font-face.

I think @jpamental's proposal makes sense, as it agrees with the spirit of making the @font-face descriptor simply report the capabilities of the font file.

We do have a choice, though, whether we want a font to be able to advertise that it supports both italics and obliques. Do any such fonts exist?

If the answer is "yes," then this is probably the right grammar:

auto | [ normal || italic || [ oblique [ <angle>{1,2} ]? ] ]

If the answer is "no," then this is probably the right grammar:

auto | [ normal || italic ] | oblique [ <angle>{1,2} ]?

[dev-nicolaos]

I did, however, neglect to handle the case where a font can support both values of the boolean toggle.

Is this still the case or has there been any progress on this issue?

It's very strange not to be able to use font-style as a descriptor for a variable font file that contains both roman/upright and italic glyphs. If all my reading trying to understand this is correct, it sounds like the only way to use the italic glyphs from such a file is to use font-variation-settings property when applying the font? But that runs counter to the guidance to "use high level properties" where relevant, and also forces you to re-declare any other font variation settings since resetting the property will overwrite cascaded values for other axes.

Am I understanding this correctly?

[svgeesus]

@litherum wrote:

We do have a choice, though, whether we want a font to be able to advertise that it supports both italics and obliques. Do any such fonts exist?

It seems we need a good answer to that question, before designing a solution.

[nicksherman]

Several years ago, @djrrb made a version of his Roslindale typeface where the italic axis is separate from the slant axis (which is used for oblique settings). He talks about it here:
https://djr.com/notes/roslindale-variable-italic-font-of-the-month/

You can also preview how it works with a live demo here:
https://v-fonts.com/fonts/roslindale-variable-italic