Intent to Ship: OpenType Variable Fonts

407 views
Skip to first unread message

Dominik Röttsches

unread,
Jun 28, 2017, 7:50:00 AM6/28/17
to blink-dev, Ben Wagner, Behdad Esfahbod
Contact emails

Spec
Current draft for OpenType variable fonts support as part of CSS Fonts Level 4, especially font-variation-settings, feature resolution and variable fonts specific properties:


TAG review not requested, but advise is welcome: Do I need a TAG review for the what could be considered consistent edits over the existing CSS Fonts Level 3 spec (updates to existing font selection algorithm, font-variations-settings analogous to the existing font-feature-settings, etc.)?

Summary


"Version 1.8 of the OpenType font format specification introduces an extensive new technology, affecting almost every area of the format. An OpenType variable font is one in which the equivalent of multiple individual fonts can be compactly packaged within a single font file. This is done by defining variations within the font, which constitute a single- or multi-axis design space within which many font instances can be interpolated. A variable font is a single font file that behaves like multiple fonts."

There are numerous benefits to this technology. A variable font is a single binary with greatly-reduced comparable file size and, hence, smaller disc footprint and webfont bandwidth. This means more efficient packaging of embedded fonts, and faster delivery and loading of webfonts. 

The potential for dynamic selection of custom instances within the variations design space — or design-variations space, to use its technical name — opens exciting prospects for fine tuning the typographic palette, and for new kinds of responsive typography that can adapt to best present dynamic content to a reader’s device, screen orientation, or even reading distance.

The technology behind variable fonts is officially called OpenType Font Variations. It has been jointly developed by Microsoft, Google, Apple, and Adobe, in an unprecedented collaborative effort also involving technical experts from font foundries and font tool developers."

The proposal for shipping OpenType variable fonts support in Blink affects at least the following aspects, more details in the tracking bug:
  1. Support for such web fonts which conform to version 1.8 of the OpenType standard and which make use of OpenType variations (by having an fvar table for glyph variations, and/or other OpenType variations features.)
  2. Enabling Variations in a backwards compatible way for Chrome running on OS'es that do not support OpenType Variations natively: Done through hybrid glyph rasterization stack, using the native stack (DWrite or CoreText) + FreeType cross-platform (e.g. on Windows and Mac OS < 10.12)
  3. Assigning axis values through font-variation-settings CSS - done in crbug.com/669455
  4. Integration of variable fonts axis parameters into layout operations, i.e. font shaping, returning correct size and metrics for font run measurements with variations applied: Done through integration with HarfBuzz & Skia (Thanks behdad@ and bungeman@)
  5. Animating font-feature-settings, done. (Thanks to alancutter@!)
  6. Matching web fonts based on canonical scalable axes such as width or weight or optical sizing, work in progress, local prototype complete, tests passing 
Out of scope for now:

Motivation
Allow greater flexibility for authors to use the additional font choice and styling properties. Extending the concept of responsive design to the typography dimension (denser fonts on narrow screens for example), while enabling this with a compact format that allows saving bandwidth on multiple font variations.

Link to “Intent to Implement” blink-dev discussion

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
Yes, through the hybrid font stack solution using FreeType for OpenType variations on OSes without native support.

Demo Link
(Demo pages 1, 2, 3, 4 using Chrome Canary with Experimental Web Platform Features enabled) 

Debuggability
The CSS additions for font-feature-settings and extensions to the font-stretch, style, weight CSS are editable and debuggable through DevTools as usual.

Interoperability risk & compatibility risk
Edge: Public support, from converstations with Edge and DWrite team. Limited support for OpenType Variations in Windows 10 Creators Update. Edge support announced at ATypI 2016.
Safari: In development and announced at WWDC 2017 for release in fall.
Web developers: Positive

Microsoft, Adobe, Apple were part of the initial OpenType variable fonts announcement. Both Microsoft and Apple plan on shipping this feature in OS and Browser.

Since these features will be mostly new, it's unlikely to break existing content. However, since it's a new typography standard that is being introduced into multiple browsers and OSes, we should test interoperability early and in cooperation with other implementations.

The CSS for font-stretch, font-style and font-weight in @font-face descriptors has been extended to support ranges, without breaking the existing syntax.

Is this feature fully tested by web-platform-tests?

There is a tracking bug for adding web platform tests for OpenType Variations support. The first set of tests has been upstreamed, which tests font-feature-settings and capabilities of the underlying OpenType font engine. A second set of tests which tests the font-style-matching algorithm with variations support is up for review.

The feature is additionally tested by Blink unit tests, as it is notoriously difficult to create reliable ref tests for font features due to slight differences in antialiasing color values due to different filtering and rounding.

Ongoing technical constraints
We generally rely on OS APIs for certain font specific features: font metric computations as well as glyph rasterisation on Windows and Mac are done through DirectWrite and CoreText respectively. 

On Linux, Android and ChromeOS we control the full font stack, we can coordinate the introduction of the feature and ensure having FreeType and other font libraries at the required version.

On OSes where the system rasterizer does not support OpenType Variations, we use a hybrid font stack solution with FreeType as the rasteriser for OpenType variations.

See above in the summary under "Out of scope for now": We won't support variable system fonts for now. 

OWP launch tracking bug

Link to entry on the Chrome Platform Status

Requesting approval to ship?
Yes.

Special Thanks
Special thanks to behdad@, bungeman@ from the Skia team, eae@, thestig@ from PDFium, alancutter@, and everyone who helped getting this ready.

Philip Jägenstedt

