Bug 163790 – font-variation-settings at or beyond axis extremes result in the axis reverting to default

• Component: Text
• Status: RESOLVED DUPLICATE

[Laurence Penney]

Created attachment 292357 [details]
HTML (with a bit of PHP) to show how some values close to axis extremes revert to default. The $makesafe variable is a toggle which ensure values are within the range

Using font-variation-settings beyond axis extremes results in the axis reverting to its default. Sometimes using font-variation-settings *at* axis extremes results in the same undesirable behaviour. Settings at or beyond the extremes should (surely?) be clamped to that extreme.

To replicate the bug, try Skia, which contains the following raw data in the fvar table (min, default, max):

wght: 00007AE1, 00010000, 00033333 = 31457, 65536, 209715
wdth: 00009EB7, 00010000, 00014CCC = 40631, 65536, 85196

These correspond to the extremes, expressed in CSS:

font-variation-settings: 'wght' 0.47999572753906, 'wdth' 0.61997985839844;
font-variation-settings: 'wght' 3.1999969482422, 'wdth' 1.2999877929688;

These settings do not result in expected behaviour. In particular the 'wght' seems to become default. Subtracting 0.0001 from the max weight does not fix the problem, however subtracting 0.01 does fix it. See the difference by using the $makesafe toggle in the attached PHP file.

[Myles C. Maxfield]

This is intentional. From the spec[1]:

"Axis values not present in the font, or axis values greater or less than the range supported by the font, are ignored and therefore have no effect"

[1] https://drafts.csswg.org/css-fonts-4/#low-level-font-variation-settings-control-the-font-variation-settings-property

[Myles C. Maxfield]

I'm not sure if values exactly equalling the maximum/minimum are expected to work on any other piece of software

[Radar WebKit Bug Importer]

<rdar://problem/28893836>

[Laurence Penney]

(In reply to comment #2)
> I'm not sure if values exactly equalling the maximum/minimum are expected to
> work on any other piece of software

I tried values for Skia that are definitely within the min and max:

<?php

$d = 6;
$font['wght']['min'] = (31457.0+$d)/65536.0;
$font['wght']['max'] = (209715.0-$d)/65536.0;
$font['wdth']['min'] = (40631.0+$d)/65536.0;
$font['wdth']['max'] = (85196.0-$d)/65536.0;

echo "<div style=\"font-variation-settings: 'wght' {$font['wght']['min']}, 'wdth' {$font['wdth']['min']};\">"; ?>Check the metrics</div>";

echo "<div style=\"font-variation-settings: 'wght' {$font['wght']['min']}, 'wdth' {$font['wdth']['max']};\">"; ?>Check the metrics</div>";

echo "<div style=\"font-variation-settings: 'wght' {$font['wght']['max']}, 'wdth' {$font['wdth']['min']};\">"; ?>Check the metrics</div>";

echo "<div style=\"font-variation-settings: 'wght' {$font['wght']['max']}, 'wdth' {$font['wdth']['max']};\">"; ?>Check the metrics</div>";

?>

These are designed to resolve to predictable Fixed (16.16) values that are definitely >min and <max.

However $d must be 6 before correct width behaviour happens, and $d must be 7 before correct weight behaviour happens.

So, to retitle the bug, "font-variation-settings just within, at, or beyond an axis's extremes result in that axis reverting to default".

[Myles C. Maxfield]

Related: https://github.com/w3c/csswg-drafts/issues/647

[Myles C. Maxfield]

WebKit just passes the values into the platform, so this bug is in the platform rather than the browser.

Perhaps I could work around it...

[Myles C. Maxfield]

I'm going to fix this bug in the patch I'm working on for https://bugs.webkit.org/show_bug.cgi?id=165948

*** This bug has been marked as a duplicate of bug 165948 ***