With all the talk about web fonts, I think it’s time I tried to outline the present situation. I’ve not attempted to do so before, owing to the complexity of some of the material, and the speed at which things are moving.

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? Today, in Atlanta, Georgia, at TypeCon 2009, the faithful met to talk about Web Font Embedding: The New State of the Debate. At the foot of this article, I’ve included highlights from the twitter feeds of @typographica (Stephen Coles) and @splorp (Grant Hutchinson). Many thanks to them for the great job they did in reporting.

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. [see also Stephen’s comment below.]

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.

I once heard 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. [I was wrong; see Richard Fink’s comment, & Thomas Phinney’s comment.] 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.

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 dot 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.

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:

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.

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.

Multiple jars of jelly

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.

If no consensus is reached then .webfont will forever remain a proposal. If there is consensus, then perhaps 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 thoughts

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. And Typekit is now. I know I’ve omitted mention of other proposals like EOT Lite or Kernest from Ascender Corp., etc., but this article is intended as a non-technical, brief [laughs] overview. If you have questions or comments, then please leave them below.

Eleven font nerds and a microphone. @typographica is live tweeting from the huge #webfont panel discussion this morning. Audience unrest already. Only one web designer on a panel of 11. Via @nicewebtype — @splorpUsing a service like @typekit or @kernest is similar to buying/selling faces through distributors like @myfonts.… except that you’re not renting the typeface via a modified license. It’s not yours to use perpetually. — @splorp@opentype They don’t want fonts that users currently have to be used as web fonts. Should be a separate license and product. — @typographica“… the thinness of the wrapper is disturbing …” — John Hudson on the .webfont format. — @splorp“Any new font format we come up with … takes years to be implemented.” — Bill Davis, Ascender — @splorpDewitt: Foundries, if you don’t have a license that addresses the web, do it. Have a position that allows for some of these things. — @typographicaBill Davis — “I think we’re on the cusp of something happening very quickly here …” That’s because web designers are frustrated. — @splorpThere’s a big ostentatious EOT Lite petition at the door. Presumably placed there by Bill Davis. Waiting to hear his invitation to sign it. — @typographicaJohn Hudson of Tiro Typeworks is explaining @typesupply’s .webfont format. “… super easy to implement … ” — @splorpMason: The W3C doesn’t lead, it follows. It takes steps once groups find consensus. — @typographicaHudson explains the problem with a new format: IE is slooooow. IE users are slooooow to update. (Could take years for .webfont to be real.) — @typographicaBill Davis — “I think we’re on the cusp of something happening very quickly here …” That’s because web designers are frustrated. — @typographica@_Baylink I don’t think that’s the case. The foundries aren’t terrified, they’re cautious. None of these solutions will ‘eliminate’ misuse. — @splorpThomas Phinney: URL binding was a non-starter because vendors don’t want to enforce that. Worse, users might be open to DMCA liability. — [see Thomas Phinney’s comment for clarification.]Basic Q. What happens when any of these schemes don’t work? A. You’ll get the fallback font. Whatever specified in CSS, what you see today. — @typographicaVerdana is still a pretty good typeface. — John Hudson — @splorpGabrowitsch (F[ont]F[ont]): We support .webfont and “EOT Lite, Medium, or whatever”. As long as there’s no chance to use existing fonts on the web. — @typographicaRelevant commentary from Tim Brown @nicewebtype: Type sellers, web fonts, and Typekit. link — @typographicaTypekit is willing and excited to incorporate .webfont proposal in their product. — @typographicaFinal question from moderator: how urgent is it?A. Garrick Van Buren (Kernest): We’re 10 years behind.— @typographicaHudson: You can say yes to .webfont or EOT. It’s not an either or situation. But foundry weight behind one format will influence browsers.
End. Applause. Matthew Carter first to stand. Maybe wants out of here. — @typographica
Looks like everyone is walking out without batting an eye at the giant petition. Not sure the pen has been touched. — @typographica