Web fonts now (how we’re doing with that)

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

Read more

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

82 thoughts on “Web fonts now (how we’re doing with that)”

  1. Excellent article Jeffrey. I was wondering “where we stand on this” just the other day, thanks for the update!

  2. We’ve managed to make this placed called web a mess with just a few fonts. I just can’t imagine what will happen in 5,10,15 years when people will be able to use Comic Sans as their main font. Good god…

  3. I cannot believe that anybody seriously pushes EOT. It’s a (super-weak) DRM, and we all know how good DRM is at stopping piracy and helping legal users.

    Legal users will buy fonts, pirates will steal them. The only difference is that with EOT both groups will have to run yet another program.

  4. Thanks for this great aerial view of the web font landscape.

    What a shame there is so rarely one rope for us all to pull in the same direction. If it’s not Microformats vs. RDFas then it’s @font-face vs. EOT or licensing.

    I suppose life would be duller if everything was smooth and aligned — it’d be nice to try it once in a while though.

  5. Correction: Wolfram|Alpha uses images because the results are outputs from Mathematica. I can’t explain the backend workings for you, but the technology doesn’t exist yet for us to go straight to copyable plaintext (this is generated separately). We’re working on it though ;)

    Don’t worry, though, there are plenty of examples of big websites that DO still use images, sadly

  6. I think Firefox 3.5 will be the tipping point on this for me. Once I can serve most of my visitors between font-face and EOT, it will be a compelling technique to start using. I’m very excited at the prospect of using better fonts online, but I can’t justify elaborate hack-arounds for it in my everyday work quite yet. The day is coming fast though and I thank you for the state-of-things reminder. Here’s hoping IE gets on board (around the time it supports rounded corners).

  7. Pingback: QuirksMode Blogs
  8. Significant improvements to in-browser typography are appearing. Besides the HTML proposals and their gradual uptake in browsers, the New York Times Reader is the first big project to take advantage of what is already supported by 90% of browsers today:
    http://www.google.com/search?q=“new+york+times+reader”+typography
    http://labs.adobe.com/technologies/textlayout/

    The ground is changing… expectations out there for in-browser typography are getting higher.

    jd/adobe

  9. Remember to gzip your fonts, everyone. The browsers that support .ttf and .otf via @font-face also support Content-Encoding: gzip, so you can use it unconditionally without content negotiation.

  10. it fails if the user has a Flash block plug-in installed, as half of Firefox users seem to

    Jef, could you share the source on this information?

    Did we miss a meeting?

  11. I have started with flash text 10 years ago, then into image text for the headlines, now I will start with Cufon. With old IE browsers out there, intent of destroying my formatting, I don’t have a ton of faith that we’ll be using anything beyond the 7 web safe fonts for a long time. Thanks for the article.

  12. This is exactly why we created easyimg.com, to convert text to images so we can use uncommon fonts. Thanks for the article Jeff. I feel like it’s going to be a long struggle unless Microsoft shortens the gap in features between IE and the other browsers.

  13. Re Adobe supporting EOT over @font-face…. Seriously, who cares if Adobe supports it or not? Browser makers are the ones who make the ultimate decision and they are the ones driving the standard by actually implementing things.

    Safari already supports it and once @font-face is in FF, Chrome, Opera, it will be a de facto standard! All Adobe can do at that point is to ignore it and suffer the consequences of losing the sales of their products since they don’t support the new standard.

    If you want to see how that ends, go talk to Sony about MP3s, iPods and Walkman… heheheh.

  14. It’s great that most browsers will soon support @font-face or some sort of downloadable font. You provide a nice summary of the current status.

    The problem you touch on briefly is the apparent lack of fonts that can be used. Yet almost every TrueType and OpenType font that I’ve gotten with Windows or with Office is available to be embedded in other applications. At least that is what the license says on the Embedding tab of the font properties. (you may have to download the OpenType Font file Properties Extension to see this). I have about 150 fonts available to me for use on my web sites/pages.

    I may be incredibly naive about the extent of this license. I prefer to take the, admittedly brief, wording at face value.

  15. Pingback: Ectomachine
  16. Thanks for the summary Jeffrey.

    Just found the great Twitter Account @font who recognize every Tweet about @fonf-face. Take a look ;-).

  17. Pingback: DEREFER
  18. There’s a “nuclear option” available under the “@font-face” banner, that’s sleazy, but legal: Scan the letterforms of the font you want to use, then use FontForge or the like to recreate the font. Since this new font is your creation, you can license it for use on the web.

    Traditionally, the shape of the letters is not copyrightable, merely the “program” (the equations inside the font face) that creates them. It’s time consuming enough that you wouldn’t want to go through this process for every site you build, but you could support doing it for 3-5 fonts that you do most of your building with.

    Like all “nuclear options” this is not a course of action that should lightly be undertaken; the collateral damage would be severe. And I’m certainly not advocating we all jump on the wagon and start doing this. (It may be legal but it’s still sleazy.) But perhaps the threat of it could be used as a club to get the more rigid folks involved in the discussions to give a little.

  19. Fact is, we are not doing well with font-linking at all. Yes, there has been a higher volume of chatter the last couple of months, yes, some font-makers are modifying their EULA’s to acknowledge we are in the 21st Century (kudos to Ralph Herrmann), but the bottom line is that there are still only, at maximum, ten fonts fully suitable for body text at smaller font-sizes. (Anyone who thnks differently, hasn’t looked.) And the EULA’s for most of those fonts don’t permit direct linking to TTF or OTF files.
    When Chrome, FF, Safari, and Opera also support linking to an EOT or EOT-like file, then we will see some real change.
    Until then, we are just piddling around. Very disheartening.

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

  21. RE: blog.typekit.com
    An rather heady reaction there to such a small whiff of vapor. Caveat Emptor.
    There is a complete absence of technical details. Not a single demo page.
    When something seems too good to be true, well, we’ll see, won’t we.
    At the least, it’s a gauge of just how much interest there is in font-linking within the design community.
    Me, I’m from Missouri. (By way of Brooklyn.)

  22. I’ve worked with Cufon, and it’s a very nice cross-browser solution, at least for headers. The rendered text can’t be copy/pasted, but otherwise it works well everywhere I tested.

    Thanks for the link to Kilian Valkhof’s article on mixing Cufon and @font-face… will take a look.

  23. @ Rick wrote “Yet almost every TrueType and OpenType font that I’ve gotten with Windows or with Office is available to be embedded in other applications. At least that is what the license says on the Embedding tab of the font properties.” The font embedding permissions are for embedding fonts into electronic documents. This is NOT the same as posting fonts to web servers for use with @font-face. The license agreement for Windows XP or Vista and Microsoft Office does not allow you to redistribute the fonts. Yes, you can embed fonts into electronic documents such as Word or PDF files. But this does not extend to posting font files to web servers for use with @font-face. This is also true with most commercial fonts. That’s why EOT or some other web font standard is desired. I work for Ascender Corp, a small font company, and we support the efforts of Adobe, Microsoft, Monotype Imaging and others to come up with a solution that would allow commercial fonts to be licensed for web designers to use with @font-face. Numerous proposals are being discussed. We hope all this renewed interest will lead to a solution that meets the needs of web designers, developers and font designers.

Comments are closed.