Progress on smaller and more colorful fonts [LWN.net]
We're bad at marketingWe can admit it, marketing is not our strong suit. Our strength is writing the kind of articles that developers, administrators, and free-software supporters depend on to know what is going on in the Linux world. Please subscribe today to help us keep doing that, and so we don’t have to get good at marketing.
Concurrent with the central program of the 2013 ATypI conference in Amsterdam were various side meetings and workshops—not to mention the informal hallway discussions that are common to all technology conferences. In this case, the different side tracks resulted in some forward motion on some specifications that are likely to affect font development and software support for several years to come. The biggest is probably the Web Open Font Format version 2 (WOFF2), a proposed revision to the format used to deliver compressed font files over the web. WOFF 1.0 is still quite new, but Google is keen to update the format with support for a newly-released compression algorithm. At the same time, both of the two competing proposals for encoding color into fonts also moved forward, suggesting that the contest is far from over.
WOFF2
WOFF1 reached World Wide Web Consortium (W3C) "recommended" status in December 2012, but work was underway for a successor as early as March 2012. The format is intended to lossless-ly compress a font file for HTTP transmission. "Lossless" in this case means that the WOFF file retains the same glyphs as the input TrueType or OpenType font; the standard allows the WOFF creator to subset the characters included and remove unwanted tables (e.g., tables for character mappings, metrics, kerning, tracking, etc.). The file format is not simply a gzipped TTF, however: each data table in the font is compressed separately, so that applications only need to decompress the parts they need.
The first version of WOFF uses zlib's compress2() as the compression algorithm, which is a no-nonsense choice—after all, implementations are widely available and the algorithm is unencumbered with patents, which makes the W3C happy. But Google, purveyor of the largest web font–delivery service, was interested in improving on the compression in two respects: further reducing the size of the files and making decompression faster.
Reducing file size is an obvious improvement for any compression system, but the optimize-for-decompression model used for serving up the files might mean making different trade-offs than one would in a general-purpose algorithm. The font files only need to be compressed once, but need to be decompressed by every client—in browsers, the lag between loading page text and the application of the web font to that text is a common enough irritant that it has become known as FOUT ("flash of unstyled text"). Plus, optimizing decompression at the cost of more complex compression could help reduce the load on less powerful mobile devices.
Google's initial attempt to improve on WOFF1's compression used the LZMA entropy coder, but that algorithm proved aggravating on a number of fronts. First, its only documentation (much less specification) is sample code. Second, its lead developer was uninterested in working to incorporate LZMA into WOFF or other standards—a task that could involve time on his part for tasks like a rigorous security review. Third, although LZMA achieved smaller file sizes than zlib, it fell short on the goal of speeding up decompression.
The team at Google, led by Raph Levien and David Kuettel, reached out to other offices within the company and found a viable alternative. Jyrki Alakuijala and Zoltan Szabadka (who had previously worked on WebP compression) were already working on a variant of the Flate algorithm called Zopfli. They were able to further adapt their work into a new algorithm optimized for WOFF2. Called Brotli, the algorithm results in file sizes comparable to LZMA's (though a bit larger), but drastically faster decompression. Levien cited data rates of 120 to 300 MB/s decompression on the Google Fonts collection, compared to 20-30 MB/s for LZMA. The average file size is 29% smaller than WOFF1.
Google enabled the use of WOFF2 with Brotli as a runtime option for Chrome's "Canary" test builds in July 2013, and presumably has continued to tweak the algorithm based on what it has learned in that process. Keuttel has subsequently posted several updates to the W3C WebFonts Working Group mailing list, reporting the results of tests done on other font libraries. Most recently, on November 6, he noted additional improvements to the average decompression speed that came at the cost of altering the bit-stream format. That change had not yet been released in the open source code as of press time. Google also noted that the Brotli algorithm has not been optimized at all (in comparison to decades of optimization efforts for zlib), so hopefully with additional work there will be additional performance gains.
Improving the compression algorithm is the primary aim of WOFF2, but there are a few incidental improvements thrown in as well. Monotype's earlier MicroType Express (MTX) format proposal introduced some space-saving optimizations, too, like replacing composite glyphs (e.g., accented characters) with references to the original glyphs (e.g., the unaccented character and the accent mark), and transforming the tables in a font in order to take advantage of redundancy (for instance, WOFF1 required every glyph to have a bounding box, but in practice many glyphs' bounding boxes are identical and thus redundant). Google's Brotli-based WOFF2 reuses those ideas from MTX, and adds a few more, such as allowing some or all of the font file's tables to be compressed together, rather than requiring each table to be handled separately.
After the ATypI meeting, the WebFonts Working Group released its Evaluation Report for WOFF2, the first official publication in the publication-heavy process of W3C standardization. File compression fans will be happy to hear that Brotli is moving toward standardization, too; Google's Kenji Baheux posted a preliminary specification for Brotli to the mailing list after ATypI.
Outside of WOFF2 development, the WebFonts Working Group has looked at two other questions, but without resolution. The first was building support into WOFF for TrueType Collection (TTC) files. These are essentially bundles of multiple TTF fonts (such as a regular, bold, and italic) compacted together. Some people feel that delivering TTCs (instead of multiple TTFs compressed into multiple WOFFs) would further improve compression efficiency. The trouble is that in the real world, virtually no one publishes TTCs. Finally, Monotype's Vladimir Levantovsky resurrected a proposal to add "font" as a top-level MIME filetype with the IETF. Doing so might simplify the semantics of further standards work—right now, all fonts are registered underneath the "application" catch-all MIME type, like application/font-woff. As with TTC, however, what seems to be missing is motivation to push for the change. The reality is that what is in use today is good enough.
Colorful language
While TTC support and MIME-type registration languish, there is an abundance of interest in the area of standardization for chromatic fonts (i.e., fonts with color elements). As we discussed in August, there are two competing proposals from different players. Microsoft has been pushing for adding color index tables to the OpenType specification, which for historical reasons is managed by the MPEG body of the ISO. The W3C has a community group that is backing a different solution that adds SVG to OpenType instead. The W3C proposal was developed by Mozilla and Adobe.
Neither group has blinked yet. The W3C camp released its final proposal on October 9, notably with the additional backing of Monotype. On November 1, MPEG published its formal call for proposals for OpenType color support.
One might well ask whether or not the W3C group could simply submit its SVG-based proposal to MPEG. But the specifics of the MPEG call for proposals may make that difficult; among the listed requirements for submissions is "Low implementation complexity," which states that a proposal "shall not introduce significant burden on implementers and shall be easily implemented on various platforms including devices with limited capabilities and constrained memory / CPU resources". That language was certainly not invented to exclude SVG from consideration, but even die-hard SVG fans would probably agree that the format is rarely described as a "low implementation complexity" one.
The most probable outcome is that both proposals will be approved by their respective standards bodies; that is frequently what happens when standards-body proliferation goes unchecked. But the most important lesson may be that Microsoft has learned which standards bodies it can work with and which it cannot. WOFF actually began as an answer to Microsoft's Embedded OpenType (EOT) proposal, a compressed font format that explicitly supported DRM-like restrictions. But the EOT submission to the W3C never garnered outside support, and WOFF beat it handily. Years later when the chromatic font discussions began, it seems, Microsoft decided to skip the W3C and head straight for MPEG.
The W3C's process is not the fastest in the world, but it does have
the benefit of requiring consensus between disparate parties. As the
Encrypted Media Extensions (EME) debate has shown, the W3C process does
not always reflect the will of everyone who uses the web. But it is
more resilient against single-vendor solutions. Like a lot of
plumbing underneath the web, users may not notice WOFF2 at all (aside
from less-frequent FOUT annoyances), but they will notice chromatic
fonts. Hopefully the dueling proposals will get cleanly resolved
without years of frustrating incompatibility—but the more
officially-blessed standards there are, the less likely that could be.
| Index entries for this article | |
|---|---|
| Conference | ATypI/2013 |