You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
"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."
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.
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 implicitauto
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):
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
https://drafts.csswg.org/css-fonts-4/#font-style-matching
Additional references
https://bugs.chromium.org/p/chromium/issues/detail?id=1380486
The text was updated successfully, but these errors were encountered: