LWN.net Weekly Edition for September 22, 2016

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.

Comments (5 posted)

BubbleKern

At ATypI 2016 in Warsaw, Toshi Omagari presented an open-source tool he has developed to partially automate the repetitive task of generating kerning data for fonts. The program is called BubbleKern and, although it does not fully automate the kerning process, it may strike a balance that many font designers find useful.

Kerning traditionally referred to carving cutouts into the physical metal sorts for particular letters, Omagari said, which we would today refer to as negative sidebearings. It enabled letters with an overhang, like "f", which could otherwise not fit next to standard letters. The wood-type printing era used an approach more like what is done in digital type today, however. Many standard blocks would be cut down so that would fit together more closely. The visual gap between problematic pairs like "AW" is a common example; Omagari showed images of wood-type blocks cut down with carpentry tools to produce a better fit. That fine-tuning is akin to what designers do in digital type.

But, generally speaking, kerning today refers to any kind of conditional spacing. Type designers regularly do kerning for standard alphabetic fonts, while it is a far more complicated process for some specialty fonts like those for typesetting mathematics. Most font editors provide only a basic mechanism for kerning: there is a text preview window, and the user can enter adjustments to change the distance between a pair of letters, as many times as is necessary to achieve an appropriate result.

Periodically, someone makes an attempt to automate or otherwise improve the kerning process in a font editor. Omagari showed screenshots of the oldest such tool he has found: Calamus Type Art, a 1989 program for the Atari that, against all odds, is still available for purchase today; the most recent update being 1999's version 2.0.

Coincidentally, the kerning tool in Calamus Type Art uses some similar steps to BubbleKern's approach, although Omagari noted that he only learned about the other program after the fact.

BubbleKern is implemented as a set of scripts for the Glyphs font editor. Using it requires three steps. First, the user creates a drawing layer called "bubble" and, for each glyph of interest, draws a shape that encloses the glyph. These bubbles, he said, are meant to represent the necessary space each glyph requires. Unlike sidebearings, which are a single signed value, the bubbles can take the shape and slope of the glyph into consideration. Drawing the bubbles is a free-form operation; they can include as many straight lines or curves as necessary.

Second, before the kerning step itself, the user first selects all glyphs of interest—running the script against every glyph in a large font is generally regarded as a bad idea given the enormous number of permutations. Finally, the script then reduces each bubble to a series of horizontal, rectangular bands 20 points high. Since a standard OpenType font is designed on a 1000-point grid, there are thus 50 bands per glyph. The script then compares pairs of selected glyphs, moving them toward each other until there is a collision between the bands. The adjustment required to make the bubbles touch is then saved as a kern in the font source file.

The process is inevitably an iterative one, Omagari said; the user will want to edit the bubbles and re-run the kerning script. So BubbleKern provides a visual preview of the bubble layer. It is also possible to run the kerning step on a selected sample text rather than to generate all permutations for selected glyphs; that may also save time for some designers.

Several corner cases require special attention. Composite glyphs (such as accented characters) simply inherit the bubbles of their base glyphs (that is, the unaccented character). Glyph pairs that will not ever collide are a more problematic case. The period and quotation marks, for instance, probably require some kerning, but because they do not overlap at any horizontal band, would slide past each other. So BubbleKern's algorithm clamps the maximum possible kerning adjustment to be one half of the width of the narrower glyph in the pair. Omagari reports that this seems to be a sensible limit, and is hardcoded into the script.

But there are some unsolved problems as well, even ignoring the fact that sloppily created bubbles will generate poor results. First, if the user draws bubbles around the serifs on their glyphs, they may get unexpected results, because serifs usually extend almost all the way to the glyph's sidebearings. Thus, the user needs to clip bubbles at the sidebearings (even if that means the bubble is much thinner around the serifs than it is elsewhere). Another issue is that the script currently cannot make positive kerns, such as might be needed between W and a quotation mark or apostrophe. Finally, the script is limited to generate kerning values in the TrueType-style kern table format; users who want to produce kerning data in other formats (namely the GPOS table used by CFF-flavored OpenType fonts) will have to convert the results with another tool.

Omagari estimates that BubbleKern takes care of 70 to 90% of the kerning required when making a font. That is not a perfect solution by any means, but it also has side benefits. For example, it can catch glyph pairs that need kerning even when the designer did not notice them. And it could be extended to cover more situations, such as kerning trigraphs or kerning fonts in the Nastaliq writing style, where collisions can occur between glyphs that are several characters apart in the underlying string of text.

There have been other attempts to automate the kerning process prior to Omagari's. Charles M. Chen's command-line tool Autokern, for example, used related ideas. BubbleKern has one obvious advantage over a program like Autokern, however: it can be integrated into the popular font editor used by a rapidly growing number of working font designers, including integration with the on-canvas drawing tools. So far, BubbleKern is only available for Glyphs (which is proprietary and runs only on Mac OS X), but its Apache 2.0 license would certainly allow it to be ported to other tools and platforms.

Comments (3 posted)