AS FAR back as 1998, CSS2 provided a way to link to real fonts from your style sheet:
@font-face {
font-family: "Watusi";
src: url("http://www.example.com/fonts/watusi.ttf")
format("truetype");
}
h1 {
font-family: "Watusi", sans-serif;
}
Instead of static pictures of fonts, linked font files can be retrieved from the web and used to display HTML text. And not just for headlines, but for body copy, too. It’s brilliant! It’s magnificent! There are just two problems:
- Unless they are specifically licensed for web use (and few fonts are), if you embed fonts you own on a web page, you may be violating your End User Licensing Agreement (EULA) with the font foundry.
- While Safari (and other Webkit browsers, including Google Chrome), Opera, and Firefox support
@font-facefor TrueType (TTF) and OpenType (OTF) fonts, guess which browser does not? That’s right, Internet Explorer. That’s not because IE is technically inferior to the other browsers. Rather, it’s because Microsoft does not wish to provide technology that might infringe on the rights of type designers. Instead, Microsoft supports@font-faceonly for the Embedded OpenType (EOT) format—which Microsoft itself invented. EOT discourages the copying of copyrighted font files via encryption, “subsetting” (using only needed characters rather than the entire font), and other techniques. Microsoft has supported EOT—and proposed it as a W3C standard—since IE4 was young. No other browser maker supports EOT.
The Tan method and IE
It’s the perennial web standards problem, but until Microsoft joins the party, Jon Tan offers a commendable workaround, combining standard @font-face with EOT served via IE conditional comments. It’s a hack, perhaps, but a clean one—and one that even Microsoft would approve. Nice work, Jon Tan. That’s one hurdle cleared.
The licensing hurdle
Type foundries are on the verge of agreeing to standards that will protect their rights and enable designers to embed real fonts on their web pages via standard CSS. They are on the verge, but not there yet. Competing proposals include Erik van Blokland and Tal Leming’s .webfont, a compressed format containing XML and font data; Ascender’s EOT Lite, which removes the chief objections to Microsoft’s EOT while still working in IE; and David Berlow’s OpenType Permissions and Recommendations Table, a mechanism for showing that the designer has paid for the right to use a particular font on a particular domain.
Using @font-face in all browsers today
Some of these methods work already. For instance, on Font Bureau’s website, you will soon be able to buy a web- and print-licensed version of one of their fonts for 20% more than a print-only-licensed version, and embed it on a given domain via @font-face. It will be legally licensed, and it will work in Safari, Firefox, and Opera. It will even work in IE, if you use Jon Tan’s workaround.
Rise of the middlemen
Until type designers agree to a standard and all browsers support @font-face embedding of TrueType and OpenType fonts, “middleman” platforms such as Typekit and Typotheque will make real web fonts possible by handling licensing and technological hassles.
As nearly all of you reading this know, here’s how it works: First, companies like Typekit get font vendors to sign on. The companies agree to license their fonts through Typekit. Designers pay a monthly fee to Typekit for arranging the license and hosting the fonts. Typekit also provides a technology solution, ensuring that the fonts show up in browsers that support standard font formats via @font-face (Safari, Firefox, Opera) as well as the one that does not (Internet Explorer).
Worth noting is that Typekit is font foundry agnostic, welcoming all, whereas Typotheque is a foundry-specific solution. The wizards at Clearleft have their own middleman platform in the works. All these solutions are currently in beta.
As of this writing, their pricing models are unknown—and price is sure to have an impact on acceptance.
Moreover, by definition, no web font middleman (or font developer, like Typotheque) offers every font you could wish for, and ultimately, designers will only choose a service that provides fonts they wish to use. Nor is it yet known whose technical solution will be best, whose font file will load fastest, how reliable each hosting platform will be as usage scales up, and so on.
The effect of font services on web standards
It remains to be seen whether a font-licensing standard and universal browser support for @font-face will kill the middlemen, or whether the middlemen will prove so successful that they delay or stifle the adoption of a font-licensing standard and allow Microsoft to shrug its shoulders indefinitely at supporting @font-face for anything beyond its proprietary EOT file format.
There is also the possibility that the middlemen, by increasing acceptance of web fonts, will hasten the arrival of a licensing standard—and that this will, in turn, prompt Microsoft to support @font-face for any licensed font.
ShortURL: zeldman.com/x/54
