Debating OpenType 2.0

The OpenType font format was designed to put an end to the "format wars" of the 1980s and 90s—a task at which it was largely successful. But the needs of users and software developers do not stand still, so there has been recent talk of revising the format in some major ways. Two session slots at the 2015 ATypI conference in São Paulo, Brazil were dedicated to discussing the idea. No consensus emerged as to whether small changes will suffice or a new revision of the format is warranted, but there is general agreement that OpenType needs updating to better address several specific situations.

The first OpenType-related discussion took place during an "open mic" slot, where a series of type designers and font engineers expressed their personal wish lists. The second was a moderated panel discussion, which dealt as much with the "how" of pushing the format forward as is did with the "what" of new features that could be added to OpenType.

The OpenType specification is, officially, maintained by the ISO MPEG group. In practice, though, updates and additions to the specification are managed in a rather informal manner: there is an open-membership mailing list, and proposed changes are discussed and agreed upon in a mostly ad-hoc fashion.

Font War III

For the benefit of those unfamiliar with the subject, Si Daniels of Microsoft and Vladimir Levantovsky of Monotype presented a history lesson on the creation of OpenType before the open-mic session began. The story is an entertaining one for those who are interested in how corporate rivalries can affect so-called "open standards" for better or worse. Without attempting to recount the entire tale, the salient points are that Microsoft, Apple, and Adobe repeatedly squared off against each other on font technology—much as they did on graphics, filesystems, data formats, and other potential product differentiators—but that eventually led to the market-wide solution.

Prior to OpenType, the font world was divided between Apple's TrueType and Adobe's PostScript Type 1. When a nascent collaboration between Apple and Microsoft on a successor to TrueType broke down in 1994, Microsoft paired up with Adobe instead and thus, essentially, merged the ideas from the TrueType and Type 1 camps into a single format. That format became OpenType, which was standardized in 1996 as ISO/IEC 14496-22. The standard essentially ended the TrueType/Type 1 rivalry by creating a superset of both older font formats.

It did take a while to catch on, in part because the Apple and Adobe type teams continued to release "pro" versions of fonts in the earlier formats, but virtually everyone else (including type foundries) moved to OpenType. Because an OpenType font can encapsulate the core data structures from either Type 1 or TrueType, adding support for the format to existing software was also relatively painless.

Unfortunately, as Daniels and Levantovsky then discussed, history can repeat itself. When web fonts were introduced in CSS2, the industry again found itself split: Apple backed the TrueDoc Portable Font Resource (PFR) format, while Microsoft backed the Embedded OpenType (EOT) format. It was not until ten years later that all of the major browser vendors collaborated to define the Web Open Font Format (WOFF), which has since taken off.

As a result of these experiences, few in the font-engineering world are keen to see competing revisions to OpenType appear. Gathering the stakeholders in one, neutral forum is a good step in the right direction.

Features for everyone

Seven people spoke during the open-mic session. Kamal Mansour from Monotype went first; his primary thesis was that OpenType's model of classifying glyphs is broken for many of the world's users—particularly those who use the Arabic script or many Indic writing systems. OpenType's shortcomings for these scripts is well-known (we covered, for instance, John Hudson's talk on the subject from TypeCon 2014), but Mansour provided a different illustration that does not require experience with Arabic or Indic writing. OpenType's classification rules, he said, cannot be used to typeset music—and the root of the problem can be traced back to one specific flaw.

The format requires that each glyph be either classified as either a base (such as a letter) or as a mark (such as a diacritic). But the specification explicitly says that marks must have zero width, which is not true in music notation nor in many writing systems. Just as music notation needs its flags and dots (which clearly add to the width of the base notes that they modify), Arabic and Indic scripts require flexibility in the horizontal direction, because they rely on modifiers that change the widths of letters. We have essentially tried to emulate these scripts in OpenType for years, he said; the real fix is to throw out the base-and-mark classification model.

Ned Holbrook from Apple made a different feature request. OpenType, he said, needs a mechanism to specify alternate glyphs to be used in specific typesetting situations. For example, capital letters with diacritics can often get tall enough to interfere with the line of text above (the Å of Swedish being a frequent offender). From a design standpoint, the best solution might be to substitute a slightly shorter A beneath the ring diacritic, but there is currently no way to specify this substitution in OpenType.

Google's Behdad Esfahbod proposed what was by far the longest list of new features. First, he suggested formally adding support for two Apple features—Apple Advanced Typography (AAT) and TrueType GX—and allowing fonts to mix and match those features with their existing OpenType equivalents. AAT is a "smart font" system that supports kerning, ligature substitution, "swash" variations, and so on. Most of its features have an equivalent in OpenType (an intentional move when OpenType was created), but Esfahbod contended that AAT tables should be allowed as-is in an OpenType font.

