[OTVar] Introducing OpenType variable fonts

John Hudson

A single font that behaves like multiple fonts

As I post this, colleagues from Microsoft, Google, Apple, and Adobe are at ATypI 2016 in Warsaw making the first public announcement of the OpenType Font Format specification version 1.8, and its key new technology: OpenType Font Variations.*

The Font Variations working group is pleased to be partnering with TypeDrawers to provide a centralised location for online discussion of the new technology. Members of the working group will be monitoring this thread and any others including the tag [OTVar] in the subject line, ready to answer questions. General questions or feedback on the technology can be provided in this thread. For discussion about specific aspect of the technology, or for individual queries, we recommend starting a new thread with an appropriate subject line, e.g. ‘[OTVar] CFF 2’.

* A note on terminology: the official name of the technology is ‘OpenType Font Variations’, while fonts including the variations technology are referred to as ‘variable fonts’ (a term introduced by Nick Sherman: 'Variable Fonts for Responsive Design').

Links

Introducing OpenType Variable Fonts
A medium.com article that I was tasked to write by the working group, explaining major aspects of the technology and highlighting some key implications of the format architecture for font makers and font tool developers.

OpenType Font Variations Overview
The new chapter of the OpenType specification explaining how OT font variations work.

OpenType 1.7 → 1.8 changes
A useful diff version of the two most recent version of the specification, highlighting changes.

Announcements by three of the working group industry partners:
Adobe • Google • Microsoft

Note that links to the OpenType specification currently point to a specific /otspec180/ folder. It is recommended to link to the published version of the specification when it is updated to the new version.

Thomas Phinney

FontLab announces support for OpenType variable fonts.

Belleve Invis

https://github.com/caryll/otfcc/issues/32

Track this please

(but I do not have any test payloads for now...)

[Deleted User]

The user and all related content has been deleted.

James Puckett

Sounds interesting for web stuff. I have no faith in Adobe, Apple, or Microsoft to implement this usably or consistently across their desktop software, so I don't expect this to matter there.

Chris Lozos

Adobe still has not totally supported stylistic sets so why dream they would move more quickly on this?

Mark Simonson

Jeez, what a bunch of cynics. I think this has a better chance of being supported than a lot of previous font technologies.

GX: Only supported by Apple, on Macs.
MM: Only supported in Adobe apps.
OTVar: All major platforms involved and intend to support.

Daniel Gamage

https://www.periscope.tv/w/1PlKQeQEkYkKE

I just wanted to point out the file savings demo around 16:00, which is a little self-evident but didn't occur to me until someone pointed it out.

Nick Shinn

This will be fun, especially for design axes other than the usual.
For instance, distress and bounce.
And for multi-colour/tonal effects.
Applications could even interpret such fonts dynamically, as animations.
I’ve long dreamed of leafy green type, rustling in the breeze.

John Hudson

James P, interoperable implementation is one of the central goals of how Font Variations has been developed and spec'd. It's been a very different process from OpenType Layout, for which there was no implementation spec or test suite.

The Font Variations process was more like the WOFF process: we specified not only the data format, but also how it should be interpreted, the algorithms used to manipulate the variations data, and are building a test suite against which to certify implementations. Does this 100% guarantee that no one will blow it at some point? No, but it's such a better process than OpenType 1.0.

Peiran Tan

I’m curious about how this could be controlled in the browser (or maybe it’s because I haven’t read enough spec that is already published). Is it controlled through CSS -font-feature-settings? Would we in the future write super-long declarations?

Chris Lozos

I am very curious about how the new design axis will work.  If there is only one 'file" how will the weights be interpreted--mostly, how will the type designer supply the information that the 'file" will use to interpret weights?  Will we still draw them as always but the software will package them in a different way with data tables to point the "file" in the correct direction as defined by the type designer?

John Hudson

[Suddenly wishing TypeDrawers had nested discussion threads.]

John Hudson

James M, I spun-off your interesting point about naming of arbitrary instances to a new thread:
http://typedrawers.com/discussion/1765/otvar-naming-arbitrary-instances

John Hudson

Pieran, yes, the idea is that variable font design space will be addressable in CSS. Members of the Font Variations and W3C CSS working groups are in contact, and variable fonts are on the agenda for this month's W3C TPAC meeting. Topics will include not only mechanisms to explicitly specify instances in CSS, but also enable conditional dynamic (responsive) web typography with variable fonts.

John Hudson

Chris, yes, you've got it: font makers will design as they do already, with multiple master design sources, and font tools will write this to the variable font as a single set of outlines and deltas to the axis extremes and any intermediate masters within the design space.

We're deliberately avoiding using the term 'master' when referring to the variable font data, because there is only one set of outlines stored, but we use the term when talking about sources. One of the criteria for the format was that it should be easy to generate from the kinds of interpolable sources that font makers are already typically making.

[Note also the aspect of all this for which David Lemon received applause during the ATypI announcement: Adobe are updating the CFF rasteriser to allow overlapping outline paths.]

John Hudson

[Now going on vacation for 24 hours. Hopefully some of the other working group members start contributing here, although many of them are in Warsaw at the moment.]

Kent Lew

Adobe are updating the CFF rasteriser to allow overlapping outline paths.

Excellent! That answers that. One of the first questions I had upon reading the overview.

Richard Fink

Mark Simonson said:

Jeez, what a bunch of cynics. I think this has a better chance of being supported than a lot of previous font technologies.