unread,
Jun 30, 2017, 6:07:29 AM6/30/17
to Dominik Röttsches, blink-dev, sligh...@google.com, Ben Wagner, Behdad Esfahbod
A very comprehensive intent, this one, sounds like a great new feature that we should ship. A few comments inline first.

On Wed, Jun 28, 2017 at 1:49 PM Dominik Röttsches <dr...@chromium.org> wrote:
Contact emails

Spec
Current draft for OpenType variable fonts support as part of CSS Fonts Level 4, especially font-variation-settings, feature resolution and variable fonts specific properties:


TAG review not requested, but advise is welcome: Do I need a TAG review for the what could be considered consistent edits over the existing CSS Fonts Level 3 spec (updates to existing font selection algorithm, font-variations-settings analogous to the existing font-feature-settings, etc.)?

It's a pretty big new feature and it looks like we'll be the first to ship. But the web-facing API surface isn't huge, and it looks like there's already been a lot of cross-vendor involvement. It looks like the whole feature is well past the point where design review is most useful.

It sounds like you were able to rely entirely on web-platform-tests and unit tests, is that right? Quite encouraging if so.

I really like the README that came with the second review, that kind of "how is this feature tested" view would be useful for many test suites I suspect.

(Wondered about directory structure in https://github.com/w3c/web-platform-tests/issues/6434.)

Ongoing technical constraints
We generally rely on OS APIs for certain font specific features: font metric computations as well as glyph rasterisation on Windows and Mac are done through DirectWrite and CoreText respectively. 

On Linux, Android and ChromeOS we control the full font stack, we can coordinate the introduction of the feature and ensure having FreeType and other font libraries at the required version.

On OSes where the system rasterizer does not support OpenType Variations, we use a hybrid font stack solution with FreeType as the rasteriser for OpenType variations.

See above in the summary under "Out of scope for now": We won't support variable system fonts for now. 

OWP launch tracking bug

Link to entry on the Chrome Platform Status

Requesting approval to ship?
Yes.

Special Thanks
Special thanks to behdad@, bungeman@ from the Skia team, eae@, thestig@ from PDFium, alancutter@, and everyone who helped getting this ready.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBszA-VU7TFewYN4AAfBWUx%3DB-TMCmJ4t%3DQrZZ27nv1FdQ%40mail.gmail.com.

Dominik Röttsches

unread,
Jun 30, 2017, 10:23:10 AM6/30/17
to Philip Jägenstedt, blink-dev, sligh...@google.com, Ben Wagner, Behdad Esfahbod
Thank you Philip for taking an initial look and the encouraging comments.

On Fri, Jun 30, 2017 at 1:07 PM, Philip Jägenstedt <foo...@chromium.org> wrote:
A very comprehensive intent, this one, sounds like a great new feature that we should ship. A few comments inline first.

Is this feature fully tested by web-platform-tests?

There is a tracking bug for adding web platform tests for OpenType Variations support. The first set of tests has been upstreamed, which tests font-feature-settings and capabilities of the underlying OpenType font engine. A second set of tests which tests the font-style-matching algorithm with variations support is up for review.

The feature is additionally tested by Blink unit tests, as it is notoriously difficult to create reliable ref tests for font features due to slight differences in antialiasing color values due to different filtering and rounding.
It sounds like you were able to rely entirely on web-platform-tests and unit tests, is that right? Quite encouraging if so.

Additionally there is pixel testing in Skia, compare https://cs.chromium.org/chromium/src/third_party/skia/gm/fontscalerdistortable.cpp plus FreeType and HarfBuzz did some additional, but mostly manual testing. I believe there is now good coverage for rasterization tests, font-feature-settings, font selection/matching and through this, also some advanced features such as GSUB, GPOS, and avar tables are covered when using variable fonts.
 
I really like the README that came with the second review, that kind of "how is this feature tested" view would be useful for many test suites I suspect.

Thanks. 
 
(Wondered about directory structure in https://github.com/w3c/web-platform-tests/issues/6434.)

I replied on the issue. Indeed, this should be discussed.

Again, thanks for doing a first pass on the intent and expressing your support.

Dominik

Philip Jägenstedt

unread,
Jun 30, 2017, 10:41:35 AM6/30/17
to Dominik Röttsches, blink-dev, sligh...@google.com, Ben Wagner, Behdad Esfahbod
Sounds great, just wanted to confirm that there wasn't a third category of testing (LayoutTests with internal APIs) needed here.

LGTM1

Chris Harrelson

unread,
Jun 30, 2017, 5:19:57 PM6/30/17
to Philip Jägenstedt, Dominik Röttsches, blink-dev, Alex Russell, Ben Wagner, Behdad Esfahbod
LGTM2

I think filing a TAG review request is a good idea regardless.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
 To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeW1YgvCW12sZ50eEzxLdouJcA-ewP8rmm76zepO3GUtA%40mail.gmail.com.

Mike West

unread,
Jul 3, 2017, 3:58:26 AM7/3/17
to Chris Harrelson, Philip Jägenstedt, Dominik Röttsches, blink-dev, Alex Russell, Ben Wagner, Behdad Esfahbod
LGTM3.


-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_yGnNbnOSvVc1c%2BD8B4b9T8VGRQZs8grKgy7qLGU9qZw%40mail.gmail.com.

Dominik Röttsches

unread,
Jul 3, 2017, 1:36:11 PM7/3/17
to Chris Harrelson, Philip Jägenstedt, blink-dev, Alex Russell, Ben Wagner, Behdad Esfahbod
On Sat, Jul 1, 2017 at 12:19 AM, Chris Harrelson <chri...@chromium.org> wrote:
LGTM2

I think filing a TAG review request is a good idea regardless.

Reply all
Reply to author
Forward
0 new messages