Variations fonts and OpenType 1.8

The first day of the 2016 ATypI conference was marked by the release of a major update to the OpenType font format. A panel of speakers representing the major players in font technology over the past several decades announced the update together. Although there are several changes under the hood, the key new feature is the ability for a single font file to encode sets of delta values that programs can use to automatically interpolate changes in font weight, width, and other features, each throughout a continuous range. When software support is fully rolled out, that will all but eliminate the need to distribute font families as collections of individual font files, as well as removing many longstanding assumptions about font usage.

Variations

Peter Constable from Microsoft started the session off, noting that the results being presented were a year in the making, based on discussions held at ATypI last year. But, he added, "there is nothing new under the sun." Most of the ideas encapsulated in the new revision have existed in other forms for quite some time.

A variations font (or, alternatively, variable font) is a single font file that can behave like multiple fonts. At runtime, any combination of settings on a continuous variation range (requested by the user or by software) can be used. Variations fonts can have multiple axes of variation (such as weight, width, and slant). There are no intrinsic limits to how many variation axes a font can provide, and there is no need for any particular glyph to be altered by every axis. For example, an "optical size" axis might be expected to increase the relative heights of lower-case glyphs with respect to the upper-case glyphs, but leave the punctuation unaltered.

The variations can affect not just glyph outlines, but font metrics, too: widths, font-wide ascent and descent values, left and right side bearings, horizontal and vertical kerning, and so on. Variations can also affect OpenType layout rules—for instance, by substituting simpler versions of a glyph at small optical sizes or at extremely heavy weights, or by adjusting the positioning rules used in complex scripts like Indic and Arabic. Furthermore, the variation data is stored in a set of newly defined tables, leaving the basic table set untouched. That means that any program incapable of reading the variation data will still see a valid font—just one that has only the default glyph shapes and metrics.

The new format is designed to be compact, Constable said. In tests, a two-axis variations font that would be suitable to replace a family of ten traditional instance fonts took up just 30% of the size. Ultimately, the savings could be slightly better than that, he said, but the test font had not yet implemented hinting. This means smaller file sizes for operating systems, embedding in documents, and delivering over the web.

Constable also noted that the new 1.8 specification was an example of cross-industry collaboration. Much of the groundwork now implemented in the OpenType variations font specification comes from ideas implemented in the 1990s in Apple's TrueType GX. In 2015, Microsoft noticed the increasing interest in variable font techniques (such as the responsive typography trend) and reached out to Apple to discuss the matter. Little did they know at that time that Google and Adobe were also discussing the idea but, within a few months, all of the players got together and began working in earnest on the revision.

One benefit of that approach is that the new revision supports all of the various flavors of OpenType, including the TrueType flavor preferred by Microsoft and the Compact Font Format (CFF) flavor initiated by Adobe. Just as importantly, the specification defines not just the data structures used in the files, but the algorithms used to interpret them. So how the values in a font instance are derived from the base font and the variations tables is precisely defined, meaning that there should be no ambiguity in how they are interpreted. This was an issue with TrueType GX, Constable noted: GX fonts could specify their own range of possible weight values, but how Apple chose to interpret that range was not specified. In the OpenType 1.8 implementation, by contrast, weights and the ranges on all other axes must first be normalized to the interval [-1,1] before any interpolation is done.

Axes and instances

Apple's Ned Holbrook spoke next, delving a bit further into the specifics. Each axis of variation in a particular variations font has to be declared with a default, minimum, and maximum value. The axes are specified in a table named fvar. Five axes are predefined in the specification: weight, width, slant, italics (as distinct from slant), and optical size. If more axes prove generally useful, they can be added to the predefined list. In the meantime, designers can create and name any axes they wish to—say, stroke contrast.

The font's basic glyph, metric, and layout numbers (in the existing tables, that is) correspond to the default setting. In font-interpolation terms, each variation design included in the font file is called a "master." For each master, the font will include a set of delta values relative to the default. So, for each glyph outline that changes, there will be the default outlines as in a regular font, which are defined by a set of Bézier curve points. Then, for each master, a separate table would include a set of (delta X, delta Y) values, each of which corresponds to the adjustments made to one of the Bézier curve points. In OpenType fonts that use TrueType curves, the name of this variations table is gvar; in CFF-based OpenType fonts, the table is named CFF2.

