Web font services join fray as .webfont format gains support

At least two other services will join TypeKit in attempting to provide @font- …

Improvements to CSS3, in particular a revival of the @font-face directive for linking to server-based fonts, promise to allow designers to deliver richer and more nuanced typography on the Web. And while Firefox and Safari (via WebKit) are leading the way by supporting standard TrueType and OpenType font files, posting commercial fonts on a publicly available Web server violates the licensing agreements from most type foundries. So, at least three services are close to launching, giving Web designers and developers access to licensed typefaces that will work with @font-face. And even while several foundries are looking to license their fonts for these services, several prominent foundries have expressed support for the .webfont format that is being proposed to the W3C.

Why bother?

What's with all the hubbub about Web fonts anyway? Microsoft licensed a number of fonts years ago, which became the de facto "Web fonts," and the Web has survived just fine with those 10 choices. And let's be honest, something like 98.7 percent (an unscientific estimate) of text on the Web is set in just one of four typefaces: Times, Arial, Verdana, and Georgia.

"The answer is contained in two words," designer Richard Rutter told Ars. "Design and accessibility."

While the commonly used typefaces are well designed, especially for display on most current low-resolution monitors, they don't offer the same wealth of character and differentiation available to print designers. Differentiation is especially important to corporations, for example, which often use custom designed or modified typefaces for corporate identity purposes. "At its simplest, access to a wider range fonts is about making websites look more individual," explained Rutter. "At a more esoteric level it's about choosing faces whose individual spirit and character is in keeping with the text."

Beyond such aesthetic considerations, however, are some practical concerns, especially for accessibility. While designers have developed workarounds that involve converting some or all text into graphics or Flash, such solutions are a compromise. Using real text means less data to download to display a page—not incredibly important if you have high-speed broadband at home, but it's still a concern for the burgeoning mobile Web. Real text also has the benefit of being resizable, translatable, indexable, can be read out loud using a screen reader, and can even be displayed with an alternative font if necessary. And non-Latin-based languages aren't well-served from the common Web fonts—having downloadable fonts "will be a boon" to those publishing in languages like Greek, Thai, or Chinese, said Rutter.

Today: TypeKit, Fontdeck, and Typotheque's web font service

So having fonts that can be downloaded and used by the browser has some important advantages, and there is already some technical support via the @font-face directive. But how can type foundries be coaxed into licensing their typefaces for use online, where rampant font piracy would be a mere click away? That's where services like TypeKit and Fontdeck come in. These services host licensed typefaces, and provide designers with custom CSS or JavaScript code that will work with a variety of browsers. And while TypeKit and Fontdeck are working with several foundries to hopefully serve as one-stop shops, independent foundry Typotheque has even built its own comparable service.

"[Our service] works with raw TTF fonts, but hides the URL where they are hosted, so they can't be copied," Typotheque's Peter Bilak told Ars. "Our system will take a copy of our retail font, will reduce the character set and remove all the font tables that browsers can't read, and provide the user with just a piece of code to embed on their site. The file size is then reduced to about 10 to 20 percent of the original size."

This is a preview of TypeKit's editor UI, which allows a Web designer to configure a subset of characters to use, weights and styles, and what CSS classes to associate with a font.

Both TypeKit and Fontdeck work in similar ways to Typotheque's own solution, even if they differ in technical details. The services license the fonts on a per-domain basis, so other websites can't simply copy source code and gain free access to fonts they haven't paid for. They allow custom subsetting of the font files, which can reduce the amount of font data that needs downloaded. Fontdeck, being developed by Rutter's Clearleft design firm, can serve different font formats depending on the browser—Internet Explorer supports @font-face, but only with Microsoft's custom EOT format. And the services have different ways of providing fallbacks if the browser doesn't support @font-face—TypeKit will even serve sIFR or Cuf�n if @font-face isn't supported.

There are criticisms of such systems, however. One is that the systems are run by third parties and must be relied upon for uptime. Another is that the pricing can cause issues—while not all details of pricing have been finalized, proposed subscription models and bandwidth usage fees can make costs harder to anticipate. And some people argue that these systems don't prevent font piracy—the main concern of font designers and distributors—it merely makes using type more difficult.

But, Rutter told Ars, folks rely on third-party services all the time—think Google Maps or Amazon S3—so designers and developers shouldn't be concerned about reliability. "Reliability is possible, and any failure of a font service is nowhere near as critical as failure of these other services—we just get a fallback to the current situation of viewing text with installed fonts," he said.

Pricing will vary among the services, no doubt, but having multiple services competing against each other should ideally result in pricing that the market is willing to bear. And as far as font piracy is concerned, foundries aren't interested in DRM, they just want to keep downloading fonts from being trivially easy. "Our intent is only to discourage casual misuse and to make it clear that taking fonts from Typekit is an explicit and intentional act," explained TypeKit's Jeffery Veen on the company's blog.

Tomorrow: a Web font format of our very own

So, while Web font services have some downsides, they work now (Typotheque gave us a sneak peek at its service) and should be publicly available soon. But there are proposals for a Web-specific font format, one of which may gain traction within the next few years. Microsoft recently submitted its proprietary EOT to the W3C a a proposed standard, but was roundly rejected. The awkwardly-named "EOT Lite" was proposed as a compromise, since it would be compatible with IE. However, as Richard Fink of Readable Web explained, EOT Lite as proposed is little more than a TTF file with a tweaked header and a different file name extension. And The Font Bureau's David Berlow has suggested adding a table of permissions to the standard OpenType format, which browsers could check to see if the font is licensed for use with a particular website. The makers of Firefox and Opera have stated in no uncertain terms that they will not implement license enforcement into their respective browsers, though, which could lead to inconsistent handling of licensed fonts.

The proposal that seems to be getting the most attention from foundries and the W3C is the .webfont format proposed by typographers Tal Leming and Erik van Blokland. The .webfont format is a zip-compressed bundle comprised of two files: info.xml, which contains metadata in XML format, and fontdata, which is the actual font data in whatever standard format is available—currently it's OpenType, but it could be anything. While the format doesn't offer the same level of obfuscation as services like TypeKit, the metadata is designed to carry licensing info along with the font, as well as a field that lists the URLs that a particular copy is licensed for. Such fonts would have at least a 40 percent file size savings thanks to the zip compression, but conversion tools from font vendors should allow for character set subsetting, which would afford even more file size reduction.

The list of foundries that have pledged support for the format includes House Industries, FontShop, Hoefler & Frere-Jones, and more—even Typotheque is behind the proposal. "It is not an ideal proposal, but a compromise," Bilak said, "though it still manages to address the concerns of many type foundries. In a way, for us it doesn't really matter, because we design and sell fonts rather than the technology behind it."

And it appears that browser vendors are willing to get on board with the format, especially if the W3C adopts the proposal as a standard. However, even if consensus could be reached on .webfont (or any other proposal), the specification would have to be hammered out in a working group in the W3C and finalized before browser vendors will support it. ".webfont is a solution for the future, say in two to four years," Bilak said. Others have speculated that the process may take five years or more.

As it stands, though, designers will have @font-face, combined with either freely-licensed "open" typefaces or licensed fonts available through services like TypeKit, to bring us a richer, more nuanced, yet still accessible online experience. Like all emerging standards, it will take some time for richer typography to spread into mainstream use. But we think when the results of these tools start appearing online, the change will be a welcome one.