Cufón Font Replacement - The Good and The Bad

Erik Olson, ON THE TOPIC OF CSS and Javascript and Opinions/Reviews

Apr13 21

As soon as designers got ahold of the web as a design medium (probably about 15 years ago), they were thinking about fonts, right? (It was at least in the top five on the "first things to think about" list). So, in an age where tens of thousands of fonts have been invented, why are we mostly still using the same six?

Techniques like image replacement and sIFR have done us well. They remain the strongholds until something better comes along -- which may have just happened: namely, I'm talking about Cufón by Simo Kinnunen.

Cufón (I'm pronouncing it "koo-fon") is a font-replacement technique that uses javascript and vector graphics to write fonts from a font file (TTF, OTF or PFB) to your browser. It's easier/safer to use than sIFR and lighter on size than image replacement, but has the same copyright issues as both.

What Does Cufón Do?

The way Cufón works is pretty smart and highly technical. A proprietary javascript rendering engine takes your font file and converts it to a vector form. From there, it's translated to VML (Vector Markup Language). The result? Essentially, the font outline is written as JSON and converted into lots of numbers that define every curve and angle of its shape. The html5 canvas element is used to display the font in most browsers while VML is used in Internet Explorer (kudos to IE who has supported VML since IE5.5. VML is a very fast way to display vector graphics).

What's Good About It?

Ease of Use. The process involves uploading your font file to the script generator and adding the resulting file to your page, then adding the rendering engine script to your page. The final step is calling Cufon.replace javascript method for the particular text you want to replace. Those of you who have experience with sIFR know that while it provides for any font you need, it's tough to set up. I think I had the Cufón set up in about 5 minutes with no problems (and I'm not that bright).

File Size. Once the rendering and compressing is all said and done, the font size is about 60-80 percent less than the original.

Fully Supported. It's not Flash, so there's no need for the plug-in. And it is fully compatible in all major browsers.

It's also light on the browser. Click here to turn on Cufón in this section.

What's Bad About It?

~~Not Selectable~~. When the font is displayed it's rendered as a bunch of elements broken up by word. This is a serious limitation because Cufón text is not selectable(try it if you converted the text above). Personally, I often find myself wanting to select many things that look like text but isn't like images and flash content that isn't properly enabled to be selectable(selectable content in Flash SHOULD be the default setting people!). This will be a consistent point of frustration.

UPDATE: Within minutes of publishing this post I was shown by a few people that it is possible to select Cufón text. Here's the way Cufón works. The javascript file breaks up the html text you want to replace with Cufón by word and wraps each word in a span tag. It adds a class to the span that sets the height and width to "0" so it appears as though the text is not visible but in reality is still there as far as the browser is concerned. The experience isn't optimal but in IE(6-8), Safari 4, Chrome and FF3 you are still able to select the original HTML text. Although FF3 won't show you the selected text but if you select it and hit ctrl+c you will be able to paste it.

The Copyright Problem. This is the biggest issue. When generating your Cufón javascript file, you are given the option to restrict the use of your font to certain domains. I don't know whether or not this makes the font totally secure. What I do know is that it seems like it would be a tricky process, which will likely curb the majority of font stealers right there. sIFR has the same issues where it is possible to decompile the flash file and steal the font; however, people haven't been doing this. Since it hasn't been a problem with sIFR, I don't expect it to be a problem with Cufón.

Conclusion

When thinking about fonts on the web, what is the best case scenario for us? Probably the ability to embed any font directly into any browser using HTML/CSS, right? Cufón comes fairly close, but is still just a simpler hack. Cufón is certaintly not the final word on fonts on the web, but is -- at this point -- a little closer thanks to its simplicity and compactness.

Jeri Hastava said on 04/15 at 01:26 PM

Thanks for the Cufón review. I agree that selectable is nice, but as a designer, if I restrict the use to headlines, it doesn’t seem as much of a deterent. And as a non-technical person, the fact that I could make it work is a huge plus.

Jeremy said on 04/15 at 01:31 PM

Thanks for the great writeup. I recently converted a client site from sIFR to Cufon and I was amazed at the simplicity of setup. Cameron Moll also posted a writeup about Cufon and he highlighted the point that Cufon allows you to specify the units per em for which your typeface is rendered. A lower value produces a smaller JS file and better performance but yields a lower rendering quality. A higher value produces good quality at the expense of filesize and performance. http://cameronmoll.com/archives/2009/03/cufon_font_embedding/

Jose Espinal said on 04/15 at 01:35 PM

One thing, I was able to select the text and copy it, I’m using Safari 3.

Sean Rice said on 04/15 at 01:47 PM

I actually like cufon a lot. I don’t need Flash to create a swf or anything complicated. it’s simple to turn on.

That said, I’ve run into a few issues.

1) you CAN copy the font for use on your own web page. Simply open the javascript files, and copy/paste. Adding your domain to the list of supported domains is pretty easy if you know a little javascript (the domain list is in the first 30 or so characters of the generated javascript file). Not a big deal (you could do this with sifr too, but it’s more difficult).

2) I can’t change the properties of the text after the page renders. For example-- what if I wanted to make the text change colors, or grow larger? There’s probably a way to do it, but there’s no documentation as to how.

All said-- it’s much simpler to use than sIFR. So, I think I’ll probably be using much more in the future.

Chris Butler said on 04/15 at 01:50 PM

Erik,

Great info- thanks for posting it. I just put a link to your post in the comments section of our newsletter from February on designing for the web. On the fifth page, I reviewed typography issues around sIFR and image replacement techniques.

Feel free to chime in there with more on Cufón if you’d like.

Chris

