Intent to ship: OpenType Variation Font support

[Jonathan Kew]

As of this week, for the mozilla-61 cycle, I plan to turn support for
OpenType Font Variations on by default.

It has been developed behind the layout.css.font-variations.enabled and
gfx.downloadable_fonts.keep_variation_tables preferences.

Other UAs shipping this or intending to ship it include:
Safari (on macOS 10.13 or later)
Chrome (and presumably other Blink-based UAs)
MSEdge (on Windows 10 Fall Creators Update or later)

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1447163

This feature was previously discussed in this "intent to implement"
thread:
https://groups.google.com/d/topic/mozilla.dev.platform/_FacI6Aw2BQ/discussion

[L. David Baron]

This sounds great; it's a highly requested feature that's being
shipped with a decent amount of synchronization [1] across multiple
browser engines.

Is there something with a little more detail about how our (a)
feature set and (b) platform support compares with what other
engines are shipping? That is, are there substantive cases where
some systems will have variation font support on other browsers but
not Firefox, or substantive features that other implementations will
be shipping but we won't?

-David

[1] At least, it's pretty good synchronization compared to the
recent track record in the CSS, fonts, and layout world, though
other parts of the platform have somewhat better records here.

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[James Graham]

On 19/03/2018 22:32, Jonathan Kew wrote:
> As of this week, for the mozilla-61 cycle, I plan to turn support for
> OpenType Font Variations on by default.
>
> It has been developed behind the layout.css.font-variations.enabled and
> gfx.downloadable_fonts.keep_variation_tables preferences.
>
> Other UAs shipping this or intending to ship it include:
>   Safari (on macOS 10.13 or later)
>   Chrome (and presumably other Blink-based UAs)
>   MSEdge (on Windows 10 Fall Creators Update or later)
>
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1447163
>
> This feature was previously discussed in this "intent to implement"
> thread:
> https://groups.google.com/d/topic/mozilla.dev.platform/_FacI6Aw2BQ/discussion

Are there now (cross-browser) tests for this feature?

[Jonathan Kew]

There are a handful of tests now in
web-platform/tests/css/css-fonts/variations, and there a bunch more
currently in preparation (e.g. see
https://bugzilla.mozilla.org/show_bug.cgi?id=1436588).

JK

[Emilio Cobos Álvarez]

On 03/20/2018 11:22 AM, Jonathan Kew wrote:> There are a handful of

tests now in
> web-platform/tests/css/css-fonts/variations, and there a bunch more
> currently in preparation (e.g. see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1436588).

There's also https://github.com/w3c/web-platform-tests/pull/9373. Do you
know how interoperable are we on those tests? They seem to have caught
at least a few Blink and Edge compat issues.

-- Emilio

[Jonathan Kew]

Yeah, that's the PR that bug 1436588 relates to. :)

Many of the tests there are concerned with the CSS extensions to
font-{weight,stretch,style}, which we haven't yet implemented (that's
bug 1436048, bug 1436061).

(Note that Blink also hasn't fully implemented this, at least judging by
testing of Chrome stable: they have done the CSS parsing extensions, but
not hooked it up to the rendering side. Maybe that's in Canary by now?
Anyhow, just a data point that supports doing a gradual roll-out of the
feature, starting with font-variation-settings, which is the most basic
piece of support.)

I'm hopeful that we can get these extensions ready within the next cycle
or two, but in any case I don't think that should block exposing the
basic feature.

JK

[Jonathan Kew]

On 19/03/2018 22:42, L. David Baron wrote:

> Is there something with a little more detail about how our (a)
> feature set and (b) platform support compares with what other
> engines are shipping?

That sounds like it could be a worthwhile blog post somewhere....

In brief: everyone supports font-variation-settings, the most basic tool
authors can use to control these fonts.

The CSS spec also calls for higher-level linkage to (enhanced forms of)
the font-{weight,stretch,style} properties. Edge implements this; Blink
currently accepts [at least some of] the extended CSS values (e.g.
non-integer font-weight values) but doesn't have them hooked up to
variation font rendering; we don't yet implement this.

