Automating hinting for every script

At TypeCon 2016 in Seattle, Dave Crossland presented a look at the recent advancements in the free-software utility ttfautohint, which has rapidly grown from being a stop-gap measure with plenty of critics into a core part of many font-development workflows—including commercial foundries. The program automatically adds hinting information to fonts by analyzing the shapes of the included glyphs, alleviating the need to add hints manually. Challenges still remain for ttfautohint, though, including expanding the set of writing systems it can handle.

Crossland began with a disclaimer that, although he is known largely for his work with Google Fonts in recent years, ttfautohint is a distinct side project. That said, one of the early challenges faced when building the Google Fonts library was that font hinting is a notoriously complicated, labor-intensive process. The library was growing by more than a font every week in 2011, which provides considerably less time than a typical type foundry would have allotted for tasks like hinting.

So the team needed a different solution. Hinting is vital for reading text on screen, and particularly on Windows machines (which, unlike other platforms, never adopted a text-rendering model that would produce eye-pleasing results without relying on hinted fonts). The essence of hinting is the addition of embedded instructions to be read by the font renderer; instructions that keep similar letters the same size (in Latin alphabets, such alignment efforts keep lower-case letters aligned to the x-height, capitals to the capital height, and so on) and that keep glyph strokes aligned with pixel boundaries. PostScript fonts and their successors, Compact Font Format (CFF)-flavored OpenType fonts, rarely use any hinting because the PostScript rendering model takes care of such alignments internally. But TrueType fonts rely on hints that are embedded in the font and use a particular instruction set for the TrueType virtual machine.

But, many years ago, FreeType developer David Turner had developed a workaround for making those fonts without hints look good: he wrote an "autofit" module for FreeType that used many of the same concepts from the CFF renderer and applied them to TrueType fonts. It was developed, initially, because FreeType had been threatened over patent-infringement claims about the use of built-in TrueType hints. Autofit let FreeType make TrueType fonts look good on screen, essentially, through its own means.

The patents in question eventually expired, but the autofit workaround gave Crossland an idea: why not take the instructions generated and turn them into actual TrueType hints that could be merged into the font file? In 2011, he posed the question to then FreeType maintainer Werner Lemberg, who took the project on. In a few months there was a working prototype called ttfautohint.

Awkward fit

Although the "Inception-style" approach used by ttfautohint (using CFF rendering analysis of a font to inject TrueType rendering hints that will then be used by a TrueType renderer) seemed like it might be workable, Crossland said, there were some practical problems. First, hinting is usually done as an interactive process: the engineer adds hints, examines the rendered result immediately, then adjusts them. But ttfautohint was a command-line-only program with no interactive features. Second, hinting is ideally done during the design process, starting with a few core glyphs, then branching out as the font grows. But ttfautohint was a one-and-done program run only on a completed font file.

So the project set up a crowdfunding campaign to fund Lemberg's time, specifically to add a GUI and to further instrument ttfautohint with the controls needed to fine-tune the results. Other new features were targeted in the campaign, too, including hinting families of related fonts and supporting scripts other than Latin. In 2012, a few months after that campaign ended successfully, Google Fonts began using ttfautohint on fonts in its library.

But even then, the reaction from other font projects was not entirely enthusiastic. Göran Söderström famously criticized ttfautohint's output in a 2012 blog post [Wayback link], calling some of the results borderline unreadable and saying "I can’t really see the point of using ttfautohint at all." He also made a point of lamenting the fact that the hints generated by ttfautohint cannot be edited or adjusted; they are simply generated and inserted into the font file.

Work, however, continued. In 2012, Frederik Berlaen of RoboFont designed a Python-based GUI that would fit in with Apple's Mac OS X user-interface guidelines, although Crossland noted that the GUI's complexity has continued to grow and may have "gotten a little bit out of control." Other contributions began to come in from the developers of various font libraries and editors. In 2013, he noted, the project ran into a nasty bug encountered on certain laser printers, where rounding errors in the printer were causing wildly distorted results. The ttfautohint team released a fix.

Stability and extension

In 2014, ttfautohint version 1.0 was released. That version added support for a control file, which designers could use to tweak hints produced by the program—thus answering one of Söderström's criticisms. By the end of 2014, ttfautohint was in use at the commercial foundry ProductionType and was included with the proprietary Glyphs font editor.

In 2015, Lemberg began to look at how to support additional writing systems. He started by taking the Noto fonts by Google, which are open source and were extensively hand-hinted, stripping out all of the hinting, then working to reproduce the original results with ttfautohint.

There are now 22 scripts supported by ttfautohint. Crossland referred the audience to the online manual for a better description of how the hinting process works. In a nutshell, ttfautohint first analyzes each font file to automatically determine the width of vertical and horizontal strokes. It does this by examining characters that resemble the Latin letter "o" (there are similarly round characters in most, although not all, writing systems). Each glyph in the font is then examined to locate the stems and each stroke segment that can be adjusted as a single unit, using an approach described in a 2003 paper [PDF] by Turner and Lemberg.

Next, ttfautohint identifies what are called "blue zones" (after terminology used in PostScript), which roughly correspond to the vertical alignment areas of the script—in Latin, as mentioned above, those are the baseline, the x-height, the capital height, and so on. Naturally, each writing system has its own intrinsic set of these blue zones; ttfautohint looks at specific character codes in each script to assess where the blue zones of the font are.

Subsequently, ttfautohint will use this information to make sure that hinting adjustments do not push glyph components out of the zones, in theory keeping the entire font well-aligned. Sets of hints are generated to align edges to the blue zones, then to align components to pixel boundaries, then to align serifs. For now, all of ttfautohint's hinting is done only to change vertical alignments, because altering horizontal alignments usually has the unwanted side effect of changing the number of lines of text.

In practice, as one might expect, there is more to the process than this: there are many special cases, and matters get more complicated once composite glyphs (like accented characters) are added to the mix. Adding support for a new writing system, in most cases, begins with the question of identifying the key characters for ttfautohint to examine and the blue zones that are important to the writing system—followed by a great deal of testing.

Acceptance among designers has increased in recent years, too, Crossland said. In March, Ramiro Espinoza announced on the TypeDrawers discussion forum that he found ttfautohint's results to now be comparable to those from Microsoft's interactive hinting program Visual TrueType—and, in some cases, ttfautohint's to be better. Jasper de Waard discovered ttfautohint and used it to build a large font family called Proza Libre, a process he wrote about online.

Wide world of scripts

Looking forward, Crossland identified two areas where ttfautohint is needing to improve next. The first is it support for hinting font families. Although a family with a lot of weights will hopefully look harmonious when the weights are used together in a page, a bolder glyph is almost always taller than a lightweight version of the same glyph, because the strokes are thicker. Or, at least, that is what happens with lowercase glyphs; capitals tend to stay the same height for a given point size.

This presents a challenge to ttfautohint's analysis, which tries to align all of the glyphs to a single height. The approach currently being explored is to provide separate controls for uppercase and lowercase blue zones.

The other big issue is adding support for Chinese, Japanese and Korean (CJK) fonts, which do not follow the patterns used by the writing systems currently supported in ttfautohint. Thus, new algorithms will need to added. Crossland noted that there is some existing work in this area already, specifically Belleve Invis's sfdhanautohint.

There will, no doubt, be additional challenges in the years to come. But ttfautohint has already come a long way from its genesis as a workaround, so it may not be out of tricks just yet.