[OTVar] Introducing OpenType variable fonts

Stephen Coles

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

I hope the new paradigm will shift the consumer’s perception of value away from an arbitrary number of interpolated styles (which is sometimes inflated to justify a certain price) and towards the specific masters and axes, which are the main objects of a designer’s labor. That will require providers to clearly explain these aspects of a font, which will be much more difficult than simply touting the number of weights and widths, but it could help to focus valuation on the stuff that requires the most time, expertise, and talent. 

Belleve Invis

@John Hudson
I have a question, does Variation support MATH table?
It is not mentioned in the spec, but math values can have a device table which is used for variations.

Khaled Hosny

It was mentioned in the presentation that SVG and MATH tables are not supported yet.

Thomas Phinney

James Montalbano said:

Here's hoping they get some proper support. Naming a font style Wt562Wd420 is not going to cut it. Are you listening Adobe?

As I mentioned in a couple of other places, this was a consequence of very short font menu name length limits at the time. Given that there could be three-axis fonts, and style names limited to as few as 16 characters, and axis values could be 4 digits... Adobe didn't have a lot of better options.

MS Word still enforced an effective 32-char limit on style names last I checked, but even that would be enough to allow "Weight 562 Width 420" which would be a lot less painful naming scheme.

Thomas Phinney

Peiran Tan said:

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?

Yes, you can use CSS font-feature settings. It already works with variable fonts in Chrome and Edge browsers on the latest Windows 10, in fact. I think you can see it in the demo video.

Thomas Phinney

Daniel Gamage said:

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.

The space saving aspect is a huge part of the revived interest! More important than the typography advantages for some key backers. But there is a synergy between the two that increases the enthusiasm of the players. Some care more about one or the other, but everybody sees the combo as a good thing.

Peter Constable

Here are quotations that various vendors provided us ahead of time with their reactions to our announcement of OpenType Font Variations:

Monotype:
"As technology advancement is critical to the long-term success of the type industry, Monotype is thrilled to have played a role in development of OpenType Font Variations. This important technology will allow us to improve the value of type solutions we can offer to type designers, partners and customers."

David Berlow, Font Bureau:
"As a pioneer developer of Apple’s GX variations in the 1990’s, Font Bureau is delighted to be working with Type Network and its foundry partners to support the new OpenType Font Variations standards."

Dalton Maag:
"We believe that variable fonts are a major step forward as a technology which serves the ambition of font creators, and allows us to meet the demanding needs of font users everywhere. We can’t wait to start exploring how we can solve everyday typographic problems in new ways."

Akihiko Morisawa, President and CEO, Morisawa Inc.:
"Morisawa expects that the incorporation of these new specifications into both our Roman and CJK typefaces will provide added value to our clients and creators."

SinoType:
"As a widely accepted platform and standard, we need OpenType to evolve continually.  The OpenType Font Variations initiative is a big step forward that we want to support and implement in our CJK font production!"

Dutch Type Library:
"DTL and URW++ will support the new font variation extensions for OpenType within our font production tools like OTM and will continue to adjust the tools to the future technological OT development."

Tom Phinney, President, FontLab:
"FontLab is excited to see axis-based fonts return as an end-user format, and has already begun adding support for OpenType Fonts Variations to FontLab VI, and intends to ship it with the initial release of the app."

Thanks to all of them for their support!

Marc Oxborrow

This discussion is such geeky fun. Watching/reading with great interest.

[Deleted User]

The user and all related content has been deleted.

Ray Larabie

Typodermic Fonts:
"Wow! Neato!" 

Ben Blom

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

As far as I know, the current CFF rasteriser sometimes behaves erratic with sharp inner corners of glyphs. To prevent such problems, sharp inner corners can be cut. Will such erratic behavior be a thing of the past in the updated CFF rasteriser?

Russell McGorman

James Montalbano said:

Very exciting, and not to be a drag, but...

Many users are still clueless as to what an OpenType feature is, 