The generic case used in most examples is a font with two variation axes: weight and width. That provides a two-dimensional [-1,1] space through which the proportions of the font can be varied. The "regular" version of the font would typically be at the origin, [0,0], and the font would include a set of deltas for the four corners: [1,1], [1,-1], [-1,-1], and [-1,1]. Those corners correspond to "maximum weight, maximum width," "maximum weight, minimum width," and so on.

So there are, in essence, five versions of the font encoded into the file. But the real benefit of the format is that a new font instance can be generated by interpolating between the masters provided, enabling a new instance to be created at runtime based only on a (weight, width) tuple requested by the user or software.

Naturally, the existence of that many possible variations can present a challenge for fitting information into the traditional font menu—at least for non-graphic-design apps like word processors. The solution, Holbrook explained, is that variations font files can also include a set of "named instances" that include a traditional font name (e.g., Source Sans Extra Bold) and its associated tuples for the relevant variation axes. The system can choose to present only these options to the user, simplifying usage.

Looking a bit beyond the generic case, Holbrook explained that a font does not have to declare [0,0] to be its default instance (nor [0,0,0] for a three-axis font, and so on), nor does it have to set its masters at 1 and -1. If the designer chooses to make a font that only covers a small range of weights, for example, that is perfectly acceptable.

There is also a mechanism available to specify more complicated interpolation. By default, the interpolation between any two master designs is linear. But the font can include an optional avar table that specifies a scaling factor to use between specific masters. By including several such scaling regions, one can approximate non-linear interpolation if desired.

Metrics and details

Next, Google's Behdad Esfahbod discussed how interpolation between masters can affect things other than the glyph outlines. Essentially, any data in the font can be interpolated between masters. As is the case with the Bézier points that make up glyph outlines, changes relative to the default font instance are stored in new tables. Deltas to changes in font-wide metrics are stored in the MVAR table, changes to horizontal metrics in HVAR, vertical metrics in VVAR, and hinting in cvar.

Fonts may also need to vary positioning data, Esfahbod said, such as the attachment points used for diacritics or for glyphs in connected scripts. Glyph substitution rules can also change between masters; for example, in extra-bold weights the designer might wish to swap in a simplified version of a glyph (in comparison to the default) simply to prevent that glyph from turning into a difficult-to-read black blob. Unlike the other kinds of variation data discussed, these positioning and substitution changes are encoded in an existing table, GDEF, but in a new subtable called Item Variation Store.

Constable then spoke briefly about hinting. Hinting data, he said, consists mainly of rules that define relationships between different outline points (such as defining two points as belonging to the same stem) or between an outline point and a font metric (such as defining that a point belongs on the base line). Because those relationships do not usually change, interpolating the hinting between two masters is a relatively simple affair, affecting only some key values that are stored in the control value table (CVT). Hints for masters in a variations font can thus be generated almost automatically (although manual review remains a good idea); in the new revision, any such changes are encoded in the new cvar table.

Finally, Adobe's David Lemon spoke about the new CFF2 table, which encodes the glyph-variation deltas for CFF fonts. The original CFF table, he said, was created for PostScript Type 1 fonts, and was grafted into OpenType after the fact. Thus, while its name ("Compact Font Format") belies its original intent, the table format actually includes quite a few redundancies usually found elsewhere in an OpenType file.

20 years later, he said, CFF is only used in OpenType. So the changes in OpenType 1.8 presented Adobe with a chance to do a little "housecleaning" of the format. CFF2 drops the redundant fields, further compacts internal data representations, and makes other improvements—in addition to supporting variations fonts. Among the other notable changes is that the new table format deprecates the rather unloved CID encoding originally developed for Chinese, Japanese, and Korean fonts.

Adobe contributed a CFF2 parser and rasterizer to FreeType, and is on schedule to update its font-building tools to support the new format by the end of September.

There were several other changes made in the new revision of the OpenType specification—Constable mentioned, for example, the MERG table, which lets fonts indicate to the text renderer that certain composite glyphs (e.g., a letter with an attached diacritic) should be cached after they are rendered, not before as is the default. That will prevent rendering glitches seen when the base character exists in the renderer's cache but the diacritic does not. The format now also fully supports all of the chromatic font approaches proposed by various players in recent years.

But variations fonts are by far the biggest change; in fact, Constable called it the largest change to OpenType since the format's inception. Considerable work remains to be done before end users can reap all of the benefits of the new format, but there are plenty of places where improvements will be noticed. Smaller file sizes will benefit distributors and network services, fully adjustable fonts will benefit layout tools and publishers, and more flexibility in fonts will, hopefully, benefit end users.