Addressing brokenness in OpenType

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

At TypeCon 2014 in Washington, D.C., John Hudson presented a talk detailing the serious problems encountered when rendering text for many non-Latin languages—problems, he said, that stem from assumptions made in the OpenType font format, and that are overdue to be corrected. Although any file format has its limitations, Hudson said, he focused on what he called "problems of adjacency" that confront Indic and Arabic writing, and reveal a set of assumptions that were baked into the OpenType because of its roots in European alphabets.

The OpenType specification is an open, ISO standard for font files, first introduced in the mid 1990s, and built out of contributions from Adobe and Microsoft. The format it specifies for the actual shapes of glyphs themselves is derived from Adobe's PostScript-based Compact Font Format (CFF). But the specification includes much more than the outlines of characters; among other things, it also provides ways for font files to include rules for making context-sensitive substitutions of one glyph for another and for repositioning certain glyphs based on their adjacency to others.

Hudson started his talk by showing a video of Iraqi calligrapher Hajj Wafaa doing Arabic lettering with a broad-nib ink pen. Hudson pointed out that the adjacency issues he was discussing are inherent to the writing system, not to any technical implementation of it. Wafaa has to adjust for positioning and substitution rules as he works—the difference is that he can do so on the fly, based on accumulated experience. Software has to attempt to regularize and encode the required strategies, which is the difficult step. OpenType provides two basic means for adjusting how a sequence of character codes gets converted into text on screen: positioning rules, found in a font's GPOS table structure, and substitution rules, in the GSUB table.

Positioning

The positioning feature is most familiar to readers of Latin-based languages with regard to kerning awkward letter pairs (such as "AV") and placing diacritics. In the underlying string, a letter may be followed by the Unicode character for a diacritical mark; for example, "a" followed by "`". The text rendering engine encountering this sequence looks for a rule in the GPOS table, which tells it where to place the diacritic with respect to the letter—in this case, "à". Many languages support stacking multiple diacritics, so OpenType rules support this as well.

The approach breaks down almost entirely for several south Asian languages, however. Indic scripts simply do not fit into the assumptions made by OpenType; the individual letters in a word or syllable are positioned in two dimensions, often with respect to several surrounding letters. OpenType positioning essentially considers only the relationship between pairs of sequential character codes, because it was designed with kerning in mind. And kerning, he said, inherits its basic model from Gutenberg's metal type, where only horizontal movement was possible. Hudson then presented a real-world example.

Despite its unfamiliarity in the West, the Telugu language is the fifteenth most-common language in the world, with over 75 million native speakers. In the Telugu script, some of the basic building blocks of words are clusters made up of four letters of the form C M N V: an initial consonant, followed by two intermediary consonants, and ending with a vowel. The proper shaping of the character cluster is for the vowel V to be placed over the initial consonant C, and the two intermediary characters M and N to be placed below and to the right of C, respectively. Making matters still more complicated, the intermediary consonants M and N are also accompanied by "vowel killer" codes that are not printed at all, but alter the default shape of the glyphs.

This relationship cannot be expressed in OpenType without an arduous series of workarounds, Hudson explained, because GPOS rules can only be applied to adjacent characters. A common workaround, he said, is to designate the intermediary characters M and N in the font file as diacritic marks, which are defined as having zero width and can thus be ignored by the GPOS rule. This, of course, is a hack—the characters are not really diacritics at all. Moreover, because there is more than one of them in the middle of the cluster, there needs to be a separate rule defined to indicate how each should be positioned in relation to C.

With a little contemplation, the practical impossibilities of this approach become clear. Separate rules would be required for every possible combination of M and N medial characters in conjunction with every possible C consonant. Not only might the set of positioning rules overrun the size of the GPOS table, but performing the lookups while drawing text to the screen would impose a serious performance cost on the rendering engine. Not every possible letter sequence is a valid word, Hudson said, which limits the scope somewhat, but the increasing number of foreign loanwords makes the problem still larger, because they bring in sequences of letters that are not used in the original language. The sample word in his slides, he revealed, was actually the Telugu loanword for the English term "software."

GPOS rules can instruct the renderer to ignore diacritics, Hudson said, and they can even be written to ignore classes of related characters (such as variant forms of the same letter). But to properly support Telugu and similar writing systems, rules should be able to ignore arbitrary sets of characters defined within the font file. There is no technical reason why this cannot be done, he said; OpenType just needs to be amended to cope with the idea.

Substitution

The most familiar examples of glyph substitution in English are typographic ligatures, in which the sequence of character codes "f" "i" in a string are rendered with a distinct "fi" glyph rather than the "f" and "i" glyphs individually. This substitution is a common one in the GSUB OpenType table.

Cursive scripts, naturally, involve writing far more of these substitution rules. The Arabic language, notably, has four forms for each letter: isolated, initial, medial, and final. And, Hudson said, comparatively straightforward GSUB rules describe which is rendered for a given character code in context. But while such substitution rules generally suffice for the Arabic language, GSUB fails for several other languages that use the Arabic alphabet but operate with different rules.

Hudson showed two examples. First is the baṛi ye, which exists in the Arabic language as an alternate, stylistic variant of the letter ye, but is a separate letter in Urdu. It is much wider than the usual ye, and Urdu text typically relocates vowel markers and other characters above and below it in order to be more compact. In addition, it sweeps backward in relation to the standard flow of the text (baṛi means "turned"), so it affects letters that precede it in many strings. GSUB rules cannot express the changes needed at all, Hudson said.

His second example is the Bengali script, which routinely requires placing multiple markers above the top line of the text. While Hudson and others have managed to create GSUB rules that more or less produce readable Bengali text in OpenType, he said, they are difficult hacks that require outside scripts to process the text in each application. In practice, most Bengali speakers simply put up with collisions and misplaced characters in their daily computer use and documents.

Fixing GSUB's shortcomings is not as simple as extending GPOS's functionality, he said. The problem is that, ultimately, OpenType rules assume that characters fit into fixed rectangular bounding boxes, and this assumption limits the operations that can move those boxes around. There are alternate software solutions for rendering Arabic scripts, he noted, such as Decotype's Arabic Composition Engine (ACE); they throw out the box model entirely. The typographic community has already dealt with similar issues when addressing how to render mathematical equations, Hudson said; surely it can come up with similar solutions for non-Latin scripts.

There are certainly other issues with OpenType, Hudson said. For example, Chinese and Japanese font developers do not run into the adjacency issues he described, but they do regularly hit the 65,000-character limit of OpenType files.

There is currently no active plan to develop a new revision to OpenType, but there is growing interest. Indeed, improving support for non-Latin writing systems was a major (if unofficial) theme at this year's TypeCon. Hudson noted that the typographic community has been using prefabricated rectangles as its base component for the three centuries since Gutenberg. That attests to the benefits of the system, he admitted, but it increasingly means grafting solutions like kerning and ligatures from one script onto another, whether they are appropriate or not. 300 years from now, he asked, will we still be talking about these problems in the same terms?

Hopefully not, he concluded. Kerning and ligatures are specific technical solutions. When technologists ask "how do we implement kerning and ligatures for this script?" they are asking the wrong question, Hudson said. Instead, they need to ask how the writing system in question copes with its adjacency problems already, then work toward a solution—even if that means breaking backward compatibility with an established format like OpenType.