Jumping on the webfont bandwagon

Webfonts are literally changing the face of web design (no pun intended). Even just between the time I wrote my last post on @font-face and now, there have been numerous additions to best practices and available services for invoking new, creative typefaces in your web pages.  It’s dizzying getting started because there’s just so much out there and new methods of calling fonts are cropping up all the time.  In this article, I talk about what the web font formats are, where to get them and how to use them.

What the options are

TrueType/OpenType – I’m not going to go into the difference between TrueType and OpenType in this post.  The two things exist and they are more or less the same and are typically the most common font types.  The important thing about these formats is copyright; what’s linked when you use either OpenType or TrueType fonts in your stylesheet or code is the original, unmodified font (or a variation of it) which gets downloaded as an element of the web page (just like any other element of the page like graphics or Flash).  Therefore, if you’re using TTF or OTF fonts in your code you need to be sure that the font you are using has an open license that allows for public usage.  If you don’t, you are potentially violating the font creator’s copyright and could get in a lot of trouble.

EOT – The Embedded OpenType format was developed by Microsoft in 1997 with the release of Internet Explorer 4.  What makes EOTs geared for the web is that they can only be viewed in a web browser (and, being a proprietary format developed by Microsoft, only one web browser is able to support them, that being IE).  It shouldn’t be a surprise, then, to know that Internet Explorer only supports EOTs for web fonts (thus far).

WOFF – Web Open Font Format was developed by Jonathan Kew from Mozilla, Tal Leming from Type Supply and Erik van Blokland at LettError and was first supported by Mozilla Firefox.  Like EOTs, WOFF fonts are only viewable in a browser and have the added benefit of additional compression (capable of decreasing the size of the font by up to 40%) and is able to contain additional metadata, such as the font creator.  WOFF is a favored format by the W3C as the standardized web font format and is planned for support in Internet Explorer 9 and a forthcoming version of Google Chrome.

Cufón – Cufón was designed to be an alternative to sIFR.  While not a font, per se, it shares a lot of similarities with standard web font embedding and may also violate existing copyrights on proprietary typefaces.  Cufón is a javascript-based method that converts the font into VML (for Internet Explorer) or SVG (for everything else) to render the characters as vector graphics.  Like standard web font embedding, an external file is required (in this case a generated font file read by the javascript) which is downloaded as an element on the page.  One substantial benefit of Cufón is that the rendered fonts are often much smoother than can be achieved by embedding the actual font itself.

Where to get the fonts

You may be looking at the list of different font types and wondering how you convert your fonts into one of those than can be embedded into a page.  Don’t worry, it looks much harder than it is…

For standard TTF and OTF fonts, there are numerous places to download free fonts.  However, not all fonts that are “free” to use are actually “free” to embed on your website.  DaFont does a good job of distinguishing free, free for personal use and commercial, as does FontSquirrel.  There are also open font movements like the League of Movable Type and the Open Font Library which have repositories of free fonts that are safe to use on your site.

