[OTVar] Introducing OpenType variable fonts

Nick Shinn

Two reasons that Multiple Masters didn’t catch on:
1. Output issues at service bureaux.
2. No foundries producing fonts in the format. I tried, but there were technical problems I couldn’t surmount—mind you, that was before the interweb, so help was hard to get.

Ben Blom

I think I would call this a ‘restricted variable font’.

Two thoughts:

• In the future, the most sold variable fonts may be “restricted variable fonts”.
• In the future, there may be tools to convert a “restricted variable font” into an “unrestricted variable font”.

John Hudson

There are a lot of different motivations among the people who contributed to the OT Font Variations specification. James has mentioned only one of the benefits of the technology, which was a primary motivator for only some of the companies involved: smaller data size for serving fonts on the Web. If I had to pick a single motivator that made the exercise possible in the context of the OpenType specification — in the sense that it was the motivator for people at management level to give permission for staff to work on it — it would be data size, but not for serving fonts. Software companies are concerned about font footprint on embedded and mobile systems; heck, some are even concerned about ever expanding footprint in the desktop OS and app suites.

I heard more than once during the working group meetings, from participants from more than one industry partner, 'If we weren't spec'ing this in OT, our company would have gone ahead and implemented its own solution'. I'll leave that thought there for you to contemplate how messy and full of incompatibilities the result would have been for font makers to contend with.

Just because a particular motivation has made key players participate in the project, or has been overriding in the determination of whether the thing happens or not, does not mean that the different motivations of other participants are invalid or that these people were somehow duped into, um, carrying a scorpion across a river on their back. If people are confused about what the updates to OT 1.8 are all about, perhaps it is because so much has been packed into the variable fonts model. It isn't just one thing that provides one benefit to one set of people. If OS makers just wanted to reduce the font footprint, they could have spec'd a font compression format and been done with. Instead, they also responded to what at least some font makers have been asking for, some of them for the better part of two decades: the return of run-time interpolation, and in specific the GX TrueType variations model. And they responded to what some Web typographers had identified as the potential for such a model to be integrated with CSS to enable responsive fonts.

Only the powers that be will have much reason to think about them until they’re ready for mass consumption.

There's some truth in that, although one of the things that strikes me is just how quickly everyone is moving. A fairly advanced CCS draft integration has already been published. Aspects of infrastructure support have already shipped, and the rest is being worked on with almost unseemly speed, of a kind I have not personally witnessed since Microsoft played catch-up with Netscape in the 1990s. I've already seen prototype support in font tools from more than one developer. All this, within a little less than two weeks after the public announcement of the format.

I suspect there will be some slowdown somewhere along the line. Given how long CSS font modules have gestated in the past, it could be a while before the W3C actually publishes, although the nature of that process means there will be two fully-fledged implementations before that happens.

I also wouldn't be surprised to see some companies go for the low-hanging-fruit and provide compatible support for named instances, and then be slow in providing access to run-time interpolation. It is a risk, although possibly less so than it was for OpenType Layout. The motivations of the main industry partners on the software side are not identical, but there is considerable overlap, which means there will be competitive pressure. That was not the case for OTL, where Microsoft and Adobe had entirely different priorities.

Ray Larabie

This format was developed out of self-interest.

You could say that about a lot of things.  But we always find ways to exploit new toys and make them work in our own interest.

This won't revolutionize the way designers create static graphics. It doesn't give those designers anything they couldn't get from a superfamily. If you're thinking this won't have an affect on that particular buyer/seller relationship, you're probably right.

I think this is mainly about having scalable fonts in scalable systems rather than saving bandwidth. If I want an ad that looks good on a billboard, smartwatch and everything in between, in portrait, square and landscape, I want it to scale. But we can't use a superfamily for that. So now we have this new thing. Your average web site doesn't need it. But a certain segment of the market is going to want scalable fonts.

James Puckett

Ray Larabie said:

This format was developed out of self-interest.

You could say that about a lot of things.  But we always find ways to exploit new toys and make them work in our own interest.

To be clear, I meant what I wrote as a literal response to Richard’s question, not as a value judgement. I don’t mean to dismiss the entire variation font format or its developers. Only to point out that, at this time, “There isn’t much of a sales pitch…”, and that for most users this will remain the case for at least several years.

