[css-fonts-4] Avoid font synthesis outside of variable range

[drott]

We propose that if a variable font is declared and embedded with a @font-face and correctly declares its available ranges for font-weight and font-style or uses implicit auto ranges, no synthetic bolding or obliqueing should happen outside the supported or declared ranges of that variable font.

Reasoning: We interpret that if an authors embeds and uses a variable font, the intent is to use the supported ranges of this font, and not trigger any synthesis on top.

Otherwise what happens is a weird combination of font-designer-intended oblique or bold styles from the font, plus an additional synthetization applied by the UA.

One extreme example from Firefox (thanks to Munira (@tursunova) for test case and investigation) but similarly happens in Chrome (Chrome can't do variable obliqueing by number of degrees, but when it identifies a need for synthesis, then applies a fixed 20 degree skew):

    @font-face {
        font-family: "Inter";
        src: url('Inter-VF.subset.ttf');
    }
    .style60 {
        font-family: "Inter";
        font-size: 3em;
        font-style: oblique 60deg;
    }

This was found while @tursunova and I worked on an issue extracted from this interop 2024 proposal: web-platform-tests/interop#64

Related spec parts:

4.4. Font property descriptors: the font-style, font-weight, and font-stretch descriptors

"User agents that implement synthetic bolding and obliquing must only apply synthetic styling in cases where the font descriptors imply this is needed, rather than based on the style attributes implied by the font data."

https://drafts.csswg.org/css-fonts-4/#font-style-matching

If font-synthesis-style has the value auto, then for variable fonts with a slnt axis a match is created by setting the slnt value with the specified oblique value; otherwise, a fallback match is produced by geometric shearing to the specified oblique value.

Additional references

https://bugs.chromium.org/p/chromium/issues/detail?id=1380486

[svgeesus]

correctly declares its available ranges for font-weight and font-style

Does correctly mean anything special (like a check against the actual font) here?

[drott]

Does correctly mean anything special (like a check against the actual font) here?

I meant this mostly to describe an @font-face declaration that would not restrict the available stretch/style/weight range to 0.

[svgeesus]

The spec currently says:

The value for these font face style attributes is used in place of the style implied by the underlying font data. This allows authors to combine faces in flexible combinations, even in situations where the original font data was arranged differently. User agents that implement synthetic bolding and obliquing must only apply synthetic styling in cases where the font descriptors imply this is needed, rather than based on the style attributes implied by the font data. However, variation values applied to fonts defined with '@font-face' will be clamped to both the values specified in these descriptors as well as the values supported by the font file itself.

That last sentence seems to cover synthesizing outside the range from the descriptor, and also outside the range from the font. Is it clear enough?

@drott @tursunova

[drott]

User agents that implement synthetic bolding and obliquing must only apply synthetic styling in cases where the font descriptors imply this is needed, rather than based on the style attributes implied by the font data.

Thanks for following-up. I don't think this is clear enough, because this sentence IMO still leaves room to interpret that synthetization may be required ("font descriptors imply...needed") if oblique or bold requested styles are outside the variable range.

However, variation values applied to fonts defined with '@font-face' will be clamped to both the values specified in these descriptors as well as the values supported by the font file itself.

This sounds to me more like it covers font-variation-settings:, and could do with a clarification that implied application of variation parameters (which happens for example for font-weight, translated to a wght variation axis value) are covered here as well.