Web fonts — where are we?

Web designers are generally not interested in technical specifications, TrueType Hinting instructions, and extended OpenType permissions tables. They have one pressing question: when can I use font x in my web pages? In Atlanta, Georgia, at TypeCon 2009, the faithful met to talk about Web Font Embedding: The New State of the Debate.

What web designers want

Web designers want more options, they want more fonts. sIFR, Cufón, and numerous other replacement techniques permit web designers to go beyond the so-called web-safe palette of fonts. However, all those techniques are, fundamentally, hacks. Moreover, their practical use is limited to headlines, or short bursts of text.

What type designers & foundries want

Foundries do not want their raw (.ttf and .otf) fonts uploaded to Web sites where they can easily be downloaded (stolen). @font-face permits linking directly to the raw font file. When I say raw, I mean an uncompressed, unprotected font file, just like you’d find in the font folder on your computer.

fonts

Downloading those font files would be as easy as downloading an image. For obvious reasons, foundries don’t want that. In fact, no-one wants that. Here, the music industry comparison doesn’t work. The type industry is in fact, not an industry; it’s not regulated by any kind of governing body, and the industry comprises thousands of small players — the vast majority of type foundries have a staff of one. Font piracy hurts them.

Solutions

Way back in 1997, Microsoft developed its proprietary EOT (Embedded OpenType Format — basically a compact version of OpenType, that permits sub-setting), that only supported Internet Explorer. Hoping for widespread adoption, Microsoft opened it up for all, and in 2007 submitted their EOT proposal to the W3C (for inclusion in CSS3). Later that year, the proposal was rejected, for, among other reasons, security. In 2008, the proposal was resubmitted:

The Embedded Font Format (EOT) was developed by Microsoft to enable OpenType fonts to be linked to web pages for download to render the web page with the font the author desired. This appendix specifies the format of the .EOT file so that User Agents can download, extract and temporarily install fonts of the .EOT file suffix that are included in the @font-face definition of a CSS style sheet. Example pages can be found at the Microsoft Typography site on Font Embedding for the Web.
Downloaded fonts are only temporarily installed on the user’s machines for use by the particular web page while the page is actively being used.
— source

EOT described as DRM icing on an OpenType cake. Once EOT was associated with DRM (and whether it’s strictly DRM is debatable), then EOT was doomed. For all the technical features of EOT, see the W3C’s Embedded OpenType (EOT) File Format. So what happened to EOT? To cut a very long and complicated story short: it didn’t gain the necessary support from foundries. Remember, the W3C is not mandated to push these formats through, to run around drumming up support. The consensus must come from the foundries, and from distributors.

.webfont

Recently, two highly respected type designers, Tal Leming & Erik van Blokland (they are programmers too) proposed an alternative to EOT. It’s not proprietary, and its implementation is relatively uncomplicated. Via twitter, H&FJ described the .webfont proposal as:

Smart, compact, open, elegant, forward-thinking, realistic. — source

Basically the .webfont font is a compressed file (perhaps .zip), comprising two files (the actual font data, plus info.xml). The embedded permissions or meta data are then read by supporting browsers, that could determine whether the font should be downloaded and displayed.

With such huge support from type foundries and many in the type community (even TypeKit supports it), the webfont proposal could well be a winner. So, we’ll all be using .webfont by this time next year, right? No. First, the W3C needs to be convinced that the majority of type vendors support the .webfont format. Then, and only then, will its slow wheels begin to turn. Then the browser vendors need to come aboard the .webfont ship, and build support for this new format into their respective browsers. Though the .webfont format is, in my opinion, the best proposed solution, don’t hold your breath. It will be years before we can start to link to .webfont files in our CSS.

If you’re not already confused, then let me introduce you to David Berlow’s (The Font Bureau) Permissions Table for OpenType proposal. (Technical specification here). Without getting too technical, I think Berlow’s proposal can be summed up thus: embed ‘meta data’ in the OpenType font file. These data will be information about the permissions for which the font is licensed. For example, the permissions table (not separate from the font file, but embedded) would include information about permitted use; e.g. whether it can be used on a web site — previewable for web.

The proposal does not require any change in font format; it only requires that more data (about permissions) be stored in the font file. Some have pointed out that its greatest strength — XML to describe the permissions — is also its greatest weakness. What’s to stop users from opening font files and editing the permissions? Another of its obvious strengths is that it does not require any kind of wrapper, and can be used with @font-face, which will soon be supported by most, if not all browsers.

In the meantime

While we’re waiting on .webfont et al., there’s Typekit, a simple solution that involves web-only font linking licenses. Basically, a font file, or a subset of the font is stored on a third-party server.

typekit-customise

You pay a subscription to Typekit to rent (not buy) the font. The rest is simple enough. Include a call to a JavaScript file (that handles delivery of the font, I guess), and simply include your ‘subscription font’ in your fontstack, like:

#introduction .one p { font-family:"skolar-1","skolar-2","Palatino","Georgia","Times","serif"; }

Great to see David Březina’s Skolar on screen. Go to for a beautiful web to see Typekit in action. Typekit is still in beta, but it looks very promising.

beautiful-web-detail

One of the most exciting aspects of the Typekit solution is best described by Thomas Phinney:

…the most interesting thing about Typekit & Kernest is they provide a service, a subscription, a brand new model for font licensing. — source

Final thoughts

We need consensus. They only way a consensus can be reached is through compromise. There exists no governing body of type, so there can be no democratic vote. The closest thing we have to consensus is the list of Foundries that support the present .webfont proposals.

Despite concerns about the security of the .webfont format, most of the larger and important foundries have come out in favour of the .webfont proposal; and that’s what really matters. See @typegirl’s Most of the important foundries are supporting #webfont list.

If no consensus is reached then .webfont will forever remain a proposal. If there is consensus, then still at the very soonest we’re looking at .webfont in our browsers by 2011-2012 at the earliest. @splorp sums it nicely in <140:

We just need to have one #webfont initiative to start solidifying. That’ll help. Right now, we’re tip-toeing around multiple jars of jelly.

Regardless of which format or proposal actually wins the fight, type designers are going to be very busy indeed. Most fonts are not optimised for on-screen viewing, so, if they are to compete with those that already are (e.g. Verdana), then they have lots of work ahead of them. (Type Designers have the joyous prospect of mastering TrueType hinting instructions).

Final, final thought

EOT may be dead, but Ascender Corporation is proposing EOT Lite — think of it as a less restrictive implementation of the original EOT. In what way is it less restrictive? Well, the new EOT Lite does away with URL binding (limiting use to a specific domain or URL), and proprietary compression technology (MTX compression) — the two principal objections to the original EOT specification. Ascender hopes to have it up and running within months. [added July 21, 2009].

Will .webfont ever come to our browsers? Who knows. But with the backing of the majority of influential type foundries, it could. In the meantime, TypeKit appears to be a viable, workable solution.