Jack Jennings

How much slower will this make text rendering engines to support this? It sounds like a not insignificant additional amount of processing to produce what would have previously been a more straightforward translation. Anyone producing benchmarks?

TimAhrens

Thanks for your detailed explanation, John.

Trying to summarize:

• We only have a meaningful reduction in data size (compared to single-style fonts) if there are more styles used than the number of masters. In practice, this means at least three different non-italic weights (e.g. Regular, Semibold, Bold) used on the page. As far as I have seen, this is rare on the web.

• If the number of masters is equal to the styles used on a web page then we might have a slight reduction in raw data, plus a reduction of server requests. Arguably, this could equally be achieved by a generic compression format.

• If the number of masters is greater than the styles used then variable fonts serve more data than single-style fonts.

• With variable fonts, italics still have to be loaded using a separate server request. Also, shared data is transferred twice.

Starting to wonder whether a much more primitive multi-file-compressed-container format could have solved the size and server requests issue more efficiently and more flexibly (as in: users build the multi-font resource from standard fonts themselves according to their needs, possibly automated by their website building tools).

Georg Seifert

One of the reasons why we only see two weights per website is because a third would add to much load.

Georg Seifert

So using two single fonts versus one variation font the later does give a similar download and technical complexity – but gives a lot more options. 

TimAhrens

Georg Seifert said:

One of the reasons why we only see two weights per website is because a third would add to much load.

Sure, it may be one of the reasons. But is it the main reason, most of the time? This would be interesting to investigate

Georg Seifert said:

So using two single fonts versus one variation font the later does give a similar download and technical complexity – but gives a lot more options. 

File size reduction is one goal of variations fonts, “more options”, i.e. stepless interpolation is the other one. At least as I understood (I am surprised the OT spec does not formulate the goals it wants to achieve).
 
I was strictly referring to the fil size goal here. Le’s not mix things here – the goals should be discussed independently, maybe they should even even be solved by different means, and Tinbergen would say.

Roel Nieskens

[...] most web sites don’t get enough traffic for reducing font data usage to have widespread appeal.

These sound like the words of someone who doesn't have to deal with SEO-obsessed customers raving about Google PageSpeed rankings on a daily basis. Whether smaller fonts files are overrated in the big picture or not, they'll always be preferable over larger fonts.

If the number of masters is equal to the styles used on a web page then we might have a slight reduction in raw data, plus a reduction of server requests. Arguably, this could equally be achieved by a generic compression format.

We've got TrueType Collections technology on the shelf, which apparently is being implemented in WOFF2 and is likely easier to implement in browsers than variable fonts. This would combine variants in a single file, sharing certain tables. Not as efficient as variable fonts, but combined with HTTP/2 (reducing overhead of requesting multiple files over a network) and WOFF2 (very good compression) might be as, or more, efficient as variable fonts for small sets of weights/variants. I wrote about about that on Typographica.

In the end I think variable type will be simpler and more efficient than stringing together a few separate solutions that sorta do the same, but I agree that overselling the compression benefits might backfire.

peter sikking

Chris Lozos said:

Universal also means that ‘everyone’ needs to be able to use it

Meaning software vendors like Apple, Adobe, Microsoft, and Quark need to help the user get to it with ease and use it without pain and suffering.

well, universal means operating-system level solutions: variable fonts UI on android, macOS, iOS, (the linux desktops). and the web platform, via the css API (taken care of by the determined w3c organisation).

individual application vendors (adobe, microsoft office group, google office group, quark) will not work towards the goal of getting this in the hands of everyone.

only with well-designed variable fonts UI—meaning the right level of power and complexity for a whole spectrum of different users—rolled out universally, there is a platform to actually sell (or even, give away) variable fonts.

Jens Kutilek

TimAhrens said:

Starting to wonder whether a much more primitive multi-file-compressed-container format could have solved the size and server requests issue more efficiently and more flexibly (as in: users build the multi-font resource from standard fonts themselves according to their needs, possibly automated by their website building tools).

I did a quick test with two styles, Light and Extra Bold.

Raw TTF (unhinted): 286 kB (143 kB each)
Packed into a TTC: 261 kB
Compressed as WOFF2: 66 kB

Same as TTF/GX (via Glyphs export): 191 kB
Compressed as WOFF2: 62 kB