Regarding platform support: Edge, Safari and Firefox only support
variation fonts on up-to-date versions of Win10 and macOS, while Chrome
(AIUI) also supports them on older versions (by shipping an embedded
copy of FreeType to use in place of the system font rasterizer when it
doesn't have variation support).

On Linux, official Mozilla builds have variation support; distro builds
that use --with-system-freetype will also work provided the system
freetype is fairly recent, but old distros may still have a freetype
that lacks variation support.

I haven't tested recent Chrome on Android but I presume they have the
same support there as on desktop (as does Firefox).

So to sum up....

> That is, are there substantive cases where
> some systems will have variation font support on other browsers but
> not Firefox,

On older releases of macOS and Windows, Chrome will have it but Firefox
won't (neither will Safari/IE/Edge, however).

> or substantive features that other implementations will
> be shipping but we won't?

Support for the enhanced font-{weight,stretch,style} properties is
currently only shipping in Edge, AFAICT; Blink has parsing but not full
rendering support.

[gwh...@gmail.com]

Will 61 bring support for font-optical-sizing as well?

[Jonathan Kew]

On 20/03/2018 20:50, gwh...@gmail.com wrote:

>
> Will 61 bring support for font-optical-sizing as well?

Yes; it's behind the same pref as font-variation-settings, so the two
properties will be enabled together.

[dr...@chromium.org]

Hi Jonathan,

On Tuesday, March 20, 2018 at 1:16:42 PM UTC+2, Jonathan Kew wrote:

> (Note that Blink also hasn't fully implemented this, at least judging by
> testing of Chrome stable: they have done the CSS parsing extensions, but
> not hooked it up to the rendering side. Maybe that's in Canary by now?
> Anyhow, just a data point that supports doing a gradual roll-out of the
> feature, starting with font-variation-settings, which is the most basic
> piece of support.)

font-{weight,stretch,style} are parsed and hooked up to the variable fonts rasterization backend since we initially shipped OpenType Variations in M62. I implemented this in Blink, so if you are observing any issues, mind sharing them? I'd be happy to take a look.

We do ship our own FreeType on Linux and Android, so we have support for Variations there independent of system FreeType. On Windows, it's done through FreeType and available everywhere. On Mac we use FreeType for Mac OS < 10.12.

Dominik

[Jonathan Kew]

On 21/03/2018 08:03, dr...@chromium.org wrote:

> font-{weight,stretch,style} are parsed and hooked up to the variable fonts rasterization backend since we initially shipped OpenType Variations in M62. I implemented this in Blink, so if you are observing any issues, mind sharing them? I'd be happy to take a look.

Hi Dominik,

Thanks for the note - that's interesting. Maybe I'm missing something?

Simple testcase (requires Avenir Next Variable installed):

<!DOCTYPE html>
<meta charset=utf-8>
<style>
body { font-family: Avenir Next Variable; font-size: 24px; }
</style>
<body>
<script>
for (i = 400; i <= 700; i += 50) {
e = document.createElement("div");
e.textContent = "font-weight " + i;
e.style.fontWeight = i;
document.body.appendChild(e);
e = document.createElement("div");
e.textContent = "variation wght " + i;
e.style.fontVariationSettings = "'wght' " + i;
document.body.appendChild(e);
}
</script>

When I view this with Chrome, I see the expected range of weights for
the elements that use font-variation-settings. But those using
font-weight are all rendered with the default weight of Avenir, just
with a slight (and constant) synthetic-bold effect applied at
font-weight:550 and higher.

This led me to believe something isn't completely hooked up.... on
further experimentation, though, I find that it does work as expected if
the font is loaded from a @font-face resource with the appropriate
descriptors. So this seems to be only a limitation for installed fonts?

JK

[Dominik Röttsches]

Hi Jonathan,

This led me to believe something isn't completely hooked up.... on
> further experimentation, though, I find that it does work as expected if
> the font is loaded from a @font-face resource with the appropriate
> descriptors. So this seems to be only a limitation for installed fonts?

Yes, this is the reason, currently we do not support variable system fonts
on platforms other than Mac. In your example, it also only works if you
load the font through src: url(), not local() for example. This limitation
is tracked in Chromium issue 792874
<https://bugs.chromium.org/p/chromium/issues/detail?id=792874>. I have
plans to work on this soon.

Dominik

[rosesh...@gmail.com]

[Jonathan Kew]

I'm not sure if this was intended as a question, or what?

Anyhow, to update here: we decided to hold back from shipping on 61, to
give more time to be feature-complete and well-tested. So Variable Fonts
is currently on track to ship in Firefox 62.

JK

[anastiaarli...@gmail.com]

https://groups.google.com/d/topic/soc.culture.liberia/IyH3vHwRzJo