Untangling the tangle

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.

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

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

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.

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

In my opinion, EOT is as good as dead. [Cf. Tiffany’s comment below; and Thomas Phinney’s.]

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.

[Update (July 21): fontdeck joins the fray.]

_______________
Highlights from TypeCon 2009’s Web Font Embedding panel discussion, courtsy of @splorp and @typographica

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 — @splorp
Using 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 — @splorp
Dewitt: Foundries, if you don’t have a license that addresses the web, do it. Have a position that allows for some of these things. — @typographica
Bill Davis — “I think we’re on the cusp of something happening very quickly here …” That’s because web designers are frustrated. — @splorp
There’s a big ostentatious EOT Lite petition at the door. Presumably placed there by Bill Davis. Waiting to hear his invitation to sign it. — @typographica
John Hudson of Tiro Typeworks is explaining @typesupply’s .webfont format. “… super easy to implement … ” — @splorp
Mason: The W3C doesn’t lead, it follows. It takes steps once groups find consensus. — @typographica
Hudson explains the problem with a new format: IE is slooooow. IE users are slooooow to update. (Could take years for .webfont to be real.) — @typographica
Bill 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. — @splorp
Thomas 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. — @typographica
Verdana is still a pretty good typeface. — John Hudson — @splorp
Gabrowitsch (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. — @typographica
Relevant commentary from Tim Brown @nicewebtype: Type sellers, web fonts, and Typekit. link — @typographica
Typekit is willing and excited to incorporate .webfont proposal in their product. — @typographica
Final question from moderator: how urgent is it?
A. Garrick Van Buren (Kernest): We’re 10 years behind.— @typographica
Hudson: 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

_______________

Further reading:
@font-face in IE: Making Web Fonts Work
Web fonts now (how we’re doing with that)
Web font licensing: the basic idea
Type sellers, web fonts, and Typekit
List of foundries supporting .webfont
Typophile
@typegirl @splorp @typographica @nicewebtype
@font-face in action
Jeffrey Zeldman Questions The ‘EOT Lite’ Web Font Format
Audio from the Web Fonts Panel at TypeCon2009