So in theory, the TTF/GX contains the whole upright family, but to be true to the original design it would need at least a third master in the middle, and maybe some more exceptions.

peter sikking

Caren Litherland said:

Then Peter wrote (my emphasis):

I know that the no.1 success factor is that a single organisation is determined to push it through (i.e. to cover the costs and effort). Without that, nothing is going to happen

Why? One of the most significant aspects of this effort, it seems to me, is an unprecedented collaboration among corporations and independent designers. Why can’t the same sort of collaboration on front-end tools lead to “an empowering and universal solution”?

thanks for that question Caren, and making me think about it.

1) you point out yourself that the collaboration is ‘unprecedented.’ and it creates no president.

2) quite a bit of this thread is devoted to what made the companies involved sign off on the time and budget of the ones involved in the standard—did anyone work as a ‘frog’ (unpaid) on this up to now?

3) implementing the back-end for getting vari-fonts rendered looks go (to me); the same people from the big four involved in the standard will spec or write the implementation in their company, signed off by the same manager for the same rationale.

4) vary-fonts will work on the web, via the css API. it seems in practice that an API is a lot easier to do than GUI (although an API is also a user interface). this will make the core use cases for the technology work.

5) now for the universal UI. for the operating systems, this has to be made by very different teams at mostly the same companies (apple, microsoft, google). the managers of these other teams will look at their spreadsheets and say: ‘why would we spend a penny on supporting this? it works on the web, where it belongs.’

it is the same as OpenType features: the mechanical, can-be-just-made-by-engineers, brings-in-the-money part works. then the GUI part needs to be done, which is a rocket-science design problem, not for the faint of heart. and then the GUI part becomes optional; best figured out first by someone else, somewhere else.

6) for applications, it is one at the time (as long as they cannot—or do not want to, like adobe and office apps—get it for almost free from the operating system), each app with their own manager with a spreadsheet, even when they are part of the same company. see how OpenType features worked out at adobe: every app in a different state of neglect.

conclusion: universal UI will happen when one of the operating system companies finds a good business reason to do this. then the other operating systems may follow (feature parity). most of the apps will pick it up then for free, or even unwittingly. the home-brew class of apps (where it comes to typography), adobe and offices, will follow their own, individual, trajectory.

Yªssin Bªggªr

John Hudson said:

It is possible to build a variable font in such a way that all the design axes work in discrete steps between named instances, with no intermediary interpolated instances.

I was wondering about that. Good to hear. I think it is a valid criticism from variable fonts skeptics that type designers are also there to make certain choices that (some) users cannot or do not want to do; that they don't necessarily want/need an infinite amount of possibilities but a detemined amount of options.

I think I would call this a 'restricted variable font'.

I wouldn't. I think this assumes that the proper behavior for a variable font is to offer all the range of interpolation (all that is possible is available). It doesn't have to be. It is a pretty important thing, also for business reasons. We will have to see how things develop… but let's say a client of mine want the Regular and Bold styles of a font only in a variable font because smaller size, less requests etc but doesn't want to pay for the Medium style. In such a case I would want to provide a variable font that switches from Regular directly to Bold. I don't think that is a restricted variable font, it is a variable font containing what the client wants and expects, and for a lesser price.
Therefore I don't think

Obviously such restriction would be likely to provoke support calls from customers used to variable fonts behaving differently.

is necessarily true. It really depends what the purpose of the variable font we're speaking about is. I might not be confortable letting users decide what weight of Regular they should set the main text of their website in, while having no problem letting them decide how wide or condensed a headline sans-serif should be. It will be part of the marketing to explain the purpose and possibilities of a given variable font. At the same time, how webdesign and the webdesigners expectations evolves will determine how much freedom type designers will want to give with interpolation.

Ben Blom said:

Two thoughts:

• In the future, the most sold variable fonts may be “restricted variable fonts”.

Given what I described, I could definitely see that.

In the future, there may be tools to convert a “restricted variable font” into an “unrestricted variable font”.

Sure. But the piracy ship has sailed a long time ago. WOFFs can easily be converted back into OTFs. Our fonts are available on message boards and torrent platforms. At this point, worrying about that doesn't make much sense anymore.

Ben Blom

       I think I would call this a ‘restricted variable font’.