This, unfortunately, is very true. I think partly attributable to a lot of designers just not placing value in being a little type savvy, but more to terrible OT interfaces which make features unnecessarily difficult or awkward to access. For an example of where better Interface design can make a difference, CorelDraw - which took years to finally decide to support OpenType, but now that they do, they seem to have a pretty reasonable interface: (about three and a half minutes in): https://www.youtube.com/watch?v=b_mn8J327xc . 

(I don't use CorelDraw, personally, but where they're going looks promising.)

attar

Dave Crossland said:

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

Curious why you would need components in CFF? Subroutinization is a more flexible compression system, essentially a generalization of components.

Belleve Invis

Another question: CFF2's INDEX supports more than 65535 items, does this mean that OT will support very lagrge font in the future? However all other tables' record length for GID are 16-bit.

Peter Constable

@Belleve Invis: There are no plans at this time to extend the 64K glyph limit. As Adobe prepared their draft for CFF2, they asked the working group for input on the size of that item: whether to limit it to 64K; the consensus was not to limit something to 64K solely because GIDs are limited to 64K.

David Sudweeks

Hi everyone. With hope, this is a really basic question about including italic in the ‘single binary.’ With Multiple Master technology you would still require two font files to contain Roman and italic versions of, say, Myriad MM. But by the new OpenType spec, italic is intended to be a variation, right? And its contours are included and specified as italic in the fvar table, yes? Thanks.

Chris Lozos

True italic is a different beast.

John Hudson

@David Sudweeks

My understanding is that, typically, italics would not be incorporated into the single variable font with roman. For a true italic, the glyph shapes and architecture is so different from that of roman, that it wouldn't make much sense to roll them together.* That said, the Font Variations architecture does provide ways in which it could be done. There's just no particular benefit to doing so, since you would need to store a full set of italic variant glyph outlines alongside the roman outlines: they might as well be in a separate font. The new STAT table provides for both in-font and across-family style mapping relationships.

* The exception — in both variable and non-variable fonts — is CJK with both roman and italic Latin subsets. In this case, though, italic wouldn't be an axis, but would be accessed using the <ital> GSUB feature, and have a delta sets for those glyphs paralleling those for roman weight, width, etc..
_____

There is a registered Italic axis tag in the 'fvar' table spec (and also a separate Slope tag), but I'm not entirely sure how it would be used. It's on my list of things to seek clarification and examples of.

Allan Murray

".. the recent Windows 10 Anniversary edition has already been updated to support variable fonts. Applications such as the Edge and Chrome browsers that use DirectWrite are already able to select some named instances in fonts with weight and width axes."

Are there any example OpenType Variable font(s) available so we can see this in action?

John Hudson

@Thomas Phinney wrote

Yes, you can use CSS font-feature settings. It already works with variable fonts in Chrome and Edge browsers on the latest Windows 10, in fact. I think you can see it in the demo video.

Unless I missed something very significant, what this means is that these browsers have been updated to support named instances in variable fonts, i.e. CSS font-feature properties can be used to reference named instances in variable fonts in the same way that they can be used to reference stand-alone fonts. This is a big step in terms of already being able to take advantage of the file size benefits and single-resource aspects of variable fonts, but doesn't yet mean that arbitrary instances or responsive typography are possible with CSS. We're just beginning the process of engagement with the W3C CSS working group.
_____

I suspect that for font makers and typographers, it is the arbitrary instance and dynamic variation aspects of variable fonts that strike a chord, more than the packaging benefits, so I think it is important to be very clear what we mean when we talk about things being 'supported' or 'working'. Those of us in the working group knew all along that support for named instances was going to come first, but this might not be obvious to people who are excited by the prospect of responsive typography.

David Sudweeks

Thanks @Chris Lozos & @John Hudson. Apparently I had let the idea of the whole font family fitting into a single font file go too far. Perhaps then the thinking behind the registered italic axis is that it’s used for faces with multiple italics, like Auto from Underware?

Peter Constable

@David Sudweeks: The reason for having an italic axis defined in the spec was not particularly motivated by thinking that people would implement italics as a variation from roman in a variable font, or thinking there'd be a common interest in having multiple variants of italics. Rather, it was mainly motivated by our addition of the 'STAT' table, as we wanted that table to be able to capture all design distinctions within a family.

