Rich Typography Options for the Web

June 14th, 2009
  1. | #1

    Nice presentation. The comparison chart is especially useful. Thanks for sharing!

  2. | #2

    Hi Paul, nice presentation.

    Of course I do take some issues with your conclusions on sIFR ;-) For one thing, whilst the configuration sure is different, I wouldn't say it's particularly difficult. In fact it would be quite possible to configure a baseline implementation similar to Cufón.

    I'm not sure if the selector engine speed came up in your tests, or if its a significant problem, but it can easily be replaced by any engine already present.

    Speaking of the tests, due to browser issues with loading Flash, testing performance is a bit tricky. I'd be nice if you could expand on your test approach. I'll also say that replacing 120 elements with sIFR is definitely not recommended.

    Some advantages that sIFR has over the other solutions is that Flash text is rendered within a pseudo-HTML engine, which lets you use bold and italic text, and use different colors and even different typefaces within one Flash movie. It also supports Flash filters for dropshadows et cetera. Text and styling can be changed dynamically.

    This all said, sIFR should be judged as it is, not as how it could be (esp. regarding selector engine), and it definitely is a bit too tricky to get it to perform really smoothly.

    I definitely don't think sIFR is dead, it still has many advantages over the other solutions, and it seems somewhat 'safer' in terms of licensing, though that is an argument I always hesitate to bring up.

    B.T.W., Hoefler & Frere-Jones actually have a section in their FAQ regarding sIFR licensing. They're okay with it, as long as you try to lock the domain and pay an extra license for the web server.

  3. | #3

    @Mark Wubben. Great to have you here. I agree the performance test is hard to make fair for everyone. Because of the different techniques its very challenging to get a timing that encapsulates all (but only) of the font replacement.

    Totally agree that 120 elements isn't recommended, that is part of the color I add when sharing these slides.

    At this point, it appears that most foundries consider siFR, typeface.js, and Cufon to have relatively the same amount of protection when it comes to the font data, and therefore similar thoughts on licensing.

    Thx dude.

  4. | #4

    As Samuel Clemens once quipped, "The reports of my death have been greatly exxagerated."
    In terms of market penetration, Flash still outstrips @font-face by a huge amount. However, in two years time, that will change and @font-face will achieve parity.
    Whether or not sIFR will die depends a lot, I think, on how smoothly fonts render at headline sizes. Flash, Cufón, and any image-replacement system you can name still renders the font much more smoothly than any font rendered in the browser by Windows GDI.
    However, Windows 7 is promising Y-direction anti-aliasing, which I haven't seen yet.
    There's also a little-known server-side product called GlyphGate that uses @font-face that I found very interesting - some impressive demo pages. But I really couldn't make heads-or-tails out of it technically.
    Nice presentation, BTW.

  5. | #5

    @Richard Fink, totally agree on the quality of typeface rendering.

    But the quality between siFR and Cufón is quite close and I'd likely hand it to Cufón. As my slides demonstrate there are a number of advantages to the non-flash techniques.

    Had not seen GlyphGate at all. They claim to have a format called XCGF to hold the web font data, which I certainly haven't heard of. I'm curious if there are some technical tricks that we could steal.

  1. | #1
  2. | #2
  3. | #3

For code blocks, use <pre lang="javascript" escaped="true">. css and html4strict are also accepted.