With browser support / licensing issues of @font-face (a feature of CSS3), which intermediate option do you prefer?
Cufon,Typeface.js, or SIFR?
Cufon is new but has been getting a lot of praise from the web design community, how does it differ from Typeface.js ?
I personally preffer Typeface. It's easy to use and works well. It's created using JavaScript, not both JavaScript AND Flash like sIFR, or JavaScript AND PHP like FLIR.
Typeface.js
Advantages:
Disadvantages:
sIFR
Advantages:
Disadvantages:
Cufón (similar to Typeface.js)
Enter Cufón, the Javascript-based font replacement solution which makes heavy use of canvas and VML. This offers a great alternative to other solutions out there - no Flash or images required.
There are some issues with using Cufón on a live site, the most notable being the inability to highlight and copy/paste text, which is really the biggest issue for your site's users.
Combine that with the EULA issues, which prevent you from being able to legally embed fonts in Javascript files for most fonts on the market today.
The other issue is knowing what fonts can be used with Cufón. For sIFR, most fonts are fair game, since the font is embedded in a Flash movie, which is typically an approved usage by most font foundries for most fonts. With Cufón, the Javascript files used for the font can be easily "stolen" and either used on another website or reverse engineered.
The SVG/VML canvas drawing method (used by Cufon and Typeface.js) has issues with text selection in some browsers, but has very good browser support generally. It doesn't support all text properties that CSS does. Cufon currently has support for more font types and browsers than Typeface.js does; otherwise they're functionally identical.
sIFR has some issues with flickering and relies on Adobe Flash being installed and activated, but has support for all the advanced rendering options, kerning etc, that Flash has.
Which is preferable usually has to do with how the rest of the page works.
I tested all for cross browser compatibility and found sIFR but is the only Accessible, Selectable and most important Cross Browser Compatible.
I'd roll my own - mainly just to get ClearType*esque* support
I did a bit of a review on the three of these and found Cufon to be the best for my needs. I am more of a JavaScript based developer so my views may be slightly biased, Typeface was pretty good but had a few problems with my custom font type.
Check it out the full article here
Personally I think they all produce ugly output, the rendering/anti-aliasing is noticeably worse than what is produced by the browser. Typeface.js is the worst, the text looks uber blurry, SIFR is the best, it's almost as good, but still missing the subpixel antialiasing. Cufon is somewhere in-between in terms of quality.
Check out this quick comparison I made, comparing the rendering of the three methods versus native browser rendering of the same text. Notice how blurry they are, due to both lacking subpixel rendering, and also I think they are lacking in hinting as well (But not 100% sure on this, I'm not font pro)
sIFR
If you are merely replacing title headings and body copy elements then I'm sure sIFR would work fine but I constantly find myself using text replacement for navigation and other design elements that need very fine tuning - something I find a total disaster in sIRF.
cufon
I have yet to find some css property that cufon doesnt recognize (rollovers, backgrounds, etc.etc.) and It always sets up in a fraction of the time that sIFR or FLIR do...It just seems that cufon replaces the font, size, and position of text most naturally (and predictability)
FLIR
I've tried working with FLIR many times and have always encountered problems, mainly with serverside image libraries (GD2 / ImageMagick) being inconsistent from development to production environments - Beware!
If you're targeting mobile phone users too:
I have started a comparison matrix of these different fonts solutions (@font-face vs sIFR vs typeface.js vs Cufon vs FLIR…) :
If you want to improve this public comparison, you are welcome.
sIFR3 requires not only Flash Player, but Flash Player 9, for some peeps (including our company) this put it on a back foot. The reason this was important for me, is that sIFR2's line-height and spacing woes are just too finnickity to overcome with any kind of innate efficiency, so an 'upgrade to sIFR3' was the best option. Perhaps given another few days there might have been something we could've done to fix this... still unsure though I hear other continue to struggle.
Rotated text? Fairly easy in sIFR2 - I did it in a few minutes by duplicating the original sIFR2 .fla and dont_customize_me.as include, renamed them as '_vertical' variants, opened the .fla's up and simply rotated the MovieClip holding the TextField and set some new default dimensions! I should admit that I had to comment out some of the original dont_customize_me.as scaling, which is fine really because the nature of my interface wasn't relying on pliable heights - I could safely apply height layout CSS props to our replaced elements. I reckon my efforts could've been doubled to make it more flexible.
Aaaand a biggy for me was 'display:none;' content... ugh, royal PITA with sIFR2, though doable, I ended up having to apply a temporary CSS class to move the replaced elements off-screen (position:absolute;left:-10000px;) and replacing the temporary class with the intended hidden class. I never figured out if sIFR2 had a replace() callback, which is ideally where I should've switched classes, but time and budget made me do the switch whenever my hidden elements were revealed.. it worked but.. ho hum.
Cufon on the other hand, replaced correctly, didn't flicker when following the clear guidelines, and IE6 seemed to have a few issues with leaving the VML replacement layers in the same position when the DOM is manipulated around the replaced elements (like revealing 'display:none;' content), I foudn this to be inconsistent, and sometimes setting 'position:relative' on the replaced element.. worked?. I did also notice that the 'selection area' on a elements in IE8 is fragmented, the cursor flickers between pointer and default between words (there's most likely a more refined, rational explanation of this effect out there...).
