Cufon vs sIFR vs FLIR
Typography is a very important element to design, and it’s quite a shame that for the past decade we’ve resorted to using images to display this element, without having the flexibility to define different fonts outside of the 13 or so web safe fonts. In the past few years, however, we’ve seen a growing trend towards forcing new typefaces on the web. CSS defines a property for browsers to support a property called @font-face which lets the developer define new typefaces and include the original font file for the browser to download and render the site with. Support for this feature has been implemented in Safari already and is due to release with the next versions of Firefox and Opera. Though this is definitely good news and progress in the right direction, a few issues stand in the way:
- Copyright is an issue for downloading and sharing fonts via the font-face attribute
- Internet Explorer 6-8 do not support font-face
- Font-face could potentially pose a threat if malicious sites attach/spread viruses via the font files
Until font-face is fully adopted, web developers must resort to complimentary or supplementary solutions to make non-traditional typefaces work. There are few major flash and javascript solutions in existence that offer solutions with different approaches to displaying these typefaces. The three major typeface scripts that I am going to discuss are SIFR, FLIR, and Cufón. Before diving into details about each I’d like to point out that all of these solutions that I discuss are 100% SEO friendly, and all require JavaScript (and flash in the case of SIFR) but degrade to standard markup if JS is not enabled, also note that each of these play well with jQuery.
SIFR (Scalable Inman Flash Replacement)
First I must address the acronym, thought not the most relevant seeming, “Inman” is referring to Shaun Inman who originally conceived the idea of using the DOM and Flash together to support non-traditional typefaces. SIFR uses a flash object to render to the font face, and then Javascript to identify the DOM and replace the text as specified.
Pros of SIFR
- Text can be selected
- Does not violate EULA or copyrights, since font is contained within the SWF object
- You can easily add shadows, anti-aliasing, and other text effects in Flash
Cons of SIFR
- Slightly slower load times
- Requires both JavaScript and Flash to be enabled
My thoughts on SIFR
Some people complain that SIFR is harder to implement, but if you’re a front-end web developer it’s vital to learn and master new technologies including really basic flash. All you have to do is open the flash file included in the zip, change the font of the text to the font you want to use, and then publish it. Instructions are included on how to do this and if it is “too challenging” than you’re in the wrong field!
Many have also commented and argued that SIFR is no more secure to stealing a font file and using it on your website. While I do agree with that statement, the issue is a legal matter. Like it or not, and argue it as you may, Adobe Flash is legally allowed to embed and use fonts that the developer has purchased. This is not true for any of the others.
FLIR (Face Lift Image Replacement)
Using PHP (and the GD library) FLIR renders text into a font of your choice by reading the text in a DOM and sending a request to the server with that string and returning an image of that text rendered in the new font. It’s a very clever idea, and works behind the scenes, but it’s not without it’s quirks.
Pros of FLIR
- Does not violate EULA or copyrights, since font is rendered as an image
- Prints in the font rendered since it is an image
Cons of FLIR
- Requires PHP with the GD enabled
- Text cannot be selected
My thoughts on FLIR
While FLIR is fast and efficient with few flaws, one restriction I cannot overlook is the requirement for PHP and GD on the server. Many corporate websites (addressing the big guys, not the freelancers with this one) work exclusively with .NET on Windows/IIS servers without PHP installed at all. This eliminates FLIR from the mix for many websites unfortunately. In addition, FLIR disables the user to be able to select text. This is not a huge draw back if used on headings, but if used on a even body of text then you’re killing usability.
Cufon
Cufon is basically a new and improved version of Typeface.js, with a focus on faster and easier implementation. Cufon uses the browser to draw vector objects using VML (Vector Markup Language) for Internet Explorer and the HTML 5 Canvas element for the more advanced browsers.
Pros of Cufon
- Faster load times than SIFR and FLIR, since it is all JS and nothing more
- Has all the strengths of Typeface.js with fewer weaknesses.
Cons of Cufon
- Violates EULA and copyrights due to fonts being embedded. Not many fonts are permitted to be rendered with this method
- Text cannot be selected
- You can’t apply a hover state to converted text
My thoughts on Cufon
For many, Cufon is the best solution to work with. It allows for rendering on the fly, and works well for a developer to match a design without having to replace each heading with an image. Cufon even works quickly with large bodies of text! One thing I remain disappointed about is text selection; if this library aims to provide a solution for larger bodies of text, then it seems that text selection is a must.
As I have tested and worked with Cufon, I recommend it for the developer looking for a quick solution but only for personal or non-profit website. I’ve talked with a few professionals including a lawyer and confirmed that Cufon is not a legal solution for font-embedding on ANY website, but that unless you’re developing a large profile commercial site, you should be safe to use it freely.
If you’d like to learn more about Cufon, check out the tutorial on TutsPlus.
Read further:
Cufon vs sIFR vs FLIR
Style vs SEO
Fonts and the Law
[...] Cufon vs sIFR vs FLIR 09.04.2009 | Posted in Computer World Typography is a very important element to design, and it’s quite a shame that for the past decade we’ve resorted to using images to display this element, without having the flexibility to define different fonts outside of the 13 or so web safe fonts . In the past few years, however, we’ve seen a growing trend towards forcing new typefaces on the web. CSS defines a property for browsers to support a property called @font-face which lets the developer define new typefaces and include the origin Continued here: Cufon vs sIFR vs FLIR [...]
[...] [...]
Nice Article, I did a bit of a comparison between sIFR, Cufon and Typeface. Cufon worked pretty well for me but like you say the copyright violation is an issue. Typeface.js was a little stricter on this and wouldn’t let me embed the font unless I had the rights. Unfortunately Typeface didn’t like the kerning on my custom font.
[...] Cufon vs SIFR vs FLIR | Clayton McIlrath [...]
Thank you for this round-up. A small item though. In the eyes of foundries using sIFR does still violate many EULAs as many foundries do not allow for embedding in this way.
[...] tetap dapat di-highlight layaknya teks normal, serta tidak melanggar hak cipta seperti kata Clay McIlrath, karena metode SIFR menanamkan (embed) font ke dalam objek flash [...]
I really don’t see the legal difference between sIRF and Cufon. Using Cufon the font is not embedded, but only drawing instructions which is pretty much the same as the sIFR method.
Excepted for text selection Cufon seems reasonnably good.
Few thoughts of mine after reading the article:
1. The main disadvantage of SIFR IMO is that it’s flash. Sometimes it takes a while to adapt flash object / css so layout looks well. Some more sophisticated operations / solutions would be also almost impossible to implement using SIFR.
2. You are able to select FLIR’ed text, however only whole header. It is problematic if you replace using FLIR whole paragraph, but be honest, who would do that?
3. IMO the biggest advantage of SIFR is that one is able to manipulate the font from inside of .swf pretty well. Its easy to add shadows or apply custom antialiasing. However as long as you do not need those, FLIR is obvious winner for me. Unfortunately, I have never heard of Cufon, but I will have to try it soon.
[...] sIFR vs FLIR [...]
I’ve found it very difficult to control line heights with sifr.
Cufon *does* support selection in most browsers, but it suffers from an odd quirk: You can’t “see” the selection as highlighted. Try it though: select-copy-cut-paste works great in Firefox and reportedly in other browsers as well. Although it’s possible to fix this in the Javascript (“just” change the color of the background) it’s probably not worth the code bloat in most instances, so it should probably be optional if ever implemented.
This makes Cufon, in my mind, perhaps the best of the solutions out there.
The *real* problem, though, is the fundamental conflict between our need to use any face on any web page anywhere, and many foundries’ insistence that they get paid on bizarre usage terms. This is at heart a DRM battle, and technology and need will carry the day here, as they have with other media.
I’m really not sure why sIFR gets a free pass here on the “legality” issue – Like Cufon and others, it transforms a typeface, and then freely shares that transformed version as a sIFR font file that can be easily downloaded, and (in most cases) re-used elsewhere. (I confess to snagging others’ sIFR fonts to avoid the PITA of making them myself (I don’t own Flash). How could that be wrong if I already own a copy of that font?) How is this *legally* any different from Cufon? In other words, what gives Flash users special immunity w.r.t. font use – just Adobe’s clout and Flash marketing muscle? The real problem seems to be font licenses that are badly out of step with the realities of market need.
BTW, Any system that just transforms the original vector data would seem to fall into the same category. FLIR is fundamentally different because it flattens the vector (outline) text to a bitmap, but this approach has many drawbacks, including reliance on external servers for proper rendering (and performance), inability to dynamically scale locally, etc. Interestingly, in the case of Flash, the font info isn’t even transformed, it’s just put into a magic Flash wrapper. This whole situation is crazy….
@Sabre: I totally forgot to mention the drop shadows and anti-aliasing advantages of sIFR, those are some of the main reasons why I prefer sIFR, I will have to add those to my article.
@Dub: I agree that the legality issue of sIFR is a bit unfair, but it IS due to the power of Adobe and rights of use within flash. But as stupid as it may be, I’ve heard there have been lawsuits due to this technicality.. people will do whatever they can for an extra coin in their pocket.. especially typeface owners, they even outsource firms that specialize in searching for copyright violations. Not a path you want to travel down.
Overall I agree with many of you that sIFR is very frustrating to work with, as it doesn’t render properly in some cases and doesn’t follow a very strict styling model with CSS. However, there are simply too many legal or usability issues with the other typefaces that I simply cannot ignore. Thank you for your valuable feedback, I hope you continue to share.
Clay, I think the fact that you consider sIFR to be subject to fewer legal issues comes from a lack of understanding of the SWF format. With sIFR you are still embedding a converted version of the font, it can still be decompiled, and the font can still easily be extracted.
Cufon and sIFR equally (il)legal; they are in fact precisely the same technology. I’m not going to make a judgment as to whether they’re legal or not, since I’m not a lawyer, but there is certainly no separation between them on the legal front.
I recently used Cufon on one of the websites I made. Got a few problems with it (.font.js was kinda bugged and some of letters had like 2000px spaces after them, but I somehow figured out in compressed .font.js which variables are responsible for that and managed to fix .font.js file on my own).
For sure it is nice and fast solution (of course .font.js files are big (20-100kb) but they load before element so layout does not hurt because of long loading time like when using FLIR or SIFR). However I don’t know if I will use it often. It is somewhere between FLIR and SIFR in css-layout impact and styling possibilities. Like FLIR, it has no option to change Antialiasing. Don’t know if it supports effects like shadow or blur (easily available in SIFR and also in FLIR with additional mods). An obvious disadvantage is that Cufon does not support text-align:justify!
So, the truth is that one should choose between SIFR, FLIR and Cufon depending on given layout. Thats all.
I’m working on another web font solution, currently called Fontwebula. It will surely break copyright, BUT my business plan calls for licensing/selling commercial fonts and well as using freeware fonts (there are tens of thousands). In a great many cases you will be able to find a freeware version that is close/identical to the commercial version.
I will attempt to launch my new webapp, OCD, at the TechCrunch50 this year and I will be displaying several webtop publishing tools as well as fontwebula.
Cufon is SEO friendly, see getfamous.biz/…/cufon-a-compromise-between-design-and-seo/
Chance:
That sounds nice. I wonder which tools will you use in your solution, since the most common (and any I can think of) are already used: JavaScript (Cufon), Flash (SIFR) and server-based image generator (FLIR).
IMHO two most important factors are:
* CSS manipulation – how can I manipulate the result using CSS (this is tought in all solutions described here)
* Effects – your solution should be able to generate simple shadows, change antialiasing and support hovering and links.
I wish you good luck!
Duncan:
Cufon is as friendly as FLIR and SIFR as they all use same technique – DOM Element Replacement. They all are launched using JavaScript after webpage is load.
In looking for information on these different types of font replacement, I always see people worrying so much about SEO. Unless I’m totally missing something I don’t see how sIFR or Cufon (haven’t used FLIR) could affect SEO at ALL. If I recall correctly the only thing the search engine web crawlers do is read the HTML of the page (within tags) and with these replacement (this is the keyword here) techniques, the only thing it’s changing is the visual display of that HTML and not the HTML itself. All of them even use techniques of (mostly) unobtrusive Javascript, another plus for SEO.
So on that note, again I’d like to know how these could *possibly* affect SEO.
@Jeremy, right you are my friend, when i wrote this post, FLIR and Cufon were both using techniques that did not degrade to clean markup (FLIR used actual images with alt tags for each letter, and Cufon used markup the rendered the markup unreadable to crawlers that support javascript). I have updated it to reflect the fact that all three of these solutions are SEO optimized now.
Looks like Cufón does support hover (since March).
Furthermore, I am able to select text rendered by Cúfon or FLIR. Like Jeremy says, these techniques do not change the HTML itself, so the text is still there. Or did you mean something else when you say that Text cannot be selected?
Hey, stumbled upon this article while I was searching for reviews of Cufon. I know the focus of this article really isn’t @font-face, but this statement is a bit misleading:
“Internet Explorer 6-8 do not support font-face”
@font-face has been supported since IE4. IE only supports EOT fonts, not TTF or OTF, so you have to use a font that has both formats, or convert a TTF to EOT.
Good article, that’s what I’m looking for. thanks
Nice summary. I’ve done a bunch of research on these options as well:
http://paulirish.com/type/ Lots of slides and research here.
I’d add that Linotype’s current EULA allows use of Cufon with their web license, assuming you do the domain binding. And more and more are allowing it everyday.
One quirk with Cufon is its built-in 10ms setTimeout before actually modifying the text. This is only problematic if you are doing some further computations with the modified text, especially when calculating based on element height/width.
Does anyone know of any cases where a company has been approached for using cufon without license to the fonts?
Regarding the con of Cufon “You can’t apply a hover state to converted text,” you can work around this using jQuery’s hover event. For instance, in the hover over function, use Cufon.replace with the hover colour, and in the hover out function, use Cufon.replace with the original colour again.
I hope this is of use to someone!
Thanks,
Zoe.
Thanks for comparing them all.
I wrote a plugin that implements Cufon into Wordpress themes easily http://tomsramek.com/plugins/all-in-one-cufon/
I hope someone will find it helpful.
In your artcile you said (“Internet Explorer 6-8 do not support font-face”) Actually Internet Explorer was the first browser to support font-face – its support comes since version 4 (or so). The only difference is that they use a different font type or simply a different format – .eot instead of ttf. There are already several online services (like http://www.kirsle.net/wizards/ttf2eot.cgi) that can convert ttf into .eot so support for font-face works well among most browsers.
the problem with font-face is that it doesnt look good when ClearType is enabled on win7 – it looks all jagged. But there are some possible solutions (http://allcreatives.net/2009/12/05/jquery-plugin-ie-font-face-cleartype-fix/)