Kimler Adventure Pages (http://randsco.com)

For years, web designers and bloggers have been limited to a select number of "web-safe" fonts. With the Jun 30th release of FireFox 3.5, it's now possible for cross-browser font embedding using the CSS3 @font-face selector. Here's a tutorial to show you how

@Font-Face: Typography can be art! Web designers have been limited to only 13 or so "web-safe" fonts for years. Now, cross-browser use of the CSS3 @font-face selector may change all that.

Expand Your Font Palette Using CSS3

In a tale involving proprietary font formats and a week-old release of FireFox, I'm here to say that using the CSS @font-face selector to spice up your website typography is an easy, light-weight, valid and cross-browser solution. Finally, fancy fonts for the masses!

Can this be true? You bet your sweet bippy! Read on.

History: The Web as a Typographic Wasteland

The Core Nine: List of "web-safe" fonts that are generally loaded on any operating system (PC, Mac, Linux, etc) Choosing among only 9 or so fonts severely limits web design.

For the past decade, web designers have been limited to a selection of about 13 or so "web-safe" fonts. Out of hundreds of thousands of available fonts, this is a tad limiting.

While it's theoretically possible to utilize any font you want for a web site, in order for it to display properly, each visitor must have that particular font loaded on their computer. Because of this requirement, web typography has been a wasteland, limited to only a short list of commonly available (web-safe) fonts.

There have been several attempts to circumvent this problem and below, is a list of some of the most common. All have their short-comings and for me - no disrespect to very creative, determined and knowledgeable people - they all fall into the category: "life shouldn't be so hard"!

• Image Replacement (typography as a graphic is seen by everyone - except search engines - and one has to play CSS games, to attempt to achieve both objectives).
• sIFR (sIFR means "Scalable Inman Flash Replacement", based on work done by Shaun Inman, et. al. A convoluted solution that relies on JavaScript and Flash technologies to replace web-safe text with a Flash image of the text, in your chosen typeface.)
• Cufón - a JavaScript image replacement technique that's a worthy alternative to sIFR. The name is derived from "CUstom FONts".
• FLIR - A server-side PHP script that dynamically generates images of text in the font-face of your choosing. PHP5 is recommended and requires GD library (with FreeType and PNG support enabled).

CSS3 @Font-Face Embedding to the Rescue

Spelling Counts: The @font-face CSS selector may rescue fancy fonts, but all the fonts in the world can't save bad content or typographic errors (i.e., fonts are the icing, don't lose sight of the basics).

Even though the ink is still drying on the official June 30th release of FireFox 3.5, which supports the @font-face CSS3 selector, there has been much buzz about how this will herald a new, creative web-font landscape. Truth is that Safari has supported @font-face for a while now and Opera 10+ is reportedly going to be supporting supports it as well.

In the Inspect Element Web Design & Development Blog, Tom Kenny writes, "Currently only Firefox 3.5 and Webkit browsers such as Safari and Google Chrome will render [the @font-face selector]. Of course, older browsers such as IE6 and IE7 will not support it and with IE8's distinct lack of CSS3 feature [sic], that doesn't support it either." (Source: "Go Beyond Web Safe Fonts with CSS3")

I know it's popular to bash Internet Explorer, but Tom (and others) need to check their facts before they publish false information!

Firstly, Microsoft has been supporting font-embedding for over a decade (since IE4 in 1997) and also the font-face tag and @font-face CSS selector. Secondly, the @font-face selector was a 1998 CSS2 recommendation (dropped in CSS2.1). It's made a comeback in CSS3 and hopefully will become a web standard.

Updated:4-Feb-2010 (Chrome 4 now supports @font-face by default) Secondly, Chrome doesn't support @font-face by default. (Apparently, Google supported it in an early beta release and then disabled it for subsequent releases, for "security reasons". To activate it, users must add a command-line switch --enable-remote-fonts .) (source)

