EOT Archives

THE WEB Fonts Wiki has a page listing fonts you can legally embed in your site designs using the CSS standard @font-face method. Just as importantly, the wiki maintains a page showing commercial foundries that allow @font-face embedding. Between these two wiki pages, you may find just the font you need for your next design (even if you can’t currently license classics like Adobe Garamond or ITC Franklin and Clarendon).

The advantages of using fonts other than Times, Arial, Georgia, and Verdana have long been obvious to designers; it’s why web design in the 1990s was divided between pages done in Flash, and HTML pages containing pictures of fonts—a practice that still, bizarrely, continues even in occasionally otherwise advanced recent sites.

Using real fonts instead of pictures of fonts or outlines of fonts provides speed and accessibility advantages.

Currently the Webkit-based Apple Safari browser supports @font-face. The soon-to-be-released next versions of Opera Software’s Opera browser, Google’s Webkit-based Chrome, and Mozilla Firefox will do likewise. When I say “soon-to-be-released,” I mean any day now. When this occurs, all browsers except IE will support @font-face.

IE has, however, offered font embedding since IE4 via Embedded OpenType (.EOT), a font format that enables real fonts to be temporarily embedded in web pages. That is, the reader sees the font while reading the page, but cannot download (“steal”) the font afterwards. Microsoft has “grant[ed] to the W3C a perpetual, nonexclusive, royalty-free, world-wide right and license under any Microsoft copyrights on this contribution, to copy, publish and distribute the contribution under the W3C document licenses,” in hopes that EOT would thereby become a standard. But so far, only Microsoft’s own browsers support EOT.

Thus, as we consider integrating real fonts into our designs, we must navigate between browsers that support @font-face now (Safari), those that will do so soon (Opera, Chrome, Firefox), and the one that possibly never will (IE, with a dwindling but still overwhelming market share).

The person who figures out a designer-friendly solution to all this will either be hailed as a hero/heroine or get rich. Meanwhile, near-complete solutions of varying implementation difficulty exist. Read on:

CSS @ Ten: The Next Big Thing

“Instead of making pictures of fonts, the actual font files can be linked to and retrieved from the web. This way, designers can use TrueType fonts without having to freeze the text as background images.” An introduction to @font-face by Håkon Wium Lie, father of CSS.

Real Fonts on the Web: An Interview with The Font Bureau’s David Berlow

Is there life after Georgia? To understand issues surrounding web fonts from the type designer’s perspective, I interview David Berlow, co-founder of The Font Bureau, Inc, and the ?rst TrueType type designer.

The W3C: @font-face vs. EOT

A discussion that shows why the W3C may not be able to resolve this conflict. (It’s kind of like asking the Montagues and Capulets to decide whether the Montagues or the Capulets should rule Verona.)

sIFR 2.0: Rich Accessible Typography for the Masses

Mike Davidson’s scalable and accessible remix of Shaun Inman’s pioneering use of Flash and JavaScript to replace short passages of HTML text with Flash movies of the same text set in a real font. The Flash movies are created on the fly. If JavaScript or images are turned off, the user “sees” the HTML text; text set in sIFR can also be copied and pasted. sIFR was a great initial solution to the problem of real fonts on the web, but it’s only for short passages (which means the rest of the page must still be set in Georgia or Verdana), and it fails if the user has a Flash block plug-in installed, as half of Firefox users seem to. It’s also always a pain to implement. I don’t know any designer or developer who has an easy time setting up sIFR. In short, while sIFR is an awesome stop-gap, real fonts on the web are still what’s needed. Which also leads us to…

Cufón – Fonts for the People

Simo Kinnunen’s method of embedding fonts, regardless of whether or not a browser supports @font-face.

Combining Cufón And @Font-Face

Kilian Valkhof: “Everyone wants @font-face to work everywhere, but as it stands, it only works in Safari and the upcoming versions of Firefox and Opera. In this article I’ll show you how to use Cufón only if we can’t load the font through other, faster methods.”

Adobe, Web Fonts, and EOT

Why Adobe supports Microsoft’s EOT instead of @font-face.

Introducing Typekit

Update May 28, 2009: Working with Jason Santa Maria, Jeff Veen’s company Small Batch Inc. introduces Typekit:

We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
Web Fonts Now, for real: David Berlow of The Font Bureau has proposed a Permissions Table for OpenType that can be implemented immediately to turn raw fonts into web fonts without any wrappers or other nonsense. If adopted, it will enable type designers to license their work for web use, and web designers to create pages that use real fonts via the CSS @font-face standard. — 16 July 2009

[tags]fonts, webfonts, webdesign, embed, @font-face, EOT, wiki, css, layout, safari, opera, firefox, chrome, browsers[/tags]

A proposal for a fonts working group is under discussion at the W3C. The minutes of a small meeting held on Thursday 23 October include a condensed, corrected transcription of a discussion between Sampo Kaasila (Bitstream), Mike Champion (Microsoft), John Daggett (Mozilla), Håkon Wium Lie (Opera), Liam Quin (W3C), Bert Bos (W3C), Alex Mogilevsky (Microsoft), Josh Soref (Nokia), Vladimir Levantovsky (Monotype), Klaas Bals (Inventive Designers), and Richard Ishida (W3C).

The meeting started with a discussion of Microsoft’s EOT (Embedded OpenType) versus raw fonts. Bert Bos, style activity lead and co-creator of CSS, has beautifully summarized the relevant pros and cons discussed.

For those just catching up with the issue of real type on the web, here’s a bone-simple intro:

CSS provides a mechanism for embedding real fonts on your website, and some browsers support it, but its use probably violates your licensing agreement with the type foundry, and may also cause security problems on an end-user’s computer.
Microsoft’s EOT (based on the same standard CSS mechanism) works harder to avoid violating your licensing agreement, and has long worked in Internet Explorer, but is not supported in other browsers, is not foolproof vis-a-vis type foundry licensing rules, and may also cause PC security problems.

The proposed fonts working group hopes to navigate the technical and business problems of providing real fonts on the web, and in its first meeting came up with a potential compromise proposal before lunch.

Like everyone these days, the W3C is feeling a financial pinch, which means, if a real fonts working group is formed, its size and scope will necessarily be somewhat limited. That could be a good thing, since small groups work more efficiently than large groups. But a financial constraint on the number of invited experts could make for tough going where some details are concerned—and with typography, as with web technology, the details are everything.

I advise every web designer who cares about typography and web standards—that’s all of you, right?—to read the minutes of this remarkable first gathering, and to keep watching the skies.

[tags]web typography, typography, standards, webstandards, W3C, fonts, embedded, @fontface, EOT, workinggroup[/tags]

Read more