GX would be a more complicated addition; it allows fonts to specify text-shaping and arrangement rules using a state machine and a small command language (this is in contrast to OpenType's positioning rules, which, as Mansour and Hudson pointed out, are simplistic). GX also defines a mechanism for interpolating a font (e.g., to create a bold or condensed variant of the font on the fly), which Esfahbod would like to revive. The complexity of the GX shaping system could enable it to solve many of the Arabic and Indic-script shortcomings of OpenType (including the ones highlighted by Mansour), though adding support for the GX state machine to existing software could be quite an undertaking.

Esfahbod also suggested that OpenType fonts should be allowed to mix TrueType and Type 1 curves within the same file or even within the same glyph. TrueType curves are quadratic Béziers and Type 1 curves are cubic, but all modern font renderers can already handle both, he said. In addition, he suggested adding a new 2D-positioning layout engine to handle the Nastaliq writing style, making the free-software autohinter released by Adobe in 2013 into part of the OpenType specification, dropping infrequently used OpenType tables, and several other changes. He later posted the list online for public consumption.

Google's Raph Levien also took a turn at the podium, with a more limited list of suggestions. He argued that many of the space-saving techniques employed in WOFF ought to be applied to OpenType. For example, WOFF eliminates the bbox table, which takes up four bytes per glyph to specify each glyph's bounding box. That data is superfluous, since every bounding box can already be computed directly from the glyph's list of points. He also voiced his support for several of Esfahbod's proposals.

Of the other speakers, type designer Jean-Baptiste Levee suggested making fonts "rendering-environment aware," such as allowing them to change depending on the screen's pixel density, and allowing designers to define "kerning triplets" (or even greater tuples), rather than limiting kerning to pairs of letters only. Jan Middendorp and Levantovsky also weighed in—with cautionary notes rather than new-feature proposals. Middendorp noted that rendering engines and applications are far behind what the OpenType format supports already, so extending it further may be an uphill battle. Levantovsky added that several of the proposed changes would break backward compatibility, which the industry should not take lightly.

Table talk

In the panel session, Daniels, Levantovsky, Mansour, Holbrook, and Esfahbod were joined on stage by Adobe's David Lemon, FontLab's Thomas Phinney, and by Dave Crossland, who acted as moderator. The panel debated a number of topics, some from the open-mic session's suggestions and some prompted by Crossland.

Several security issues were raised. First, OpenType currently supports a digital-signature (DSIG) table that can supposedly be used to verify the integrity of a font file—a feature added to the standard by Microsoft—but, as Daniels pointed out, no software supports verifying the signature. While there is some concern that fonts could embed malware, Levantovsky argued that a signature-based approach cannot work for general web-delivered fonts, where the files in question are, by necessity, stripped down on the fly so that they only contain the subset of glyphs needed in the document. The consensus seemed to be that dropping DSIG would be a reasonable move.

Second, several panelists and audience members advocated making certain environment variables visible to font renderers—such as line length and leading. That would allow fonts to embed features that respond to those settings (such as the alternate-height capitals proposed by Holbrook). The concern is that exposing such local system information to a font retrieved from an arbitrary web server could leak information to the server or even enable the server to deliver a malicious payload. Phinney noted that there have been several real-world cases of malware delivered in font files, and the industry has "just agreed not to talk about" them and fix the bugs quietly.

On the feature front, the kerning of glyph triplets (or other tuples) was discussed; Mansour pointed out that multi-glyph kerning is supported in OpenType for several non-Latin scripts, but is rarely supported in application software or font-authoring tools. Phinney raised the issue of OpenType's 65,534-glyph limit, which can already be a limitation for Chinese fonts. Lemon replied that Adobe developed a workaround using the Composite Font Representation in 2012 (which was then published as ISO/IEC 14496-28:2012), but agreed that the glyph limit should be fixed.

A question from the audience raised the problem of localized forms, which are glyph variations that should be automatically substituted based on the system locale setting. They typically work for alphabetic characters, but support is inconsistent for numerals, punctuation, and other symbols. Daniels noted that Microsoft Office has a "known bug" about the issue, while Levien added that Android respects localized forms for non-alphabetic characters. Holbrook and Mansour agreed that the OpenType specification is silent about non-alphabetic localized forms, but Mansour said it is not clear if fixing OpenType will address the issue. The OS, the application, and the document may all have different locale settings; who wins that battle is hard to predict.

There was broad agreement on a few questions, such as the difficulty of persuading application and OS developers to implement support for new OpenType features. But the open question seems to be whether or not the "evangelism problem" ought to limit the development of new features. Esfahbod said that feature adoption only requires one browser these days; once one browser supports a feature, users will begin to demand it from their other applications. Phinney disagreed, though. "This is minor stuff to most people," he said, "it isn't 'breakage.'" Not getting the wider variant of some glyph might elicit an "I'm sorry," he added, but it will not be treated as a bug.

Similarly, the panelists generally agreed that hinting "needs to die" and that it is no longer a problem that font formats need to address. Between increases in screen and printer resolution and advances in auto-hinting, embedding explicit hinting information in fonts seems to no longer be worth the trouble. But several panelists felt that it would be too optimistic to eliminate support for hinting in the OpenType format. Mansour observed that he was saying hinting needed to die 20 years ago, too, and yet it is still with us.

As to the ultimate question of the hour—whether or not it was time to form a committee or working group and produce a major revision of OpenType—opinion seemed divided. Many of the panelists felt that the informal discussions currently going on in the community constituted the best approach. There were no such cross-company discussions during the TrueType/Type 1 war, as Lemon and Levantovsky pointed out. But Mansour said that OpenType implementers have had enough time to experiment, and that it is time to gather up all of the knowledge gained and apply it to the format. Esfahbod advocated taking an incremental approach, adding a few new features at a time and dropping older ones, rather than revising the format all at once.

The risk, as Crossland reminded the room, is that an informal approach to adding new features can leave users with multiple competing variants of what is nominally a single standard. That has already happened with chromatic fonts, he said: Apple, Microsoft, Google, and the W3C each created a proposed standard, and software developers are expected to implement them all. He also reminded everyone that the past year has seen a resurgence of interest in optical sizing, with new and incompatible solutions released in Apple's San Francisco font family and Microsoft's Sitka.

As of now, there does not seem to be sufficient interest in undertaking a major rewrite of the specification, but it looks like there are more interested parties than ever with something they would like to change. Most people in the text-and-font industry agree that OpenType has been an unrivaled success, but perhaps the work of a common, open standard may never truly be finished.

Index entries for this article
Conference	ATypI/2015

---

to post comments