Peter Constable

@Thomas Phinney, @John Hudson: I demo'd some weight/width variations from a variable font in shipping versions of Edge and Chrome that have not been updated in any way specifically related to supporting variations. This was possible because there is a certain limited amount of functionality for variable fonts that is accessible using existing DirectWrite APIs that doesn't require the app to have any awareness of variable fonts --- as far as the app knows, there are a set of static-instance fonts. The limitation is this: the fonts have weight or width axes only (since this falls within DirectWrite's WWS font family model), only named instances can be used, and the instances must be detectable using the WPF Font Selection algorithm, which relies on certain sub-family naming conventions rather than correct usWeightClass or usWidthClass values, since DirectWrite hasn't yet been updated to associate axis values from the fvar or STAT tables with DirectWrite's existing weight or width font properties. This is definitely limited functionality for now, but it's at least enough for people to see the concept of a variable font working in Windows.

Roel Nieskens

Combining five separate fonts at 657 kB into a single 199 kB file is impressive and will have many a front-end developer whisper sweet things into OpenType 1.8's ear. Only if you're using one single weight will a regular font win out.

From a network request perspective, by the time variable fonts are around we'll have pretty good HTTP/2 support which makes the "it's all in a single file" argument a little less exciting, but on the other hand won't have "italic still need a separate file" take much shine off of the single file thing.

Regarding performance, will WOFF2 be automatically optimised for these new files/tables? Or will we need a WOFF3 for efficient compression of the new tables?

John Hudson

@Roel Nieskens

...but on the other hand won't have "italic still need a separate file" take much shine off of the single file thing.

Variable fonts contain single font packaging for typefaces. I know terminology around type and font is often confused, and there isn't consistency even among type designers and vendors, but I've always maintained that roman and italic are different typefaces within a type family (this usage is clearly that used in the metal period, when romans and italics were sometimes marketed under separate names — e.g. Perpetua and Felicity —, indicating that they were understood separate typefaces with a familial relationship, not styles of a single typeface; also, some roman typefaces were paired with more than one italic typefaces).

[Aside: I suspect variable fonts may challenge some of our assumptions about what it is that we make and what it is that we sell. For the past thirty years, we've been selling licenses to font software, i.e. to particular packages of typefaces, because that was legally the easiest way to express what was being sold. Will this remain the case? The anxiety already being expressed by some type designers about how EULA terms and pricing will convey the value of variable fonts is, I think, a first sign of these assumptions wavering. Maybe it's time to start questioning what we are selling?]

Regarding performance, will WOFF2 be automatically optimised for these new files/tables? Or will we need a WOFF3 for efficient compression of the new tables?

Tom Phinney has, I believe, been doing some tyre kicking of existing WOFF and WOFF2 tools being fed variable fonts. In theory, there should be no problem with basic compression of the new and updated tables in either format, but that needs to be confirmed. The next step will, indeed, be to look at whether and how variable font data can be further optimised in the two-step WOFF2 process, which might imply an update to the 'content-aware preprocessing' step. Whether this can be done under WOFF2 or would require a WOFF3 format, I'm unsure. It's something at which the W3C Webfonts working group needs to start looking.

John Hudson

Maybe it's time to start questioning what we are selling?

cf. http://typedrawers.com/discussion/comment/22918/#Comment_22918

Tamye Riggs

Video of the OT 1.8 announcement and presentations/discussions from ATypI 2016 in Warsaw. https://www.youtube.com/watch?v=6kizDePhcFU

Chris Lozos

Thanks, Tamye!

Belleve Invis

The third question: can the `vsindex` being used in the middle of a charstring, instead of at the beginning?

Nick Shinn

There are two kinds of italic: those that are oblique versions of roman (with various optical corrections), and those that have fundamentally different letter forms, e.g. /a and /g with a different number of storeys. 

And some typefaces, such as Electra, IIRC, have both.

Presumably, this new format would enable very compact oblique italics, courtesy of slant-plus-optical-correction algorithms.