Vast Majority: 97% of visitors to Randsco use browsers that can render the fancy fonts in this article (Internet Explorer, FireFox or Safari - July '09 stats).

The beauty, of course, is that it's now possible to embed fonts for IE6, IE7, IE8, FireFox 3.5+ (PC & Mac), Safari (PC & Mac) and (soon) Opera 10. According to our June 2009 web stats, that's over 97.5 percent of our visitors - about as "cross-browser" as you're going to get in today's online world! (Dunno about macIE or other browsers ... I'll have to rely on reader feedback.)

How @font-face Works: Easy Peasy

The great news about CSS3 support of the @font-face selector, is that - unlike work-a-round techniques - it's easy to use. Yay! Fonts without hoops!

Just upload the font file you want to use to your server - making sure that you're not violating any copyright rules - then embed it, using the following CSS:

Code:

The CSS code above defines a font called "yourFontName". You may use the actual font name - or - for testing purposes a unique, made-up name. Whichever you use, all you need to do is reference it again in the CSS, wherever you want to use it.

That's it! Note: the CSS3 specification provides for several font formats: "truetype" (ttf), "opentype" (ttf,otf), "truetype-aat (ttf), "embedded-opentype" (eot) and "scalable-vector-graphic" (svg,svgz).

C'mon, is it Really that Simple?

LOL ... of course not!

If there's one thing we've all learned about the Internet, nothing is really that simple and embedding fonts using the "new" CSS3 @font-face selector isn't any different.

"So, what's the issue?" you might ask.

Though Microsoft has been supporting font embedding since IE4 (1997), it's current support for @font-face is done a tad differently. Different enough, that it'll ignore a pure, valid CSS3 version. Internet Explorer supports only their proprietary "Embedded OpenType" font (eot) file format and it will incorrectly parses CSS that includes "format" values.

To achieve cross-browser compatibility, one must create some redundant CSS. The overhead isn't much and the gains, of course, are great. Using Microsoft's free WEFT tool (or this easy Online TTF->EOT Converter), one can create a Microsoft proprietary OpenType font file (having an EOT extension). Upload both the EOT and TTF files to your server. Using a single @font-face selector, load the Embedded OpenType font (EOT) for IE6, IE7 and IE8 first then the TrueType Font (TTF) for FireFox 3.5+, Safari (Win & Mac versions) & Opera v10+. BOOM ... you've just served the vast majority of your website visitors. In addition, the process degrades nicely. Browsers that can't load your special fonts won't miss a thing, as they'll be using the secondary, tertiary or generic fonts you specify. Additionally, the process is relatively future-proof. If Internet Explorer ever does support the CSS3 @font-face rules, then it'll simply utilize that bit of code already there. If not, you're covered there too.

An example of some final, CSS3-valid code might look like this, for a cross-browser compliant embedded font:

Code:

Though you can name use any font name, use the real one (capitalization matters) for the "local" declaration. This will give non-IE browsers an opportunity to look for the font on your visitor's computer. If it's loaded, it'll saves a TTF download. (Note: The local declaration is required, because it confuses Internet Explorer, which will fall back to the EOT file without trying to download the TTF).

Hints, Tips & Observations

I'm no font expert, just a web developer that's eager to utilize more than a limited number of fonts. When I realized that it would be possible to utilize embedded fonts for over 95% of our visitors, I spent a fair bit of time, playing around. Some of what I discovered along the way, contradicted what I've read elsewhere. Below is a brief list of this empirical knowledge, which I hope will help more people to use and understand this technique of font embedding.

1. Use TrueType Fonts - Even though the CSS3 @font-face selector provides for several font formats, WEFT will only convert TrueType fonts (Supposedly, WEFT will convert OpenType fonts as well, but the few that I tried didn't work, as they didn't show up in the selection list of "embeddable fonts").
2. Some TrueType fonts won't convert - Some fonts are designated as "non-convertible" by the designer, or there are other problems. WEFT shows a list of available fonts.
3. Converting OTF to EOT is More Work - Presently, it's a two-bank shot. First, convert the OTF file to TTF using FontForge or this free online font converter . Then you can use WEFT, FontForge, ttf2eot or TTF->EOT to convert the resulting TTF to an EOT.
4. Put IE First - In the CSS, it's important to put the IE EOT "src" first. It's also important that "src" is the only declaration. If you add "local" or "format", IE won't understand it and it will fail.
5. CSS3 doesn't do EOT - Despite reading that the "embedded-opentype" (EOT) is one of the formats allowed in the CSS3 @font-face selector, it either doesn't work, won't read the MicroSoft proprietary EOT flavor, or something else as I couldn't get FireFox to utilize the same EOT font file as Internet Explorer. (Pity, as it means loading the TrueType version, as well as the proprietary EOT version).
6. Understanding "Allowed Roots" - There are a few tricks to understanding WEFT. A big one: the EOT font file you create will only work for URL's you designate (i.e., "allowed roots"). If you own your own domain and want to be able to use the font file on any page, you'll need to specify both the "www" and "non-www" roots. (e.g., http://www.randsco.com and http://randsco.com).
7. Using WEFT Dont' use the WEFT wizard. WEFT wants to create a "font object" and subset it for any and all fonts it finds in webpages you specify. All you really need is the conversion part of WEFT. Here's an easy WEFT workflow:
   1. Load your TrueType font (i.e., drag it into the Windows font folder);
   2. Start WEFT (it'll create a database of "loaded fonts" on opening, so you'll need to rebuild the database if you load your font while WEFT is running);
   3. Pick the font(s) you want to convert (Tools > Fonts to Embed > Add... > Select a font on the list > repeat if you want to convert more);
   4. Close the window and then do the conversion (Tools > Create Font Objects > Set location of the font object and "allowed roots" > Finish);
   5. Upload your newly-created EOT font file to your server (I generally rename mine and make all the characters lowercase).
8. Testing can be tricky - In the @font-face CSS, if you use the actual font name for either the "font-family" declaration or the "local" declaration and that font is loaded on your computer, non-IE browsers IE Browsers IE browsers will never grab a local font. Once a "src" is specified, it'll download the EOT, every time. It doesn't matter if you specify the real name in the @font-face selector, or any other selector, for that matter. Click for the source of this information (based on IE4 behavior). It's the last question on the MSDN Frequently Asked Questions (at the bottom of the page).  will grab your locally-loaded font (i.e., doesn't test the font download). To make sure that the browser is downloading the font from your server correctly, you'll need to either (a) unload the font from your local computer or (b) rename the font in the CSS to something you know doesn't match any of your loaded fonts.
9.  src: local("font name"),
         local('fontName'),
         local("otherFontName"),
         local('some other font name'),
         url(../font/font.ttf) format('truetype'); Load Local - Once you determine your font download is working, rename the font in your CSS to its true name. Your visitor might have that font installed. You can use multiple local() declarations. If you know the font might have several names, use this to your advantage, like the example here (note syntax options). Non-IE browsers will look for the font in each location, stopping when it finds one or at the TTF download. (IE doesn't look locally in @font-face, so don't even try adding local() for the EOT line).
   
10. Problems? - Trouble-shooting deployment of @font-face can be discouraging. To test embedded fonts, one must make certain the font isn't installed locally and test in a variety of browsers. I've helped a lot of people with their @font-face fonts and below is a list of things to check:
    1. Syntax - Sounds simple, but make certain your syntax is 100% correct. Quotes around the local() filename, dash between @font and face. Nothing will work if the syntax isn't right. Validating your CSS (be sure to select the "CSS Level 3" profile) is the best way to check the syntax.
    2. Font Location - This trips up a lot of people. A location of "/font/yourFont.eot" generally isn't the same as "font/yourFont.eot". To keep things simple, I recommend creating a "fonts" folder right off the web-root and put all your fonts in there. Then, a location of "/fonts/font.eot" is short, sweet and will always work (bonus: is domain-independent). To test, you should be able to plug the URL "where the computer things your font is", into the address bar and result in a download of the font. If you get a 404 "File not found" - location is your problem.
    3. Corrupt File - I've seen corrupt files, either totally munged font files which are unusable or, more recently, fonts that work locally, but contain minor errors (typically fails in FireFox). (This is hard to test, but I've found that running fonts through Ethan's FontSquirrel generator will clean them.)
    4. Windoz Server? - Recently, David discovered that "in IIS v6 and later, you must add a MIME-type of application/octet-stream for both .OTF and .SVG in order for those types to be served properly on windows-based servers". (Thanks for sharing this, David!)

Conclusions

Because FireFox 3.5+ supports the CSS3 @font-face selector, cross-browser font embedding is now both possible and practical. The effect this will have on the web should be dramatic, replacing a decade-old typographic wasteland with a tastier and richer diversity of fonts.

While cross-browser deployment isn't ideal, the benefits of utilizing CSS to embed fonts is obvious: It's lightweight; it's valid CSS (CSS3); it's easy to do; it's search engine friendly; it's cross-browser compatible; and (yay) it relies neither on either JavaScript or Flash. The only downside is the slight overhead in downloading font file(s) and - depending on browser settings Defeating Font Embedding Internet Explorer In Internet Explorer 8, users may elect to disable font downloading or they may ask to be prompted, resulting in a message similar to the one below. (I believe, by default, this is set to "enable", so visitors would have to explicitly re-set the value and the majority won't). To reset in IE8: Tools > Internet Options > Security Tab > Custom Level > Downloads Section > Font Download (last one in the section). FireFox In FireFox, users can elect to replace all web fonts with fonts of their choosing. (This is defeated, by default and again, it would be up to users to explicitly re-set this value and the majority won't). To reset in FFx: Tools > Options > Content Tab > Fonts & Colors (Advanced Tab) > un-tick "Allow pages to choose their own fonts, instead of my selections above").   - may not render even for those browsers that support it. No worries! The technique degrades nicely to the normal "web-safe" or generic fonts you specify.

Now Go have some fun!