Opera loves my web font

And so do my iPhone and your iPad. All it took was a bit o’ the old Richard Fink syntax and a quick drive through the Font Squirrel @Font-Face Kit Generator (featuring Base 64 encoding and SVG generation) to bring the joy and wonder of fast, optimized, semi-bulletproof web fonts to Safari, Firefox, Opera, Chrome, iPhone, and Apple’s latest religious device.

Haven’t checked IE7, IE8, IE9, or iPad yet; photos welcome. (Post on Flickr and link here.)

What I learned:

Even if manufacturer supplies “web font” versions with web license purchase, it’s better to roll your own web font files as long as this doesn’t violate the license.


31 thoughts on “Opera loves my web font

  1. I know that TypeKit now supports SVN @font-face embedding with iPhone & iPad support.
    Even if designers don’t use @font-face, the iPhone OS supports more fonts than the usual “web safe” font set. The iPhone has 24 font faces built-in and the iPad has 44. For a complete list see here.

  2. A few final observations while things are fresh:

    Disclaimer: Ethan Dunham of Font Squirrel and FontSpring has done more to promote web fonts and @font-face than anyone on the face of the planet. We correspond on various issues and enjoy a friendly, collegial relationship. I thought his response to all this was classy and flexible.

    So:
    Why is there no WOFF file included with the FontSpring web fonts package? WOFF files are natively compressed. Very efficient. Adding it to the src stack is a simple matter and, as long as it precedes the TTF in the stack, Firefox 3.6 will automatically request it.
    Hakon Wium Lie has expressed support for WOFF, as well. So I assume we’ll soon be seeing support for it in Opera before too long.

    Also – and this has to do with getting things to work in IE 6, 7, and 8 – the EOT file that’s included in the package simply cannot work as expected. The font’s internal data – which, as with other Microsoft apps, Internet Explorer less than 9 relies on for clues as to style and weight – isn’t right.
    (The fsType and usWeightClass have to be set to certain values that “agree” with the weight and style declarations inside the @font-face declaration. It sounds more complicated than it is. And yes, it’s not conformant with CSS3, but – as Jeffrey Z once wrote about the quirks mode box model, it isn’t stupid, either. And, incredibly, Microsoft hasn’t documented it. (Sylvain? Am I missing something?) So how could anybody know?)
    In the course of developing EOTFAST 2.0 I’m in the process of documenting all this and it won’t be unclear much longer. Everything yields to analysis. And getting it wrong is a part of getting it right.
    We’ll get you squared away for IE, too.

  3. Can’t reproduce was Stefan reported – tried with Safari 4 on both Windows 7 and Snow Leopard.

  4. Michael: Sweet. I haven’t run Browsercam in a while. It’s a fine service.

    Notice that, according to Browsercam, Safari 3.2.3 for Windows XP does a much better job of handling type than Safari 4.05 for Windows XP, which gets everything wrong.

    What does this tell us? It tells us that the two test computers had different default settings. The computer with the newer version of Safari had ClearType turned off and seems to have been missing Georgia. The computer with the older version of Safari had ClearType turned on and was not missing Georgia.

    And that’s the problem with testing services and with the whole idea generally of expecting the web to look the same from one computer to the next. User preference settings can be just as important as the browser’s capabilities. Safari has the ability to deliver gorgeous type in Windows. But not if the user has turned off font antialiasing.

    Thanks again for sharing that!

  5. @Jeffery, do share what you find if you decide to turn off your bold declaration for IE. This has been a very illuminating conversation here of late.
    Cheers all!

  6. Jeffrey,

    In IE 6, 7, and 8 – when there is a one-member font-family, it doesn’t matter what weight or style you declare in the @font-face declaration because when the browser does it’s font-family name lookup, it will find only one possible match.
    For some reason, IE just isn’t “seeing” the @font-face declaration. Not exactly sure why.
    You have a win-ie-all.css file in conditional comments, up top in the source.
    Assuming you’re EOT is OK, which it probably is, try moving the rule:
    @font-face{
    font-family:’FranklinGothicFSDemiCondensed';
    src:(‘franklin-whatever.eot’);
    }

    into the top of that IE-only style sheet.
    Betcha it does the trick.
    (I did download a local copy of your page, and have gotten it to work by moving the declaration out of where it’s at, and further up in the source.)

    Rich

  7. Just to be clear, Base-64 encoding a font doesn’t actually protect it in any way. We encode our fonts at Typekit simply to avoid additional HTTP connections, and to add a tiny bit of obfuscation. But the way you’ve included the font here still allows easy extraction from the cache and a double-click to install. Just open up the Safari activity window to grab the font, rename it with a .otf extension, and install it. That’s likely a violation of the publisher’s EULA.

    That’s why we (and FontSquirrel) split our fonts into multiple segments, and recombine with CSS. That way, when you pull fonts from the cache, they still need to be opened in a font editing program and recombined glyph-by-glyph. That seems to be enough to send would-be pirates elsewhere and avoid casual misuse by people just poking around.

    All of this is kinda hacky, but it works for now. Of course, we’re looking into more sophisticated ways of making fonts uninstallable, and advocating for WOFF as well.

  8. For some reason, IE just isn’t “seeing” the @font-face declaration. Not exactly sure why. try moving the rule … into the top of that IE-only style sheet.

    Thanks, Richard. Have done that.

    It looks good in IE8, too. That is, the type renders correctly and is smooth and attractive. There are some nasty widows in headlines that fit comfortably into a single line in Firefox, Webkit, etc. But this is the web, and the main point is that the font works in IE.

    Richard, your knowledge in this area is wonderful. Thank you for sharing.

  9. Jeff:

    Just to be clear, Base-64 encoding a font doesn’t actually protect it in any way. We encode our fonts at Typekit simply to avoid additional HTTP connections, and to add a tiny bit of obfuscation.

    I wouldn’t know how to do that myself. I did not upload TTFs to my server, only WOFF, EOT, and SVG. The TT fonts exist in the style sheet, not as a discreet binary file on my server.

    That said, it’s just obfuscation and a determined thief could get to it, I suppose. But there are easier ways to steal fonts. And font thieves are not a type designer’s market.

    we (and FontSquirrel) split our fonts into multiple segments, and recombine with CSS.

    In that case, I’m doing the same thing, since I used FontSquirrel to convert my font. But FontSquirrel’s method seems to avoid the problems inherent in Fontspring’s method. Via FontSquirrel’s method, the type still displays correctly in Opera, and there is no (or almost no) flash of unstyled or invisible content.

  10. and advocating for WOFF as well.

    I’ve got WOFF up there as well and will be thrilled when Safari, Chrome, Opera, Mobile Safari, and (dare we dream?) IE follow Firefox’s lead in supporting WOFF natively.

  11. One more quirk from font purgatory:

    When I remove …


    @font-face {
    font-family: 'FranklinGothicFSDemiCondensed';
    src: url('franklingothicdemicd.eot');
    }

    … from the main stylesheet and move it to the IE-only (conditionally served) stylesheet, Safari stops serving the web font, and substitutes the bolded system font. Not what we want.

    In order to force IE to support the web font and prevent Safari from ignoring it, I had to restore the EOT rule to the top of the stylesheet all browsers see and stick it redundantly in the IE-only (conditionally served) stylesheet as well.

    There is no conceivable reason that Safari, which ignores EOT, should require the EOT rule in the stylesheet in order to recognize the TTF rule that follows, but, as Mr Veen has said, all this stuff is sort of hacky right now.

    (shrugs, reaches for Advil)

  12. FontSpring is rad. I love being able to buy fonts that can be used on the web. Makes me feel good.

    I too have purchased the great (and inexpensive!) Franklin Gothic FS family that FontSpring offers, and in reading the @font-face license that comes with it, I noticed a couple of parts that have me concerned about rolling my own font files. I’ve included them below:

    1. You must use the provided web-only version of the licensed font (Web Font). Linking to the full, licensed CFF OpenType font designed for desktop installation is prohibited.

    and also:

    You may not convert or embed the licensed font with any other technology. This includes Javascript methods such as Cufon and Typeface.js.

    I’ve taken this to mean that using files other than the ones provided is not allowed. I’d love to be mistaken about this. Am I?

  13. My cover is blown. Thanks for the kinds words @richard and @zeldman. Appreciate it. More updates soon…

  14. Sorry, Jeff…. your font looks like a half-opened zipper in Chrome/Firefox (latest stable releases). I fiddled with screen resolution, to no avail. Bummer. Looks like you wasted three bucks in my useless opinion.

  15. In that case, I’m doing the same thing, since I used FontSquirrel to convert my font. But FontSquirrel’s method seems to avoid the problems inherent in Fontspring’s method.

    Sorry, I got the two confused in my comment. FontSpring does segmenting in a similar fashion to Typekit; FontSquirrel does not. Most EULAs forbid putting the installable OTF on a webserver, even if it is obfuscated via Base-64 encoding.

    That said, I think we’re all looking forward to a day when it all Just Works, and we’re spending our time building beautiful web sites and not tearing apart font files.

  16. Sorry, Jeff…. your font looks like a half-opened zipper in Chrome/Firefox (latest stable releases).

    Thorn:

    In my tests it looks great in the latest versions of Chrome, Firefox, Safari, Opera, and IE8 and on iPhone and iPad. I’m sorry it looks lousy on your system. What OS are you using, and is subpixel antialiasing turned on?

  17. Shane Berry:

    It is good to look carefully at the @font-face license.

    This section is straightforward:

    You may not convert or embed the licensed font with any other technology. This includes Javascript methods such as Cufon and Typeface.js.

    I take that at face value and avoid using any such methods.

    Linking to the full, licensed CFF OpenType font designed for desktop installation is prohibited.

    This too I take at face value.

    You must use the provided web-only version of the licensed font (Web Font).

    Here is where I have been liberal in my interpretation and rolled an alternate web-only version of the licensed font, which seems to work better—as can be seen by comparing this post and the site currently to the earlier post, “Opera Hates My Web Font.”

    I was a little nervous about this but I did it publicly, and I used FontSquirrel’s @Font-Face Kit Generator to do it.

    Little did I know at the time that FontSquirrel and Font Spring are the same person (or at least have the same principal, Ethan Dunham, behind them). As Ethan has read these posts and has not objected, and as he says that Fontspring is working on new versions of the web fonts, I understand what I’ve done to meet with the maker’s approval.

    Web fonts are a moving target at this time—another appeal of a service like Typekit. As web font versions get better, as @font-face bugs and workarounds get better, as versions of fonts you have already purchased that are better optimized or better hinted for the web get released, Typekit will replace the fonts, so that your site will work better and better.

    Likewise, some foundries plan to do Typekit-like hosting for exactly this same reason: so that as they discover bugs or improve hinting and rendering in their web fonts, they can deliver improved versions to their customers without contacting those customers, asking the customers to download the fonts and replace their CSS, etc.

    On the other hand, with a Fontspring typeface going for $13 and a web license costing an additional $2.99, for sites with which you have an ongoing relationship, it would be easy enough to subscribe to a Fontspring newsletter or to request a notice when a web font is updated, and to replace that font and if necessary the CSS as needed.

    Which technology I’ll choose at a given time depends on my relationship to the site and the quality of the existing web fonts. If I’m not going to be involved with the site in any way after delivering it, and if there are problems with the web fonts (but we’ve gone ahead with web fonts in spite of those problems), then an arrangement with Typekit (or a trusted foundry that hosts and will switch out fonts as they are upgraded) is the way to go.

  18. Jeffrey Veen:

    Most EULAs forbid putting the installable OTF on a webserver, even if it is obfuscated via Base-64 encoding.

    Indeed! And I did not do any such thing, and never would (unless the license allowed it, as Font Foundry’s license for a Franklin used elsewhere in these pages did). I converted the installable OTF to a web TTF with glyphs and other features removed, and then I obfuscated it through Base-64 encoding.

    Sorry, I got the two confused in my comment.

    Well, they are both Ethan Dunham productions, as I have now learned and you doubtless knew. :)

  19. Thanks for responding!

    Yes, it seems that if Mr. Dunham has been reading this and has not raised any red flags, then converting our own versions of the font files is acceptable. This is great news! Thanks again!

Comments are closed.