I wouldn’t. I think this assumes that the proper behavior for a variable font is to offer all the range of interpolation (all that is possible is available). It doesn’t have to be.

Agreed. How about “discrete variable fonts” and “continuous variable fonts”?

Thomas Phinney

TimAhrens said:

I like the idea of reducing the file size. If we really take this issue seriously then some questions arise:

1• From which number of used instances are variable fonts more size-efficient than single style fonts? Could a two-master variable font be smaller than the equivalent two single style fonts? Naturally, we need to compare compressed data; comparing raw data is meaningless. I’d be curious whether a good compression algorithm could pack two individual fonts into one file with the same size as a (compressed) two-master variable font.

2• What about cases when the user does not make use of all the possibilities (masters) that the font offers?

2a) Say, a variations font has a weight and width axis but someone uses only the regular width. Will there be tools (and will foundries allow) to “subset” variations fonts by removing unused masters/axes, similar to removing unused glyphs? Or, will foundries provide optional weight-axis-only variable fonts for these cases?

2b) Or, if a user only needs a single (interpolated) instance, would the foundry allow to generate a single-master font from it so as to reduce the data size?

To me, it appears that a lack of understanding by the font user, or a lack of tools or the appropriate EULAs, could eventually lead to more data being transferred than with the single-style system.

1. The details of exactly how many instances will be needed to make one or the other route more efficient will vary greatly, depending on how many masters are in the font, how many instances are used, and what compression scheme you are comparing against. We will need a fair number of production fonts and some experiments before I would be willing to make any strong generalizations.

I will note, however, that additional masters can be substantially more compact than separate fonts. But how much so varies....

2. It's hard to say what tool swill emerge and which will be used by users vs which will be used by foundries vs which will be used by hosting services. I do think the variable-fonts situation will encourage foundries and web font services to allow certain kinds of subsetting of axes/instances as is already being done for glyph complements today.

Richard Fink

  OK. The fog slowly lifts...

Variable Webfont Feature and Benefit #1: Client-side generation of font-weights on the fly, interpolated by the browser from a single file, instead of multiple files, each generated for a specific font-weight, means that a single browser request for a single file can generate what previously required up to nine separate files to travel over the network and required nine different browser requests.

Do Variable Webfonts Sound quicker? More efficient?  You bet. 

For example, to get the full range of weights for a font named greatfont.ttf. 

Today, in the absence of Variable Webfonts, you would have to download the following files:

greatfont-thin.ttf           (font-weight: 100  Thin || Hairline)

greatfont-extralight.ttf  (font-weight: 200  Extra Light || Ultra Light)

greatfont-light.ttf          (font-weight: 300 Light)

greatfont-normal.ttf      (font-weight: 400 Normal)

greatfont-medium.ttf     (font-weight: 500 Medium)

greatfont-semibold.ttf   (font-weight: 600 Semi Bold || Demi Bold)

greatfont-bold.ttf          (font-weight: 700 Bold)

greatfont-extrabold.ttf  (font-weight: 800 Extra Bold || Ultra Bold)

greatfont-heavy.ttf        (font-weight: 900 Black || Heavy)

And so, there's part one of the sale pitch.

It sounds great but I'm wondering if it's precisely true.

In particular - is there any control over the resulting font-weights the type designer must forsake to give the customer the benefits of runtime interpolation? 

For example, here on TD, designers like James Montalbano and Chris Lozos have pointed out that for them, the interpolations generated by the existing technologies for generating font weights automatically - like multiple master - are very much subject to review.  They tweaking from there as a starting point. Ultimately, it's the eye that rules. 

 

So, my question is, will the interpolations done in the browser match up exactly to the interpolations done by a type designer and posted individually on the back-end?

And if that's not what happens by default, CAN it match up exactly? - are there mechanisms for tweaking the results at different weights or are you stuck with what gets produced automatically? 

Belleve Invis

Just a reminder: variable font may be easier for pirating, given that the font file contains all design-time data for generating styles.

Peiran Tan

Side note: I really don’t hope to see Adobe cramming sliders into their already-crammed OpenType feature panel.

Georg Seifert

The sliders where there until some years ago. And it was not cramped, just one small section with a few sliders. 

James Puckett

Belleve Invis said:

Just a reminder: variable font may be easier for pirating, given that the font file contains all design-time data for generating styles.

