[OTVar] Introducing OpenType variable fonts

This morning, I've been having flashbacks or feelings of deja vu. So many of the opinions or arguments that are skeptical or hostile with regard to variable fonts are exactly the ones I remember from almost twenty years ago, when OpenType was first announced. I'm grateful to Matthew Butterick for expressing these arguments so cogently, with his usual clear and pleasant prose style. It's good to have them gathered and so expressed, even if it does give me a vertiginous sense of a time warp.

I don't have a lot of time today, so this is not a point-by-point response to Matthew's article — which it surely deserves —, but a few observations:

When OpenType was first announced, I remember a number of colleagues expressing the view that this was something that only benefited Microsoft and Adobe, that it would be a burden and expense on type designers, that okay so maybe some non-Latin scripts would benefit, but that these colleagues were perfectly happy making PS Type 1 fonts thank-you-very-much. As someone who had never been happy making Type 1 fonts — a mostly opaque technology, limited to 256 characters per font, requiring multiple files per font, not cross-platform compatible, requiring abuse of text encoding to achieve typographic quality —, I was confused by this response. I spent a lot of time explaining the benefits of the new technology — much of it on email listserves —, and ended up writing a number of articles on Unicode, OTL tables, layout engine interaction, complex script shaping, etc., all of which were novel topics for many type designers but are now, of course, simply the environment in which we all work.

At the time, we didn't know — no one knew — what the outcome of OpenType was going to be. I remember talking with Thomas Caldwell at Linotype, who had good reason to be cautious because they'd been burned by Apple's QuickDraw GX fiasco. Various predictions were made, both that OpenType would be a total flop and that it would solve all problems for all time. In the event, of course, the outcome has been neither dismal nor glorious. At the Unicode conference last year, I gave my own summary of where OpenType looks like a resounding success, and where it looks like a collection of unfulfilled promises. It is both.

Why, in response to criticisms of variable fonts, am I spending so much time talking about what happened almost twenty years ago? Partly because, as I say, so many of the criticisms sound familiar to me, but also because variable fonts are just an extension of the OpenType format. OT Font Variations consists of a number of new tables — none of which are required for any new non-variable OpenType font* — and minor version updates to some existing tables to integrate variable font technology (a minor version update means that existing software can read the newer tables and simply ignore the parts it doesn't understand). There is nothing in OT Font Variations that requires a font maker to make variable fonts or, indeed, to do anything different from what she is already doing if she chooses not to.

Further, the variable fonts technology has been deliberately designed around the ways in which a great many — probably most — type designers are already working, i.e. using interpolable design masters. Anyone who has ever used Erik van Blokland's Superpolator tool has already been exposed to everything that is possible in variable font design, and anyone working with the multiple master model in font production tools like Glyphs and FontLab Studio has, excuse the pun, mastered most of the new technology. When 'Generate variable font' is a button or an option in the font tool UI, alongside 'Generate TTF', 'Generate instances...', etc., and all from the same multi-master design source, will any type designer really feel that this technology is an expensive burden?

There will be expenses, of course. Customers will need to be educated. There will be inevitable support calls, especially while implementation of the format is uneven. And yes, many customers are going to need the fonts in more than one packaging format: variable fonts for some uses and environments, discrete instance fonts for others. None of this is unfamiliar to anyone who went through the transition from Type 1 to OpenType, and at least this time the new technology comes with an implementation spec, which should eliminate those support calls that arise from incompatibilities of the kind between, e.g., Microsoft and Adobe implementations of OpenType Layout.

There will be expenses, but also opportunities, for those who want to take them. Few aspects of OpenType have been without problems in their implementation, many of the promises remain unfulfilled two decades on, software support is still partial and inconsistent — and yet, OpenType has also fostered intense creativity in type design and the development of the first truly global type industry. I am in daily contact with colleagues around the world, designing and making fonts for many different scripts and languages, and that is in large part a result of having a shared technology. We didn't know that that would be the outcome when Microsoft and Adobe announced OpenType. We don't know what the outcome of OpenType Font Variations will be, either.


_____

*The STAT table is recommended, because it provides a better model for expressing type style attributes and family relationships than the name table.