Google’s new Font API, Cufon, @font-face, sIFR, FLIR…?! It’s 2010 and the Internet has long since evolved to become an integral part of modern society. As web designers, our web fonts used to be limited to a small number of ‘safe’ font-families. Today there are a number of options that allow web developers to break free from the confines of the limited ‘web-safe’ font spectrum and express themselves, and their websites, more individually with unique fonts. Let’s examine how the web’s top font solutions work and how they are implemented.
Let’s start off by saying that the word(s) ‘web safe/websafe’ will hopefully one day become extinct. That being said, there are many issues surrounding web fonts such as font licensing issues, browser compatibility and so on. As well, it can be tricky to navigate the various solutions out there and to decide on the one that’s right for you. The aim of this article is to help you decide which solution is right and for you to be confident in that decision. Let’s dive right in to examine what the Internet has to offer web designers seeking an alternative to the normal CSS font-families.
Google Font API / Google Font Directory
We begin with Google’s Font API since it’s the newest and freshest web font solution out there. This latest freebie from Google is like a free version of TypeKit without the huge font selection. I heard that they worked together on the project… who would turn down working with Google on a project? Not TypeKit.
Implementing Google Fonts
To begin using the Google Font Directory all you have to do to use click here to go to Google Font Directory, click on font you like from the list and copy-and-paste the appropriate code like this:
For Lobster Font Family: Put this code in the this head of your website to get the font from Googleapis
As you can see this is catching the attention of many web designers out there, including me. I’ve already started to use this on my website and I imagine that we’ll be seeing this on a lot more WordPress blogs to begin with and eventually higher page-ranked sites.
Similar to Google Font Directory
Why You Should Use Google’s Font API
- Save the bandwidth on your site. Visitors won’t be downloading the font from your server.
- If the same font is used across multiple sites it will
- Google is fast, very fast
Why You Shouldn’t Use Google’s Font API
- There’s only around 20 fonts to choose from
Cufon is a font replacement solution that aims to be the alternative to sIFR. Their is no Flash or plug-in involved here, only natively supported features.
To use this solution select a font file that you’d like to use (.TTF, .OTF etc.) and head over to the Cufon Font Generator.
Now it’s time to replace the text you want using cufon. Copy-and-paste the following into the head of your document but replace the script source to point to the location you uploaded the files the font generator generated.
Cufon does have it’s use on the Internet, but it’s more of a niche than poised to overtake any of the upcoming font library solutions. It does allow you to use any font you wish as long as it’s in the common formats, but this also opens the door for lawsuits for businesses and organizations. Cufon is cool though, impress your friends and use it on one of your next projects.
Example of markup rendered using Cufon:
All this to only say “Browse by Category”? You’d definitely only want to use this for headings.
Why You Should Use Cufon
- Use and font you want (not sure how legal this is…)
- Supported by all major browsers
- Support an open source solution
Why You Shouldn’t Use Cufon
- The text is not selectable
- The font variations show up differently cross-browser
- It makes your markup looks all crazy with a bunch of spans and inline styles
- Not as simple to implement
- Cannot use for body text
@font-face is a CSS3 rule that allows you to host fonts on your server and have them rendered via your website if the site visitor does not already have that font installed on their computer. Currently, browser that support the rule are Safari, Firefox, and Google Chrome. IE kinda supports it. So what’s the problem? Font licenses… basically money. Many font artists don’t want to see their fonts used without bring them in some money, which is completely understandable.
Using @font-face is nearly as easy as using the Google Font Library except you have to host the font file on your web server. To use the web font you wish you will need to declare each font family using the @font-face CSS3 rule. For example, you would put the following in your stylesheet:
Then use the font-family via CSS on your chosen elements:
Why You Should Use @font-face
- Cutting-edge CSS
- Use any font you wish
- Easy to implement
- Selectable Text
Why You Shouldn’t Use @font-face
- Not fully cross-browser compliant
- Font licensing issues
sIFR is a is a web font solution that replaces your text elements with Flash equivalents. I’ve never implemented or had a need to use sIFR personally, but I have done work on a few websites that had this solution already in the works. I believe this solution will be used less frequently in the future since there seems to be a movement away from Flash. Despite this, the solution is still widely used; here’s brief overview of how to implement sIFR:
To begin, make sure you have Adobe Flash. You will need to modify the sifr.fla file and there’s no way to do this other than Flash. You can download a trial from Adobe if you don’t have it that is good for 30-days. Also, you should have the font files you wish to use as web fonts. Ok, have this all? Let’s look at a brief overview of what you will be doing:
- Download the latest sIFR files
- Set up the Flash file for the desired typeface
- Upload the necessary files
- replace the desired text with the ‘sIFR’ text
- styling the new text
Obviously this is a very brief overview. Here’s a good tutorial that will walk you through implementing sIFR that is more in depth than my brief rundown.
Why You Should Use sIFR
- Selectable Text
- Use any font you want
Why You Shouldn’t Use sIFR
- Flash elements throughout your site
- Font licensing issues
- Not as light-weight
- Not as easy to implement
- Need Flash to implement
To get FLIR up-and-running on your website you will have to do a bit of file configuration and the uploading files to your web server. Not too bad, but still not as snip snap as some of the previous solutions. Let’s look at the overview:
- Download the FLIR files
- Configure the config-flir.php file to define the fonts
- Add to the website by uploading the files and calling the path in you website header
- Style the tags via the special FLIR.replace(); CSS attribute
Why You Should Use FLIR
- Easier than sIFR to implement
- Use any font you wish
Why You Shouldn’t Use FLIR
- Non-selectable text
- ‘Unclean’ markup similar to Cufon
- Right-click reveals the text is an image