It will generally still be easier to just go download a zipped filed containing the entire type family. It’s not as if they’re hard to find.

Roel Nieskens

On the subject of piracy and licensing and fallback fonts: as a developer you'd want to create a site with variable fonts, and then automating the CSS and fonts for older browsers. This would be similar to current build processes where fallbacks for older browsers are derived from modern technologies: adding CSS prefixes, resizing images, using bitmaps instead of SVG, etc.

As an example, a build process would inspect the CSS and see that one typeface is being used in two weights and four widths, all contained in the single file `my-variable-font.woff2`. It would then generate fallback CSS for older browsers, splitting those two weights and four widths to six separate old fashioned fonts files, e.g. `my-favariable-font-thin.woff2`, `my-variable-font-bold.woff2`, etc.

This would be a lot easier for developers, especially when you're playing with custom axis or variants that aren't offered as a regular old OTF/TTF font by the designer/foundry.

I can imagine this'll open a huge can of licensing worms. What are your thoughts on this?

Erik van Blokand

@Roel Nieskens apart from the licensing issue, I would not trust a CSS centric tool to be precise enough to assemble a working instance font out of a variable font. I don't think foundries would look forward to handling support questions when such a tool fails either.

Chris Lozos

Perhaps instead of "cramming" sliders into the opentype panel, Adobe might redesign the UI of their products and do a better job of it--including making sensible access to stylistic sets.

Belleve Invis

I have a series of question about APIs, especially about win32:

1. Can I install a variable font directly into my system, using the existing control panel? If so, how will the result being organized? Shown as a family or a single file?
2. Will GDI support displaying variable font? If so, predefined styles only or with interpolation?
3. Will DW on Win32 support displaying variable font? If so, predefined styles only or with interpolation?
4. Will DW on UWP support displaying variable font? If so, predefined styles only or with interpolation?

 @Mike Duggan

John Hudson

@Richard Fink

In particular - is there any control over the resulting font-weights the type designer must forsake to give the customer the benefits of runtime interpolation? 

Not 100% sure I understand the question as posed but, with regard to control, any location within the variations design space can contain a delta set for one or more glyphs. So there's no reason for the type designer to 'forsake' control. As an example, a font with a weight axis might contain not only delta sets at the extremes of that weight axis — say, thin and black — but also any number of intermediate delta sets to control regions of the axis between the extremes — say, regular and bold. Again, these intermediate delta sets could cover the whole glyph set, or any subset, or a single glyph. The intermediate masters do not need to sit directly on an axis: in a multi-axis font, a delta set can sit anywhere in the design space between the axes.

Rob McKaughan

TimAhrens said:

Starting to wonder whether a much more primitive multi-file-compressed-container format could have solved the size and server requests issue more efficiently and more flexibly (as in: users build the multi-font resource from standard fonts themselves according to their needs, possibly automated by their website building tools).

It's worth mentioning that the arithmetic isn't as simple as counting the number of masters vs the number of static fonts that might be used. A "master" in a variable font is stored much more compactly than a static font. A static font would include a bunch of extra tables beyond the glyf table, plus there's the extra overhead of a separate set of TrueType hinting instructions. Finally, the outline data can be more efficiently stored in a variable font than in a second static font: the variable font only stores deltas (often with only 8 bits per delta), and need not store every point (e.g. in a lowercase o, only the four extrema points likely need deltas, not the other control points which will get piece-wise interpolated similar to the IUP instruction in TrueType).

I suspect this is what's behind the difference @Jens Kutilek found above. The difference would be greater if the variable font were hinted in VTT.

So, the only real way to see if there are savings for an fvar font vs N static fonts is to do the file comparison.

Roel Nieskens

Erik van Blokand said:

@Roel Nieskens apart from the licensing issue, I would not trust a CSS centric tool to be precise enough to assemble a working instance font out of a variable font. I don't think foundries would look forward to handling support questions when such a tool fails either.

Why wouldn't you be able to generate a precisely matching instance font in a build process? You could simply calculate the outlines based on the values for all the axis, no?

Roel Nieskens

@Erik van Blokand Rereading your comment, I want to clarify that this conversion would be done by a build process (in JavaScript, Ruby, Python) on the server/developer side, not something CSS related in the browser.