EOTs used to require an antiquated Microsoft-developed tool for converting fonts to EOT format, but the renewed interest in the format has led to the development of a couple of alternate methods.  For people comfortable working from a commandline, there’s TTF2EOT.  This simple Windows/*nix-based tool adds a simple commandline interface to convert a selected font to EOT.  For the less geeky, there’s EOTFast, however, as of this writing, it is still under development.

Similarly, WOFFs have a commandline tool called sfnt2woff which converts TTF or OTF font files to WOFF.

For Cufón, you pretty much have to use the web-based generator on Cufón’s home page.  While it gives almost complete control over the end result, the plethora of options can be a little overwhelming.

Luckily, the best and easiest place to get the fonts or have them converted is from the @font-face Generator at FontSquirrel.  FontSquirrel’s @font-face Generator comes in an Easy and Expert mode, so you can choose whether to let the generator pick the best options for you or to have more full control over the options.  Better still, it is able to generate TTF, OTF, EOT, WOFF as well as Cufón files, in addition to the actual CSS and markup needed to call the font (excluding Cufón which — presumably because it’s so much different from standard @font-face embeds in terms of how to integrate it into your site — you’re on your own for the code).  After you accept the agreement that the fonts you are using should be free to use, you just upload your source TTF or OTF and get a zip file containing everything you need to embed your font.

How to use them

If you used FontSquirrel’s Generator,  you can pretty much use what it spits out verbatim.  Even so, it helps to know what you’re doing and why, and there’s a few tricks that might help along the way…

First off, the code.  This is Paul Irish’s Bulletproof: Smiley variation of the @font-face declaration, and is edging to be the standard.  You can read his post about why it’s the best option.  For my part, I defer to the experts who have spent much more time than I have researching all the variables.  If you downloaded your kit from FontSquirrel, you’ll already be using the smiley declaration.

Simply replace the filename above with the path to the font and set the font-family name to what you’ll call it later.  It should be noted that Firefox has problems with paths that aren’t relative (e.g. full url paths) — this is a security precaution to prevent people from injecting malicious code into their site from off-site.  In most cases, this isn’t an issue, but it can pose a challenge if, for example, you were trying to use @font-face on a site with no local storage (like a BlogSpot blog) and were using some kind of off-site dump to host your files.

So that declares what that font is.  When you actually want to use it, you just add the family name to your font-family the way you would normally, so something like this:

You’ll also, of course, need to have uploaded the font to the server and make sure your source url points to the right place, but other than that, it’s pretty simple.  So what of these special considerations and tricks I mentioned?  Well, as usual, the first problem involves Internet Explorer.

If you’ve played with @font-face declarations at all, you may have noticed that your font looks great in Firefox, spectacular in Chrome and Safari, and like absolute crap in IE.  Ironically, this is because of ClearType — you know, that service that was introduced in WindowsXP that was designed to introduce font smoothing.  In IE7 and higher, ClearType is running within the browser, which in most cases is fine except when it comes to custom fonts.  In that case, it’s evidently trying to do a task that’s not required of it, and ends up hacking away at the edges which is what gives you the horrible jaggy appearance.  (This is one case in which, actually, IE6 is less broken then its successors.  Too bad it will be nigh impossible to find a machine that uses IE6 anymore.)  The fix, then, is to turn off ClearType, which, conveniently, you can do using Microsoft’s browser filters.  In the above h1, you would change it to look like this:

I won’t go into detail about the what’s and why’s of this.  It’s a hack (as per usual) that exploits the fact that IE’s filters don’t use ClearType functionality to prevent possible other problems.  You can read more about the hack and download the source files at AllCreatives.net (including the 1×1 px hIEfix.png required for this to work).

The second problem has been dubbed FOUT (Flash Of Unstyled Text).  In WebKit (Safari & Chrome), text that is styled in custom fonts doesn’t actually load until the font loads.  Other browsers, most notably Firefox and Opera, load the fallback or a default font first, then the custom font when it downloads.  This is FOUT, and can be jarring to the user.  There’s a couple of best practices here and then some ideas on how to fight the FOUT.

FOUT best practices:

• Keep your fonts small.  Just like images, the smaller the font file size is, the faster it will load, and the less time the browser will take downloading it.  Tools like FontSquirrel’s font generator can actually reduce the size of the font, and if WOFFs become standardized, that will help out as well since they’re compressed.
• Load your fonts first.  Most browsers work on a first come-first served basis for all elements, so putting your fonts right up at the top will help get them loaded first.  If you’ve got your font declarations in your normal css file, load that first.  If they are in a separate css file (which isn’t a bad idea), load that.  A rule of thumb is to load your font right underneath the according to a presentation given by the guys at Unmatched Style, it decreases the load time for the font.
• Subset fonts.  Fonts often come with hundreds of different characters, including special characters, which you may or may not be using.  Off the top of my head, I can think of several fonts that have the same characters for upper- or lower case letters.  If you don’t need the extra characters, you can just not include them in your font and this will make the font size smaller.  This is another thing you can do with the FontSquirrel generator.

If all else fails and you still need some help with the FOUT issue, there’s a couple of hacks you can try.  Like the “smiley” @font-face declaration, these come from Mr. Paul Irish who writes about fighting FOUT.

The first thing you can do is preload your fonts.  This is similar to the method of preloading images that display on a hover event where you use a display: none; or a visibility: hidden; or push it all the way off the screen somewhere in, like, left: -999em;.  Let’s say you’ve got two fonts you’re using on your site:

We’ll create some CSS styles to call those like this:

Now, in the actual body of the page, we’ll preload those fonts:

Personally, I think the .allfonts class is overkill if you’re calling both of them individually anyway, especially given that that’s targeting WebKit and WebKit isn’t our problem.  IE will download the fonts when they are declared, so this doesn’t affect IE at all.  Also, one thing you should be aware of if you decide to use this method is that it won’t validate, if that matters to you.

The other option is to target Firefox directly with this javascript which asks Firefox to act like WebKit, e.g. don’t load the text until the font has loaded.  For really slow-loading pages, there’s a 3-second fallback so people aren’t waiting forever for pages that take a really long time to load.  To do that, you will put this in your <head>:

This isn’t going to absolutely fix the problem either.  All of these are just ways to try to avoid the FOUT issue and none of them are foolproof, but they can help.

Alternate methods

There are some other methods for calling custom fonts.  One that I mentioned at the beginning is Cufón.  With Cufón, you must have, or link to, the source javascript, so the first part is to either their generator (or FontSquirrel’s generator).  When you have both files, you’ll call them in  your like this:

As you can probably guess, Cufón works by substituting its font in a given class (h1 in the above example).  If you want to use multiple fonts, you can do that with this:

It’s a little clumsy compared to @font-face and some of the other alternate methods, but if you’ve used sIFR (and by used, I mean embedded by hand, not just used a WordPress plugin), it’s probably pretty familiar.

Typekit has a bit of a roundabout method mostly to maintain control over commercial fonts and to make sure that only the font that was selected from the site and registered to you for use on the site you’ve registered with Typekit will display.  For the most part, though, it’s just two lines of javascript and a CSS class you set on the site; so, similar to what we’ve been doing already.  There are a few other companies, like Extensis with WebINK, that are jumping into the webfont market that handle it similarly.  In any case where you’re using a service, you’ll more than likely be using a javascript to contact the service and retrieve the font.

As of May 19, 2010, Google has launched their own webfont service and, for what it’s worth, it seems really promising so far.  They are using open and Creative Commons-licensed fonts and have an easy to use font directory (with only a handful of fonts right now — hopefully this will grow as time goes on).  When you find the font you want to use, you just need to click “Get the code” and voila there’s your source, which, in this case, is an externally hosted stylesheet like this:

Then you just need to call the font normally in your CSS.

The Google Webfont API also includes a webfont loader.  I haven’t played with this yet, but it appears to be similar to the preloader I mentioned earlier.  One interesting point to the webfont loader is that it’s written to allow fonts that are being loaded from other sources, not just Google.  It was co-written with Typekit, so of course Typekit can be called with the loader as well, like this:

Confused by all the options?  Here’s a comparison of FontSquirrel-generated fonts vs. Typekit vs. Google Webfonts.  This gives you a bit of an idea of how each font is rendered, and it’s all HTML/CSS so you can check this page in multiple browsers to compare browser compatibility.

And that’s pretty much it.  Before going, I should mention that FontSquirrel also has premade kits for a variety of different @font-face embeddable fonts, so it’s a good idea to see if the font you’re looking for already has a kit.  Also, some browsers don’t automatically bold or italicize some custom fonts so, like in print design, you need to declare the bold or italic variation separately.  There’s more discussion on that, if you’re interested, at the end of the Unmatched Style @font-face presentation.  Thanks for reading this far — I tried to make this as comprehensive a post as I could so if you know of any tips, tricks, hacks or other sources, let me know in the comments!

___________________

Chris Reynolds is one half of Arcane Palette. He has a personal blog, jazzsequence, where he writes about music, technology and social media and shares links, videos, and posts various personal music and writing projects.