Neal G said on 04/15 at 02:03 PM

Looks interesting (yet complicated). For some reason I wasn’t able to select your paragraphs text in Firefox 3 or IE8.

Erik Olson said on 04/15 at 02:08 PM

thanks @Jose, @JacksonFox and others for pointing out that you can select text. I amended my post. See above.

@Sean. You make 2 excellent points.
1) I see what you mean about the security of the font. They had to add the conditional at the beginning of the js file didn’t they. You could either add your domain or just delete the whole conditional and the font is yours. They really couldn’t have made it easier for people to steal.

Since fonts stealing is easier than sIFR, stealing may become an issue. Also at this point there is no policing of fonts on the web so most fonts that get stolen will probably go unpunished.

2) I agree that changing the properties of your font would be a VERY helpful feature indeed. Hopefully, like you say, we’ll see it in the future.

Sean Rice said on 04/15 at 02:24 PM

Erik:
Regarding the security of the font- Despite that you could “steal” the font to use on a web page, I doubt you’d be able to take it and use it in any other manner (print, etc). This is simply because of the simplification of the vectors that has to happen in order to convert it for cufon.

So, maybe it’s still a safe, easy alternative to sIFR.

Tor Løvskogen Bollingmo said on 04/15 at 04:36 PM

Cufón (koo-fo’ ;-) is nice, but not very native, yet. How about using @font-face for modern browsers, and serving Cufón to the rest?

Jukka Lariola said on 04/16 at 12:46 AM

Stealing fonts is really a lot easier than trying to get them from cufon. There are _a lot_ of torrents of fonts, so why make it difficult (IF you’re trying to steal a font in the first place)?

Lyndon said on 04/16 at 09:23 AM

You shouldn’t really rely on JS for security…
but you can normally setup your server/scripting to help in this sort of thing…

Surely the same sort of measures used for Anti-Hotlinking and for Image filepath masking can be employed?
- Either deny any request for that filetype that doesn’t come and/or that does match the font file path (so they cannot request it directly through the URL).
- use something like php/asp to obfuscate the font-filepath - then pass that in to the JS (more of a pain than a prevention), and/or use such scripts methods to refuse direct requests.

With those in place - this looks like a very sweet option (albeit JS based ;)).

Ben Peck said on 04/16 at 04:44 PM

Excellent article. Fonts are the biggest beef I have with designing for the web and this is a wonderful option. I just recently learned of sIFR a few months ago and I’m glad to put them both to use when and where I can.

Thanks again. Great post!

John Pash said on 04/16 at 05:43 PM

I’m surprised nobody has mentioned FLIR (FaceLift Image Replacement) yet. It’s not as simple and lightweight as the others, but I prefer it since stealing fonts is impossible. The font files themselves don’t have to live above the webroot.

Basically it’s a php image generator that dynamically replaces any text you want. It’s unobtrusive and degrades nicely. It’s not for everyone, but I just thought I’d add it to the discussion.

http://facelift.mawhorter.net/

Patrick Haney said on 04/17 at 10:42 AM

Cufón looks interesting, but there’s already something just like this out there called typeface.js, which has support for CSS2 text properties such as font-weight, font-style, letter-spacing and font-stretch. It’s open source, uses the canvas element and VML, and allows you to convert fonts as well.

The problem I see here is that it hasn’t been updated much since its release, and of course the usual copyright issues with typefaces. But it’s a step in the right direction.

Erik Olson said on 04/20 at 09:50 AM

@Pat. Typeface looks great. It does solve a lot of the text property issues Cufon has.

Hopefully if people use it more the author will update it more.

Thanks for pointing that out!

Dennis Smolek said on 04/23 at 04:25 AM

I wanted to add that in the realm of typeface replacement I dont think many designers are using any Sifr or replacement method for the copy itseslf, but headings and MAYBE Menus. Selectability would be less of an issue in this case.

I think the largest pluses here is that Flash is not required to run, and that the file cannot be dissected to gain the typeface.
I know a website can use it if stolen, but in most cases I believe foundries prime concern is with the use in commercial applications, be it digital images or print not .
It is something I hadnt heard of and will be looking into for sure..

Chris Wallace said on 04/29 at 12:11 AM

I hear all the cool kids are combining Cufón and @font-face.

Erik Olson said on 04/29 at 09:47 AM

@Chris. Thanks for the tip. As browsers stand right now your solution sounds like the best fit.

Jamie Allsop said on 05/05 at 04:18 AM

Great post thanks for sharing. Just wondering if the Cufón Font Replacement is compatible with all browsers as well as PC’s and Mac’s.

Erik Olson said on 05/05 at 08:47 AM

@Jamie, Yes Cufón is just javascript so it will run the same on all OS’s. From what I have seen there are little to no quirks across browsers.

Andrew Johns said on 05/18 at 09:12 AM

I’d echo John Pash’s question, why isn’t this being compared to FLIR rather than SIFR?

We’ve been looking at FLIR, but we’re a bit put off by the security issues surrounding it, namely the ability to hit the script from a remote server, potentially causing massive processing or free font replacement hotlinking for 3rd party websites. On the plus side, it does keep the font off the web root, so it’s protected.

FLIR needs to have domain restrictions and/or some kind of private key hashing in a backend php script before it could be considered on a production environment.

How does Cufon or typeface.js hold up to that?

I’d love to see a comparison article on all 4 main contenders. I think I’ll have a quick google now (or write it myself if there isn’t one) :)

Commenting is not available in this weblog entry.

Next entry: Displaying Your FeedStitch JSON Feed Using jQuery

Previous entry: Portfolio Reviewin’, Thoughts and Ideas for Design Students

Viget Inspire