Starting in 1998 with Internet Explorer 4, and then from March 2008 through March of 2010, one by one, all of the “big five” desktop browsers—Safari, Firefox, Opera, and Chrome—have rolled out roughly comparable implementations of @font-face font linking. With these, an indispensable piece of the web publishing puzzle—a piece missing since the web began—has fallen into place, and a true web-specific typography can begin to take shape.
Article Continues Below
First, a roundup of recent events:
- A Web Fonts Working Group was chartered at the W3C on March 18, 2010. Its first order of business was to establish the WOFF specification as the standard compressed “wrapper” format for delivering sfnt (OTF and TTF) fonts on the web.
- Font rendering in IE9 using Windows’s DirectWrite has been unveiled via the see-for-yourself IE9 Platform Preview.
- The first round of web font preparation tools like Font Squirrel’s @Font-Face Generator and EOTFAST have appeared.
- A new wave of “font hosting and obfuscation” services (FHOS) have appeared alongside Typekit, Typotheque, and the free and open source Kernest.
- The first “trusting” web font licenses from commercial font designers have appeared.
- The CSS3 Fonts Module has evolved to include some of the advanced features of OpenType.
- Adobe Flash, once a reliable cross-platform means of text replacement (sIFR), now appears permanently crippled.
- Google has launched a free font-hosting service for a growing library of fonts. All of them available for self-hosting, too.
Let’s take them one at a time…
WOFF was formally submitted to the W3C Fonts Working Group on April, 8, 2010. Unexpectedly, Microsoft co-sponsored the submission along with Opera and Mozilla and support for WOFF is featured in developer preview builds of IE9. WOFF will be the standard “transport format” for fonts. It’s already in Firefox 3.6+, and the makers of Chrome have announced that it, too, will soon support WOFF.
Now, WOFF, unfortunately, has been hyped in ways that can mislead. So let’s stop a moment because it’s important to know what WOFF is and, just as importantly, what it isn’t.
Like its older cousin, EOT (Embedded Open Type) a WOFF file is, essentially, a zipped font file. It is not a font format in and of itself. It’s a font file that’s been packed up to travel. As PNG and JPEG are to image formats like BMP and TIFF, WOFF is to TTF and OTF. (Except that, unlike a compressed image, the original font can and must be extractable from the compressed file.) In practice, WOFF and EOT are very similar and the compression ratios are about the same.
WOFF is not a magic font format that will once and forever break down all the barriers that have stood in the way of licenses for commercial fonts. No, font producers’ fears about the web are much more complex than that—and we’ll examine them shortly in connection with FHOS.
IE9 and DirectWrite#section3
IE9 uses Windows’s DirectWrite rendering API. If you haven’t downloaded the IE9 preview I suggest you try to do so, it might cheer you up. If you spend any time at all with it, you won’t want to go back to IE8 and/or XP. (Mac users, no guffaws, please.) The font rendering in IE9 is worlds apart from what we’ve all come to expect. It’s certainly on a par with the Mac and in some ways arguably better. But whatever your personal opinion, at least the difference boils down largely to a matter of taste. One of the great side-effects of the focus on web fonts was the spotlight on just how wanting font rendering in browsers running on Windows had become in comparison to browsers on OS X. Note also that DirectWrite is a Windows API, not specific to IE, and other browsers like Firefox will be implementing it as well.
IE9 and @Font-Face the CSS3 Way#section4
What makes @font-face a viable cross-browser proposition now, today, is that—amazingly—IE has supported @font-face for over ten years. However, IE9 will be the first implementation of @font-face as described in CSS3.
The main changes are these:
Font Formats#section5
In addition to TrueType (TTF) fonts, IE9 will support PostScript-flavored OTF CFF fonts, as do the rest of the “big five” browsers. Now, removing this barrier to interopability is a good thing, but a word of caution is in order: If only in the interest of backward compatibility with IE 6–8, it will be some years before web fonts can stop being predominantly TrueType. IE 6–8 will only accept a TrueType font packaged as an EOT. And there are rendering issues to consider in other Windows browsers, as well.
Hopefully, font designers will help out by making their fonts available in TrueType with adequate TrueType hinting. Unless, as one type designer quite seriously suggested to me, everyone should just hold off on web fonts for however long it’s going to take for IE8 to fall off the map. Hah! Too late.
Syntax#section6
Within an @font-face “declaration” in CSS3, you, as a web author, get to do what the operating system does for you with the web-safe fonts. You get to group fonts into font-families by “declaring” them with the same font-family name. You get to differentiate members of that family by “declaring” each to be a differing combination of font-style (normal, italic) and font-weight (normal, bold).
Be aware that the terms font-weight and font-style have different meanings inside the @font-face declaration than they do outside the declaration in the main CSS rulesets. Inside the declaration, “font-weight:bold” means, “this is the bold member of this font-family;” outside the declaration “font-weight:bold” means, “apply bold to this text by using the member of this font-family that was declared as bold.”
In IE6–8 @font-face works the same way. However, in order for EOT files to work right, some of the naming and descriptive data within the TTF file from which the EOT is made needs to match up with the CSS declaration. Most of the time there’s no problem. But once in awhile certain fields inside the font’s data tables need modification. Should that happen, the issues are fully known and easy to fix. (The docs for EOTFAST have details.)
Tools for Web Fonts#section7
The essential tools web authors need have emerged:
The Font Squirrel Generator#section8
The Generator is a suite of online tools offering conversion, subsetting, CSS generation, and more. At the moment, it’s simply head and shoulders above anything else available on the web and, in the hands of font designer and web developer Ethan Dunham, it continues to evolve.
Also, you might want to familiarize yourself with some of the following free tools being used behind the curtain at places like Font Squirrel, Kernest, and Google:
- FontForge is a full-featured font editor with all sorts of scriptable server-side goodies. It’s also open source.
- sfnt2woff is a suite of open source tools for packing TTF and OTF CFF fonts into WOFF files.
- ttf2eot is a precursor to EOTFAST. It creates uncompressed EOT “lite” files.
- TTX is a tool to convert OpenType and TrueType fonts to and from XML.
- Fontue is an open source engine for serving fonts plus font-processing scripts, too. Contributions welcome on Github.
- WebFont Loader is a JavaScript library that gives you more control over font loading than the Google Font API provides. It was co-developed by Google and TypeKit.
EOTFAST#section9
Developed by myself and Philip Taylor of Cambridge UK, EOTFAST is a free, easy-to-use alternative to Microsoft’s nightmarish TTF-to-EOT conversion tool, WEFT. Use EOTFAST to create natively compressed EOT files for compatibility and quicker page load in IE 6–8. Note also that the EOT format has not been deprecated and will continue to work in all rendering modes of IE9, making it a handy way of targeting all versions of IE without resorting to conditional comments.
Trusting licenses—fonts at volume prices that provide both installable TTF or OTF files for ease of development as well as files for posting on web servers—are available from Font Spring. And the site provides—as every web font vending site must—an in-browser specimen sheet of the font so you can see what you’re really getting before you buy. Hopefully, other shops will adopt this simple licensing model.
Font Hosting And Obfuscation Services (FHOS)#section11
Until @font-face, browsers relied on the underlying operating system for fonts, so unlicensed use in web pages was never an issue. The OS acted as not only a technological, but a legal conduit as well. Rights to use the web safe fonts came with the operating system. But @font-face bypasses the OS and, instead, the fonts come from web servers. This presents commercial font producers with the prospect of great loss of control and a completely new set of legal realities. It also brings the prospect of a huge new market, but within the font industry it’s fair to say there has been less excitement about that than there has been wariness about the potential loss of control. The web market is an unknown, the print market is established. The conflict of new media versus old media is playing out once again, this time with fonts.
The concerns of commercial font producers go much deeper than the scenario of some visitor to a site seeing a font they like, digging into the CSS, and downloading it. Let me offer the following explanation so you can better understand why font services that employ obfuscation and, in some cases, rather long, obtuse, and grumbly licensing agreements, exist.
Font producers have seen what happened to the music, book, newspaper, magazine, and stock photo industries and they are afraid that the same thing is now about to happen to them. It’s been called the iTunes Effect, and it’s about price.
Font designers are very still very much focused on print. By and large, the money is in catering to professional customers in the printing industries: Books, magazines, displays, etc. Prices usually move on a sliding scale based on the number of users. The fear is that once fonts are on the web, they will become a commodity, the current model will break, and a devaluation of fonts, in general, will occur. The fear is that font designers will no longer be able to charge a print customer, say, $420 for a four style font family with a 6–10 user license in a world where fonts are being delivered on websites to virtually unlimited numbers of “users” who don’t have to pay anything at all. What if the web drives down prices in the print sector and doesn’t generate much revenue on it’s own?
Buyer Beware#section12
In response to this “Internet Threat,” some commercial font design houses have opted for font hosting and obfuscation services (FHOS). These services use, essentially, the Amazon Kindle model but instead of books you get what books are made with: Typefaces. Fonts are doled out in a measured and controlled way so the font creators know where each one is going and how it’s being used. The obfuscation focuses on preventing casual download and making the font uninstallable in the OS and therefore unavailable to print layout programs like InDesign. For these services, keeping the font file firmly in hand is the prime directive.
Growing out of discussions between representatives of font producers like Microsoft, Adobe, Monotype Imaging, and others in the wake of Typekit’s appearance last year, the past few months have brought FHOS offerings from Microsoft’s font distribution proxy, Ascender Corp, Extensis (specialists in font-management and licensing management software), Monotype Imaging, and a collective including David Berlow’s Font Bureau.
I can tell you that the folks at Extensis, Ascender, and Monotype are genuinely happy and enthusiastic about providing fonts for the web. But certainly they won’t be quick to point out that the delivery system for those fonts is crafted within the constraints of a clever but hacky DRM-like structure. This is understandable. But attempts to identify and prevent instances of unlicensed distribution through code have proved counter-productive for just about everybody and it’s hard not to view obfuscation as futile and irrelevant in the long term.
Font designer Ray Larabie said it best:
Protecting fonts from being installable in an OS will seem quaint and silly in a decade when using fonts for something other than the web will be a rarity. Install fonts on your OS? Whatever, grandpa! In the near future, nobody will even want to install a font on an OS.
Buyer Be Thankful#section13
But then again, there’s a flip side. You can view FHOS as a phase. Services are innovating. For example, the WebINK service from Extensis features a free installable “preview wizard” of sorts called Type Drawer that enables you, among other things, to instantly swap selected fonts on your page with drag and drop simplicity. This can be a huge time saver and it is certainly the kind of authoring tool designers need. Right now it’s proprietary to the WebINK service, but still it helps in shaping things to come.
A Checklist For Font Services#section14
Personally, my focus is on providing information for do-it-yourselfers. And as a web author, now that I don’t have to rely on the OS for fonts except for fallback, I’m uncomfortable with the idea of having an outside entity in control of something as basic and fundamental to the design of my site as a typeface. Further, every independent web designer I’ve spoken to about it has said they simply would not, under any circumstances, saddle a client with an ongoing expense for fonts. Thousands of free fonts are available, and many of them are of as high quality or higher than those offered by the services.
Certainly you should know, at the very least, what the technical differences are between what the service does and what you could do if you hosted the files yourself. Influenced by the checklist recently proposed by the EFF in connection with the explosion of digital books, here’s a kind of consumer checklist for those considering FHOS:
- Exactly what inefficiencies are being introduced in the effort to prevent visitors to your site from downloading and installing the font in the OS? And how many additional http requests are being made as a result?
- Has caching been disabled? Will users be subject to a Flash Of Unstyled Text (FOUT) with each session?
- If font file splitting is being utilized as an obfuscation technique, how might it effect things like spacing and kerning? And does the file splitting increase the likelihood of failure in some browsers?
- Is the service truly “standards compliant” in that it allows you to use the CSS3 standard in its full breadth and scope as it is currently implemented by those browsers that support @font-face?
- Is the End User License Agreement or Terms of Service understandable? As a business contract, are you comfortable obligating yourself or a client to its provisions? If you stop using the service and begin to host your own fonts, can the agreement conceivably compromise you in any way?
- What is the privacy policy? Is the activity on your site being monitored and logged and if so, how? And what is done with that information?
- Do the terms of the contract define the rights of visitors to your site? As your “users,” are visitors licensed to use the font not only for onscreen display, but for printing and the creation of PDFs, as well? Are visitors who attempt to download the font files individually exposed to any risks under the DMCA? (Let’s face it, we all deconstruct and examine parts of other people’s sites. That’s the web.)
- Once WOFF (and EOT) support is ubiquitous, is there a path to self-hosting or will you forever be locked in to the service?
Comments, please.
Advanced Features Of OpenType#section15
With Mozilla’s John Daggett taking the lead as author of the CSS3 Fonts Module, an impressive team of “invited” type design experts are doing the hard work of thinking through the problems of advanced typography at the W3C.
In the near term, this can have a big impact on the display of mathematical symbols and non-latin languages.
The Future Of Flash Text Replacement#section16
It’s been years now and Flash still isn’t allowed on the iPhone. It’s forbidden on the iPad. Steve Jobs’s recent pronouncement has gotten a lot of attention and it’s very hard to see Apple backing away from this decision. Plus, the iPhone and iPad both support a much simpler and elegant @font-face alternative to font rendering using the SVG format. For any developer contemplating a new project, it’s hard to see how sIFR makes any sense. @Font-face presents a lower learning curve and it doesn’t need to have a future, it is the future.
In a suprise development that grew out of informal talks with the folks at Typekit, Google has become a provider of openly licensed fonts via the Google Ajax API’s. It’s been set up as an open source project and you’ll find documentation, examples, and information on how to contribute at its GitHub repository. Unlike a lot of open source projects, this effort has a full time curator in Raph Levien. Interestingly, in spite of the fact that fonts are quite often the product of teams, some knowledgeable observers assert that fonts defy open source collaboration. Well, we’ll see.
All together now, let’s get really confused: for IE 6–8 you can only use TTF fonts wrapped up as EOT or EOT “Lite” (uncompressed). For Firefox, Opera, Chrome, and Safari, you can deliver TTF or OTF files either “raw” or, in some cases, wrapped up as WOFF files or as data URI’s inside a stylesheet. SVG will surely be a major font format going forward but its main virtue today is support in Mobile Safari for the iPhone and iPad. Got that?
Yes it is confusing. At first. Major changes always are. But I expect that web authors will do what web authors have always done: Find a way to make it work. The raw materials are there. The tools are there. The workarounds are there. So put together some sample pages and templates, and prepare for the crossing. The time has arrived.
