Intent to Implement: OpenType Variable Fonts

[Dominik Röttsches]

Contact emails

dr...@chromium.org

Spec

Current draft for OpenType variable fonts, especially font-variation-settings, feature resolution and variable fonts specific properties:

https://drafts.csswg.org/css-fonts-4/

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."

from John Hudson's blog post on OpenType variable fonts:

https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369

OpenType variable fonts integration in the layout engine affects at least the following aspects:

1) Axis value assignments from font-variation-settings

2) Integration of variable fonts axis parameters into layout operations

3) Font matching for:

   * Matching based on canonical scalable axes such as width or weight or optical sizing.

   * Matching named instances

4) Feature resolution of CSS props, feature-settings and variation settings

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.

Interoperability risk

Firefox: No public signals

Edge: Public support

Safari: In development

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.

Compatibility risk

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. An interop test suite is under development.

Ongoing technical constraints

We 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 those platforms we depend on variable support in the OS. 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.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

That's the aim, but initial shipment will probably be limited to where OS support is available or where we control the full font stack.

OWP launch tracking bug

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

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/4708676673732608

Requesting approval to ship?

No, planning to work on the variable fonts implementation behind a runtime flag until it is reasonably complete.

[Emil A Eklund]

This is super exciting! \o/

[Dirk Pranke]

I also think this is exciting, but the "ongoing technical constraints" section worries me. Can you say more about what we think we will actually be able to support on the different platforms? Does Freetype already implement what we need, etc.?

-- Dirk

[Dominik Röttsches]

Hi Dirk,

thanks for the feedback.

On Thu, Dec 1, 2016 at 1:23 AM, Dirk Pranke <dpr...@chromium.org> wrote:

I also think this is exciting, but the "ongoing technical constraints" section worries me. Can you say more about what we think we will actually be able to support on the different platforms? Does Freetype already implement what we need, etc.?

Yes, FreeType from 2.6.5 does most of what we need, Skia has support for variation axis values on top of FreeType and CoreText. There are a few open issues on HarfBuzz, such as mark placement when specifying variation axis parameters but a good portion of support for font variations is already there. The demos that were shown at AtypI already ran on top of this stack of newer FreeType and HarfBuzz.

With that, supporting CSS specified variation axis values, shaping and rendering for web fonts on CrOS, Android and Linux based on the open source font stack will be possible quite soon. CoreText support in macOS Sierra looks pretty good too, I've done a demo for ATypI on Linux and Mac and have a development version running here which supports specifying arbitrary axis parameters. Windows 10 support for variation support is promised for 2017.

One issue that takes a little longer to resolve is supporting and matching against system fonts with variation support. System font matching for variation fonts will require changes to FontConfig and the font matching we implement for Android as well as Windows and Mac. This requires further investigation.

Hope this helps - I consider the technical path forward quite promising given that we're introducing a new technical concept across OSes and browsers. For the first time in this area we have broad industry collaboration and support for this kind of feature, the consensus was built already, now it's just™ about the implementation. Let me know if you have more questions,

Dominik

[Dirk Pranke]

Yes, that's exactly what I was looking for, thank you!

-- Dirk