Just minutes ago, at the ATypI conference in Warsaw, the world was introduced to a new kind of font: a variable font. Jointly developed by Apple, Google, Microsoft, and Adobe, a variable font is, as John Hudson put it, “a single font file that behaves like multiple fonts”. Imagine a single font file gaining an infinite flexibility of weight, width, and other attributes without also gaining file size - and imagine what this means for design.
Imagine condensing or extending glyph widths ever so slightly, to accommodate narrow and wide viewports. Imagine raising your favorite font’s x-height just a touch at small sizes. Imagine sharpening or rounding your brand typeface in ways its type designer intended, for the purposes of art direction. Imagine shortening descenders imperceptibly so that headings can be set nice and tight without letters crashing into one another. Imagine this all happening live on the web, as a natural part of responsive design.
To facilitate just such advancements, people from our four companies (along with notable independent contributors) have been collaborating for more than half a year on a significant improvement to the OpenType font file specification that now includes a new technology: OpenType Font Variations, which allows type designers to interpolate a font’s entire glyph set or individual glyphs along up to 64,000 axes of variation (weight, width, etc.), and define specific positions in the design space as named instances (“Bold”, “Condensed”, etc.). Get a technical overview and a complete introduction in our joint announcement on Medium, penned by John Hudson:
While earlier font interpolation technologies emerged from the font format wars of the early 1990s and were developed and championed by individual, competing software companies, OpenType variable fonts are the product of a new collegiality aimed not only at defining a common standard but also interoperable implementations.
Variable fonts are real, but there’s work to do
Given this high-profile collaboration, it seems as if the whole world is moving in unison toward our future with variable fonts. But it’s going to take some time - and a lot of effort – before this new kind of font becomes something people can design with and readers can read.
We need fonts. Type designers need to make and offer variable fonts. To encourage this, our multi-company working group sweated every detail of the new OpenType specification and built tools to help convert existing type families into variable font files. Our own David Lemon demonstrated this conversion as part of the variable fonts announcement at ATypI, and representatives from all four companies are at ATypI this week to talk with type designers.
Type designers, at least the ones I have spoken with, are all too ready for variable fonts. Adobe’s early efforts to define the multiple master font format may not have gained traction in the 1990s (it was way ahead of its time), but it certainly influenced type design tools and workflows. The hard part now will be licensing. Nobody knows yet how to handle the business aspects of variable fonts. But we’ve been there before, with web fonts. We’ll find a good solution.
We need rendering engines that can show the fonts. For fonts to actually show up anywhere, software behind the scenes called a rendering engine has to make typesetting and rasterization calculations. Rendering engines are incredibly complex. They also take a long time to develop and test. But people who work on rendering engines are in this working group and collaborating. This is very promising.
We need browsers and design software to support the rendering engines. It’s great if variable fonts can technically be rendered, but it won’t matter unless our favorite software chooses to use the appropriate rendering engine. That can take quite a while - it took quite a while for web browsers to go from GDI to DirectWrite on Windows. But we got there! Look at it this way: our working group includes people whose companies make the Chrome, Safari, and Edge web browsers, as well as the world’s most popular design software.
We need ways for people to design with these new fonts. If we’re going to use them on the web, we need to define the appropriate properties and values as part of the CSS standard. Our working group has begun this effort, and you’ll be happy to know that Typekit’s own Bram Stein is involved.
And if design tools are going to help us make flexible typographic decisions, we’ll need to articulate those decisions and know how they relate to one another. Flexible design is complicated. I am personally working with the Typekit team, other teams at Adobe, our external integration partners, and you (yes, you!) to better understand that complexity so we can build appropriate tools.
And, we need you. Join us in raising a glass to today’s announcement, and our dedicated working group. Follow the discussion at TypeDrawers. We’ll certainly be talking more, as here at Typekit we work to help people make, find, get, and use variable fonts. If you have any questions for us, please ask. We would love to talk with you.
Imagine condensing or extending glyph widths ever so slightly, to accommodate narrow and wide viewports. Imagine raising your favorite font’s x-height just a touch at small sizes. Imagine sharpening or rounding your brand typeface in ways its type designer intended, for the purposes of art direction. Imagine shortening descenders imperceptibly so that headings can be set nice and tight without letters crashing into one another. Imagine this all happening live on the web, as a natural part of responsive design.
To facilitate just such advancements, people from our four companies (along with notable independent contributors) have been collaborating for more than half a year on a significant improvement to the OpenType font file specification that now includes a new technology: OpenType Font Variations, which allows type designers to interpolate a font’s entire glyph set or individual glyphs along up to 64,000 axes of variation (weight, width, etc.), and define specific positions in the design space as named instances (“Bold”, “Condensed”, etc.). Get a technical overview and a complete introduction in our joint announcement on Medium, penned by John Hudson:
While earlier font interpolation technologies emerged from the font format wars of the early 1990s and were developed and championed by individual, competing software companies, OpenType variable fonts are the product of a new collegiality aimed not only at defining a common standard but also interoperable implementations.
Variable fonts are real, but there’s work to do
Given this high-profile collaboration, it seems as if the whole world is moving in unison toward our future with variable fonts. But it’s going to take some time - and a lot of effort – before this new kind of font becomes something people can design with and readers can read.
We need fonts. Type designers need to make and offer variable fonts. To encourage this, our multi-company working group sweated every detail of the new OpenType specification and built tools to help convert existing type families into variable font files. Our own David Lemon demonstrated this conversion as part of the variable fonts announcement at ATypI, and representatives from all four companies are at ATypI this week to talk with type designers.
Type designers, at least the ones I have spoken with, are all too ready for variable fonts. Adobe’s early efforts to define the multiple master font format may not have gained traction in the 1990s (it was way ahead of its time), but it certainly influenced type design tools and workflows. The hard part now will be licensing. Nobody knows yet how to handle the business aspects of variable fonts. But we’ve been there before, with web fonts. We’ll find a good solution.
We need rendering engines that can show the fonts. For fonts to actually show up anywhere, software behind the scenes called a rendering engine has to make typesetting and rasterization calculations. Rendering engines are incredibly complex. They also take a long time to develop and test. But people who work on rendering engines are in this working group and collaborating. This is very promising.
We need browsers and design software to support the rendering engines. It’s great if variable fonts can technically be rendered, but it won’t matter unless our favorite software chooses to use the appropriate rendering engine. That can take quite a while - it took quite a while for web browsers to go from GDI to DirectWrite on Windows. But we got there! Look at it this way: our working group includes people whose companies make the Chrome, Safari, and Edge web browsers, as well as the world’s most popular design software.
We need ways for people to design with these new fonts. If we’re going to use them on the web, we need to define the appropriate properties and values as part of the CSS standard. Our working group has begun this effort, and you’ll be happy to know that Typekit’s own Bram Stein is involved.
And if design tools are going to help us make flexible typographic decisions, we’ll need to articulate those decisions and know how they relate to one another. Flexible design is complicated. I am personally working with the Typekit team, other teams at Adobe, our external integration partners, and you (yes, you!) to better understand that complexity so we can build appropriate tools.
And, we need you. Join us in raising a glass to today’s announcement, and our dedicated working group. Follow the discussion at TypeDrawers. We’ll certainly be talking more, as here at Typekit we work to help people make, find, get, and use variable fonts. If you have any questions for us, please ask. We would love to talk with you.