Thanks to current lack of support for and other licensing issues regarding @font-face, we have to turn to other methods of using special fonts on our web pages. But what to choose? There are several great proven methods out there for font face replacements on a website, so today we’re going to take a look at 4 of the bigger ones that I have taken for a spin. I’m going to list for you the pros and cons that I discovered for each method.
Typeface.js
How it works:Typeface uses a browser’s vector drawing capabilities to draw text in HTML documents. It uses 2 javascript files - one that it gives you to download (typeface.js), and another which is generated from their website depending on the font that you upload. It’s a pretty simple concept; you download the typeface.js file, go to their website and click on the ‘fonts’ link to convert your font to a javascript file, and then you can easily reference both files in your HTML and change the fonts within your page just by specifying the font in CSS as if it was any normal font-family.
Pros:- Very easy setup
- Supports all of the necessary browsers
- Usage is limited due to fonts being embedded. There are not many fonts out there that are permitted to be used with this method
- Text is not selectable in most cases
Cúfon
Cúfon is the latest addition to this roundup, and it is also my new favorite. It uses the same technology and method as Typeface to draw the font (Canvas and VML), therefor it has an extremely similar Pro and Con list to typeface. The only difference is a slightly easier implementation. I first found out about Cúfon through Cameron Moll’s blog, which I would highly recommend checking out his post on Exploring Cufón, a sIFR alternative for font embedding where he discusses it and writes a quick tutorial on using it.
sIFR
sIFR requires both flash and javascript, and embeds fonts onto the page through a swf file. I believe this was the first of these technologies to emerge.
Pros:- Any font can be used, sIFR does not violate EULA’s.
- Degrades well (normal CSS will show up if user has flash or javascript off)
- Out of the 4, I would say that sIFR is by far the most complicated to set up
- Requires two browser enabled technologies instead of one.
- It loads slower than the others. There seems to be a visible delay no matter what
sIFR was great when it first appeared onto the scene, but the only reason I can see that you would want to use it over any others now is if you have a font that has an EULA preventing you from using one. Here are some nice sIFR resources that you can take advantage of:
How To Implement sIFR3 Into Your Website
sIFR Vault - lots of already created sIFR files for your using pleasure
jQuery sIFR plugin
FLIR
Face lift image replacement (FLIR) is different from the others in that it uses PHP to generate an image that replaces the text. So, as long as you are hosting your website on a Linux box, you should be all set!
Pros:- Somewhat easier to set up than sIFR
- EULA is not a problem here either
- Not as quick to set up as typeface or cúfon
- Does not always render a perfect image of the font, depending on which font face you use
- Requires PHP with GD library installed (not a problem for most of us)
How To Use Any Font You Wish With FLIR - a tutorial on setting up FLIR
Hopefully this post helped you come to a decision on how next you want to start using some snazzy fonts. Personally, I would not use these for anything BUT a header, due to load times and lack of CSS hovers. Correct me if I’m wrong, but I do not believe any of these can be used with a CSS hover. My recommendation would be to use FLIR and Cúfon when available. This was just a cursory glance into these 4 techniques, and I have not actually used any of them more than once or twice, so if I missed something or was incorrect anywhere, please post a comment.
Great Roundup!
Ive been holding out for either cufon or typeface.js to have support for selectable text, once that happens, I think we will have a winner.
I’ll keep this in mind for my next project. Thanks!
Can you explain why the JavaScript solutions would be effected by EULA restrictions and the other two are not? Is it the fact that the browser is doing the drawing rather than and “external” technology? Curious.
Sure thing Mas. I found this snippet from notesdesign.net that best explains it:
“The main concern from the perspective of the type foundry [edit: the guys who distribute the fonts and writes the licensing for them] appears to be that the typeface script generated by Cufón could be used to reverse engineer the very typeface itself. Further, because this script is a simple JavaScript file, it’s readily available to anyone for copying and downloading.”
The creators of Cufon, Typeface, and @font-face, are working with these companies to try and come to a better solution.
Good news, it looks like the embedding of OpenType font files has been approved via a new font license! http://tinyurl.com/nqobea
[...] Visit Source. [...]
[...] Font Face Replacement Embedding Techniques and Resources | Joren Rapini.com Weblog - Thanks to current lack of support for and other licensing issues regarding @font-face, we have to turn to other methods of using special fonts on our web pages. But what to choose? There are several great proven methods out there for font face replacements on a website… (More…) [...]
[...] Font Face Replacement Embedding Techniques and Resources [...]
[...] http://jorenrapini.com/blog/web-design/font-face-replacement-and-embedding-techniques-and-resources [...]
[...] when to use sIFR sIFR: la nuova tipografia per il web Font Face Replacement: aspettando @font-face Web Typography RoundUp: Typeface.js vs Cúfon vs sIFR vs FLIR jQuery plugin: font replace Revised Image Replacement Tipografia web: quali sono i limiti e quali [...]