So do I. I think it's inevitable, now. 
There's been a fundamental change - I suspect - in the way the industry sees fonts.
There is just no competitive advantage to be had by introducing a format and then hoping it wins out.  Even if a company "wins" and has it's specification deployed by everyone else and, perhaps, annointed by a standards body, what have they gained? 
Nothing that I can see.  Apple, Google, MSFT, Adobe will continue to slug it out elsewhere but in the arena of fonts, if there isn't cooperation, nobody wins, everybody loses.  How about a nice game of tic tac toe?

(I think Thomas Phinney got it right in his blog post on this. The "battle" over color font formats taught everybody a lesson.)

That said.  I see OT 1.8 as a roadmap. An agreement on where to go next.  It's like a treaty that establishes borders. 

I don't think it's cynical, however, given the magnitude of the task, to assume it will take a long time to materialize.
Can't see it any other way. 

Ben Blom

font makers will design as they do already, with multiple master design sources, and font tools will write this to the variable font as a single set of outlines and deltas to the axis extremes and any intermediate masters within the design space.

For a font family with many different weights, the distance between the two ends of the weight axis is too big to only design the two fonts for the extremes of the axis. Because of that, I am used to design a “weight axis” font family as three separate fonts: (A) a font somewhere in the middle of the weight axis, (B) one at the thinnest end of the weight axis, and (C) one at the heaviest end of the weight axis. After that, the intermediate fonts are being created by interpolation between (B)-(A) and (A)-(C). Now I wonder if it is possible to feed three such fonts to the “variable_font”_font_tools to create a variable font which contains all relevant info from all those three fonts?

Read Roberts

Yes, it is. In fact, you get the most resolution out of the normalized design space if you do exactly that. Variable fonts must have a 'default' design which is, by definition, at position 0 along every axis, with range from -1.0 to 1.0. Basically, anything you can do in Superpolator or FontLab you can build directly as a variable font, including master designs at arbitrary points in the design space.  However, there can be conflict between accuracy of design intent (improved by having more master designs)  and file size (improved by having fewer master designs). For example the Adobe font family AcuminPro has 16 masters for two design axes, width and weight. This is to some extent a historical accident - it was originally designed with a smaller design space than it has now, and this was done by adding more master designs to the original set - but most of the masters are really needed. If Adobe built this as a variable font, the it would be nearly as large as 16 separate faces. However, using just 4 master designs looks OK to the casual users, but would not be acceptable to the original designers. It would take some thought to decide just how many and which masters to use to make a variable font for this family. Maybe there will be different choices for different markets - fewer masters for variable fonts for smart phone apps, more for a variable font for tablet apps, or other venues where file size is not an issue. We are all just beginning to think about these issues.

Dave Crossland

Kent Lew said:

Adobe are updating the CFF rasteriser to allow overlapping outline paths.

Excellent! That answers that. One of the first questions I had upon reading the overview.

Although Toshi asked if they will update it to allow components, and it seems, no.

Simon Cozens

Richard Fink said:

I don't think it's cynical, however, given the magnitude of the task, to assume it will take a long time to materialize.
Can't see it any other way. 

It's great that we're seeing support in font editors already, which is imperative for getting variable fonts out there, but it is indeed a huge task to make this happen down at the user level. Take an application like InDesign: you will need to implement it in the UI, have a renderer which supports it for display, have something which vectorizes it to PCL or PS for print, and you will also have to update the file format to store user choices about font variations. And a similar story for every single document-based file format; for instance, we're going to need a new PDF specification to handle this. (Not a hard job thinking about how PDF works, but new specifications, and then their implementation in readers, take time.)

I can see that it is going to happen, but I can't imagine you'll be printing out documents with variable fonts for a few years yet.

Silas Dilworth

Can’t wait for the font pricing fallout. Goodbye, bloated “superfamilies.” What to charge for a single OTVar file if the intervals are limitless?

Khaled Hosny

Printers do not need to know anything about variable fonts, not even PDF. You just send/embed an interpolated instance, and it will be the same as ever.

Simon Cozens

Huh, yeah, that would be a smart way to do it. And if you're generating instances as traditional OTF, you don't even really need a separate screen renderer either. So if you have to generate instances for this stuff already, it might make sense to have an instance generator step before your shaping step, rather than trying to render CFF2 directly. I'll have to look at the freetype implementation to see how it's being handled.

But you would still need to build the UI, store the settings in your document format, and you would still need to plug your instance-generator into the layout and processing pipeline. So still a lot of work to be done before it filters down to the user.

Chris Lozos

And here I sit, nearing the completion of a superfamily with 13 weights--done the old fashioned way.  Here is hoping the new technology will help me in future ventures.

Mark Simonson

Chris: Judging from watching the video of the ATypI presentation that Erik van Blokland shot (the one that Daniel shared above), particularly the part where David Lemon generates an OTvar font from the existing source of their recent Acumin family, we will be able to build on what we are already doing with masters in our current font tools.

James Puckett

Georg is already beta testing exports of two-master fonts from existing Glyphs source files. It doesn’t work well, but I’m sure it will get fixed once ATypI is over

Mark Simonson

Silas: I think the point you raise will probably be the most difficult business issue for independent font developers since the emergence of web fonts. I definitely don't think preserving our current business model is more important than the advantages this new technology will bring to users (and probably to font makers). Any business model that depends on technical inefficiencies is bound to fail sooner or later. I expect we will find a way.

Nick Shinn

I would imagine it could produce a surge in the number of typefaces published, if it is any kind of workflow speeder-upper.

I have a backlog of undeveloped ideas; meanwhile I am churning through the production of multi-font families.

Therefore the business trick will be to publish more typefaces, fewer fonts.