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
LinksIntroducing 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
• MicrosoftNote 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.
Track this please
(but I do not have any test payloads for now...)
GX: Only supported by Apple, on Macs.
MM: Only supported in Adobe apps.
OTVar: All major platforms involved and intend to support.
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.
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.
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.
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.]
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.
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?
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.
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.
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.