11 Apr 2010 12 pm eastern

Opera hates my web font

Opera hates my web font.

So I’ve wanted to use a condensed, bold Franklin typeface for my site’s headlines since, well, forever. So I bought Fontspring’s fine Franklin Gothic FS Demi Condensed and licensed it for @font-face use for a mere $2.99, an incomparable value.

It looks great in Safari, Chrome, and Firefox, but not so nice in the latest version of Opera, where it resembles the inside-out test monkey in Cronenberg’s “The Fly.” (Okay, okay, it looks like a ransom note, but the monkey simile was more picturesque.)

And this, my friends, is why Typekit exists. Because even when you find a great font that’s optimized for screen display and can be licensed for CSS @font-face use, guess what? There is almost always some glitch or bug somewhere. And Typekit almost always seems to find and work around these bugs. It’s the kind of grueling task designers hate dealing with, and Typekit’s team loves solving.

If this were a client site, I’d switch to Typekit, or try licensing a different vendor’s Franklin, or (if neither of those options proved satisfactory) dump web fonts altogether and use Helvetica backed by Arial instead. But as this is zeldman.com, I’d rather nudge my friends at Opera to look into the problem and fix it. This will make browsing zeldman.com in Opera a somewhat weird experience, but hopefully it will help all Opera users in the long run.

Implementation Notes and Details

  • I haven’t made an SVG version yet, so the web fonts don’t work in iPhone or iPad.
  • iPhone and iPad see normal weight Helvetica instead of bold Helvetica, because if I leave “font-weight: bold” in the CSS declaration, Firefox double-bolds the font. This is not smart of Firefox. Fixed via technique below.
  • In order to match the impact of the previous Helvetica/Arial bold, I boosted the font-size from 25px to 32px. (This also helps smooth the font. Web fonts need more help in this regard than system fonts.)
  • Camino ignores @font-face and supports the first system font in the font stack, Helvetica Neue (correctly styled bold).

Update: Problem solved. See Opera Loves My Web Font.


Filed under: Browsers, bugs, State of the Web, The Essentials, Web Design, Web Design History, Web Standards, webfonts, webkit, webtype

42 Responses to “Opera hates my web font”

  1. Matthew Leak said on

    Have you tried using Cufon? It’s the best font replacement tool out there in my opinion.

  2. Ben said on

    I have run into problems too with Opera and @font-face. It also seems fairly tempermental in which letters it doesn’t render properly. Would be interesting to hear if this is the font, or Opera’s implimentation of @font-face.

    Let’s hope it gets sorted with the ever growing popularity of @font-face.

  3. David Sutoyo said on

    I thought Typekit doesn’t work with Opera yet? Then again I may not have been using Typekit correctly :p

  4. xen vps said on

    Personally I hate IE!

  5. Thomas Hühn said on

    Correct, no Opera support on Typekit and no hints, when it might be added. :-(

  6. Lydia Mann said on

    My cold feet regarding diving into web font use grow icy…

  7. Jeffrey Zeldman said on

    no Opera support on Typekit

    I should not have assumed Typekit supported Opera. I just thought… Well… Wow.

    It’s particularly ironic given that Opera’s CTO is the co-creator of CSS web fonts and was a leading vocal advocate of their use.

    Håkon, my brother, how’s web fonts support coming along in the next version of Opera?

  8. Jeffrey Zeldman said on

    Have you tried using Cufon?

    Yes, certainly. We’ve used sIFR, Cufon, all that stuff. One problem with Cufon is, it’s inaccessible: text is an image, not selectable, not text. The other problem with Cufon is that it violates the end-user license on most fonts (that is, it’s not kosher: many font designers consider it piracy).

    That leaves sIFR, which relies on the Flash plug-in, and CSS @font-face, which is part of the CSS2 standard (also in CSS3; they removed it from CSS 2.1 for who knows what reason). SIFR is a pain to implement. @font-face is easy and standard, except, well, except for problems discussed in some of these posts.

  9. alessandro said on

    if I leave “font-weight: bold” in the CSS declaration, Firefox double-bolds the font.

    Dud you try this in the font in the @font-face?


    @font-face {
    font-family: 'FranklinGothicFSDemiCondensed-1';
    font-weight: bold;
    src: url(//:) format('no404'), url('FranklinGothic-DemiCd_font1.ttf');
    }

    so the browser knows that when you set a font-weight bold it should use the FranklinGothic-DemiCd_font1.ttf font (or any other you choose instead).

  10. alessandro said on

    (corrected)

    if I leave “font-weight: bold” in the CSS declaration, Firefox double-bolds the font.

    Did you try this in the @font-face declaration?


    @font-face {
    font-family: 'FranklinGothicFSDemiCondensed-1';
    font-weight: bold;
    src: url(//:) format('no404'), url('FranklinGothic-DemiCd_font1.ttf');
    }

    so the browser knows that when you set a font-weight bold it should use the FranklinGothic-DemiCd_font1.ttf font (or any other you choose instead).

  11. Josh Vickery said on

    It looks like Ubuntu 9.10 hates your web font too, though not as much as Opera hates it. In both the packaged Firefox 3.5.9 and Google Chrome 5.0.342.9 beta the capitals render in different sizes at 32px. At 30px and 34px (adjusted using the Google Chrome inspector) they display in the same size. I posted a snap of the different renderings at vickeryj.com/fonts.png

  12. Bennobo said on

    “Opera is not yet supported due to a bug in their rendering of the CSS font-stack.”
    http://www.fontspring.com/fontface

    I like “not yet”. Sounds promising.

  13. Jeffrey Zeldman said on

    alessandro:

    Did you try this in the @font-face declaration?

    Not until I read your comment. That’s a new one on me! And it works. Thanks!

    Display is now bold in Apple devices that don’t support TT web fonts.

  14. Thomas Hühn said on

    Bennobo, that statement by Typekit was when Opera 10 was just out, I think. Since then we’ve got 10.50 and a point release.

    I haven’t seen any updates yet, whether the bug alluded to is fixed. Total silence from Typekit and Opera, it seems.

  15. alessandro said on

    It is a great pleasure to be useful to the man that is responsible for my passion for web design and development (and for my actual job too).

    The problem with Firefox is that if it reads that the font-weight should be bold, it renders the font bolder using its build-in font transformation engine.

    I don’t know if this is not smart or too smart. The Firefox bold version of the font obviously is different from the real bold version of the font (if one exists), but this behaviour can be useful if you have only one style for a font and want to render bold and italic styles too.

    Anyway, I think that there is a common error in many of the auto-generated @font-face stylesheets, also in the great @font-face kit generator of Font Squirrel.

    If you have, say, 3 styles for a font (DejaVuSans.ttf, DejaVuSansBold.ttf, DejaVuItalic.ttf), in my opinion you should always use 3 @font-face declarations:


    @font-face {
    font-family: 'DejaVu Sans';
    font-weight: normal;
    font-style: normal;
    src: url('/DejaVuSans.ttf') format('truetype');
    }

    @font-face {
    font-family: 'DejaVu Sans';
    font-weight: bold;
    font-style: normal;
    src: url('DejaVuSansBold.ttf') format('truetype');
    }

    @font-face {
    font-family: 'DejaVu Sans';
    font-weight: normal;
    font-style: italic;
    src: url('DejaVuSansItalic.ttf') format('truetype');
    }

    I don’t see any reason to do it in other ways (but I have not tested so much the @font-face property).

  16. Bennobo said on

    Thomas Hühn, Opera will fix that sooner or later thanks to this post of Zeldman. Jon Hicks will do the rest :P

  17. Ingo Chao said on

    Fx 3.6.3 Mac shows a 3-step change for the headline to appear in its final shape (system first, then FranklinGothic-DemiCd_font1.ttf, then FranklinGothic-DemiCd_font2.ttf). And in Safari 4.0.5, the top image is loaded, then the headline pops up. I think the empty cache situation needs adjustments. How would a big site with slow performance render this, would it show re-flows of the layout as a whole?

  18. Jeffrey Zeldman said on

    alessandro said:

    It is a great pleasure to be useful to the man that is responsible for my passion for web design and development (and for my actual job too).

    I’m blushing redder than my links. Thank you for your kind words.

    I don’t know if this is not smart or too smart. The Firefox bold version of the font obviously is different from the real bold version of the font (if one exists), but this behaviour can be useful if you have only one style for a font and want to render bold and italic styles too.

    This is the kind of thing where browser makers are on their own. There’s no right or wrong. For instance, when OS X debuted, Macs used a version of Lucida—Lucida Grande—that contained no italic. Many of us fell of in love with the font and stuck it at the front of our CSS font stacks.

    So what happened when a web browser encountered an italicized word that was set in a font containing no italics?

    Firefox slanted Lucida to fake the italics.

    Safari substituted a font that actually contained italics.

    Which was the right thing to do? Both. Either. And neither, depending on how you look at it.

  19. Jeffrey Zeldman said on

    Ingo said:

    And in Safari 4.0.5, the top image is loaded, then the headline pops up. I think the empty cache situation needs adjustments.

    Yes, that is annoying. A theoretical advantage to working with Typekit is that it caches the fonts. If more than one site you visit uses the same web font, then there won’t be a delay when you visit the second site (as the font will still be cached).

    Fx 3.6.3 Mac shows a 3-step change for the headline to appear in its final shape (system first, then FranklinGothic-DemiCd_font1.ttf, then FranklinGothic-DemiCd_font2.ttf)

    That is odd. It should be a 2-step change: system first, then Franklin Gothic Demi Condensed.

  20. Gonzo said on

    @alessandro, that’s exactly the way FontSquirrel supplies the @font-face kit, at least for DejaVu Serif. I am using this font on my blog and have all four @font-face declarations the stylesheet.

  21. alessandro said on

    @Gonzo
    No. If you look at the stylesheet.css in the font-face kit of DejaVu Serif downloaded from Font Squirrel, you will not find any font-style or font-weight property inside the @font-face declarations. This is the point.

  22. Gonzo said on

    @alessandro, I just checked, and you’re right about the normal weight and style font, but the bold and italic variant all have the corresponding properties:

    /*
    * This CSS file has been generated by fontsquirrel.com
    *
    */

    @font-face {
    font-family: ‘DejaVu Serif’;
    src: local(‘DejaVu Serif Book’),
    local(‘DejaVuSerif-Book’),
    url(‘fonts/DejaVuSerif.ttf’) format(‘truetype’);
    }

    @font-face {
    font-family: ‘DejaVu Serif’;
    src: local(‘DejaVu Serif Italic’),
    local(‘DejaVuSerif-Italic’),
    url(‘fonts/DejaVuSerif-Italic.ttf’) format(‘truetype’);
    font-style: italic;
    }

    @font-face {
    font-family: ‘DejaVu Serif’;
    src: local(‘DejaVu Serif Bold’),
    local(‘DejaVuSerif-Bold’),
    url(‘fonts/DejaVuSerif-Bold.ttf’) format(‘truetype’);
    font-weight: bold;
    }

    @font-face {
    font-family: ‘DejaVu Serif’;
    src: local(‘DejaVu Serif Bold Italic’),
    local(‘DejaVuSerif-BoldItalic’),
    url(‘fonts/DejaVuSerif-BoldItalic.ttf’) format(‘truetype’);
    font-weight: bold;
    font-style: italic;
    }

  23. Ben said on

    Just so you know, Android hates your web font too!

    http://twitpic.com/1eywvb

  24. alessandro said on

    This is the beginning of the stylesheet I downloaded from fon squirrell.

    /* Generated by Font Squirrel (http://www.fontsquirrel.com) on April 1, 2010 12:40:47 PM America/New_York */

    @font-face {
    font-family: ‘DejaVuSerifBook’;
    src: url(‘DejaVuSerif.eot’);
    src: local(‘DejaVu Serif’), local(‘DejaVuSerif’), url(‘DejaVuSerif.woff’) format(‘woff’), url(‘DejaVuSerif.ttf’) format(‘truetype’), url(‘DejaVuSerif.svg#DejaVuSerif’) format(‘svg’);
    }

    @font-face {
    font-family: ‘DejaVuSerifItalic’;
    src: url(‘DejaVuSerif-Italic.eot’);
    src: local(‘DejaVu Serif’), local(‘DejaVuSerif-Italic’), url(‘DejaVuSerif-Italic.woff’) format(‘woff’), url(‘DejaVuSerif-Italic.ttf’) format(‘truetype’), url(‘DejaVuSerif-Italic.svg#DejaVuSerif-Italic’) format(‘svg’);
    }

    @font-face {
    font-family: ‘DejaVuSerifBold’;
    src: url(‘DejaVuSerif-Bold.eot’);
    src: local(‘DejaVu Serif’), local(‘DejaVuSerif-Bold’), url(‘DejaVuSerif-Bold.woff’) format(‘woff’), url(‘DejaVuSerif-Bold.ttf’) format(‘truetype’), url(‘DejaVuSerif-Bold.svg#DejaVuSerif-Bold’) format(‘svg’);
    }

    May be am I looking at the wrong file?

  25. Gonzo said on

    They have changed things a lot since I downloaded the kit few months ago. Added WOFF and SVG and removed font weight and style.

  26. Fontspring said on

    At this point, Fontspring and Typekit have the same problem with Opera. Opera does not use the font stack properly and you end up with a mess. We are considering a few options to fix this. if Opera won’t do it, we certainly will try.

    @Ben – I assume that the Android browser you used is also Opera-based and not Webkit?

  27. Font Squirrel said on

    @Gonzo, @alessandro – A while back I updated the font-generating engine and that code that added the weight/style part was deleted. In my testing just now, it does indeed work across browsers. I notice here that Opera fails to deliver the correct font for the italic/bold styles and instead fakes it. And oddly if I refresh the page in Opera I lose all the webfonts completely.

    I will see about adding that CSS back into the generator. It is somewhat a guessing game as fonts are incredibly inconsistent with the way they’re named and put together. And even more so with free fonts. But I’ll see what I can do about it!

  28. Alessandro said on

    @Font Squirrel – Thank you for your answer!

    I understand that the inconsistence of free fonts can be a big problem for you. Anyway, I think you are doing a great work with free fonts, and your @font-face kit generator is fantastic.

    Thank you again for everything.

  29. Jeffrey Veen said on

    As @Fontsquirrel mentioned above, Opera’s inappropriate handling of segmenting and CSS stack fallbacks makes us unable to support that browser with Typekit. We’ve been working with the engineers there, including Håkon, and we’ve built a bunch of test pages to help isolate the problem. They’ve been very responsive, though I haven’t had an update for a couple weeks now.

    The nice thing, which you point out in your article Jeffrey, is that Typekit users won’t have to do anything when Opera comes around. We’ll test and deploy, then fonts will start being served to that browser automatically. It’s just like when foundries send us new versions of their fonts with improved hints for rendering — we push them out and our customers sites look better. We’ve done this dozens of times already.

    Anyway, we’ll get there with Opera ASAP. And Franklin Gothic looks great on your headlines, btw.

  30. Richard Fink said on

    I just caught up with this post.
    First of all, when you are declaring a font-family with more than one member, always add the font-style and font-weight to the @font-face declarations.
    (By “font-family” I mean fonts that are declared using the same font-family name.)
    Even if it’s a one member family, getting into the habit of writing:
    font-weight:normal;font-style:normal;
    is a very good idea. It’s unambiguous.
    Understand that unless you “declare” which members of the family are normal or italic, or bold or bold and italic, the browser can’t possibly know what font to use when you set an HTML element’s CSS properties to font-weight:bold or normal / font-style:normal or italic.
    font-weight and font-style inside the @font-face declaration have a different meaning than when used outside the declarations.
    Outside the declarations they mean: “apply bolding” or “apply italic”. Or not.
    Inside the @font-face declaration they mean: “This font is the bold member of the family, this font is the italic member of the family, etc…”
    Clearer?
    Now…. Opera doesn’t seem to be having any problem with the demo page at Fontsquirrel for this font, so I’m puzzled as to what’s going on here.
    In my last go-around with the Opera team over @font-face the only problem I saw was lack of synthesized bold and italic.
    Checkin’ it out….

  31. Richard Fink said on

    I’ve checked everything out. I know what the problems are here.
    I went and bought the entire Franklin set so I could recreate the whole process you went through, too.
    I had no idea that FontSpring was selling split TTF files.
    Do-it-yourself DRM. I had no idea.
    It really works, too. It took me all of eight minutes to download the two font files from your site and recombine them into a single file.

    Kiss optimization goodbye. With this approach you will always have two http requests when there should be only one. If it was a font-family of regular, italic, bold, and bold italic, you would have eight http requests and I imagine the Flash Of Unstyled Text would look pretty wild on the first page load.

    Oh, yes, Opera should handle the fallback properly and recombine the two fonts, character by character, on the fly. (That sounds nice and efficient, doesn’t it?)
    But that really seems besides the point to me.

    Curious:
    If licensing restraints only allow you to use a part of what the standard describes and allows, does that entitle somebody to say their approach is “standards compliant”?

  32. Philip Renich said on

    Don’t forget in all of your @font-face declarations that IE buggers out with “style linking.” According to Tim’s Nice Web Type How to Use CSS Font-Face article, putting font-weight or font-style in the @font-face declaration will cause IE to completely ignore it.

    That sucks.

    Instead you declare individual font-family names. In the article scroll down to the heading “It Takes Two, Baby”

    I haven’t played around with this explicitly to test it. Anyone have experience with style-linking? It’s definitely a nicer and easier way to do things.

  33. Alessandro said on

    @Richard Fink

    I went and bought the entire Franklin set so I could recreate the whole process you went through, too.

    Richard, are you ok?

  34. Jeffrey Zeldman said on

    I had no idea that FontSpring was selling split TTF files.

    Do-it-yourself DRM. I had no idea.

    It really works, too. It took me all of eight minutes to download the two font files from your site and recombine them into a single file.

    Kiss optimization goodbye. With this approach you will always have two http requests when there should be only one. If it was a font-family of regular, italic, bold, and bold italic, you would have eight http requests and I imagine the Flash Of Unstyled Text would look pretty wild on the first page load.

    Richard, I wondered why FontSpring provided two TTF files! You’re saying they broke one font into two TTFs with alternating characters, doubling the page weight and the time it takes the web fonts to load.

    FontSpring also provided the actual font, and while the license forbids me to use the actual font on the site, it doesn’t seem to prevent me from creating my own alternate TTF web fonts. In other words, ignoring the TTF web fonts FontSpring provided, I should be able to pay a quick visit to CSSquirrel, create my own web TTFs (and SVG for iPhone and iPad while I’m at it), and rewrite the CSS per this week’s best practices.

    This will make for a better experience on zeldman.com, but it won’t help folks who are buying FontSpring’s web fonts and don’t have the benefit of hearing from the gifted and knowledgeable people who leave comments here.

    FontSpring, are you committed to creating two versions of every web font (with alternating characters)? Your fonts are fantastic; your web-licensing fees are eminently affordable; you’re a wonderful company providing a great resource for designers. But Richard’s analysis of the way you’re delivering web fonts points to a bandwidth problem (as well as a usability problem in browsers like Opera) you might want to rethink.

  35. Ben said on

    @Fontspring nope, I’m using the stock standard Webkit browser that comes with Android 1.6 (Donut).

    No idea if this issue goes away with Android 2/2.1, might want to check that out. Most of us here in Australia are stuck on 1.6 until Vodafone starts playing nice :(

  36. Scott Kellum said on

    Be careful when setting SVG fonts in Opera. It will strip letter spacing and leave big gaps in your text… I am suprised Opera made such a big deal about web fonts on its release of version 10, it is incredibly poorly implemented…

    I don’t know if you have tried my webfnt method but it might help get it working across all browsers. Proper weight support is also implemented now.
    http://code.google.com/p/webfnt-method/

  37. Jeffrey Zeldman said on

    I don’t know if you have tried my webfnt method but it might help get it working across all browsers. Proper weight support is also implemented now.

    I haven’t yet tried that, Scott, although I read about your launch of it with great interest, and tweeted about it as soon as I finished reading. An issue with your method is that it supports Cufon as a fallback. And that would violate FontSpring’s licensing agreement. (A number of other type shops feel the same way about Cufon.)

  38. Scott Kellum said on

    @ben @Fontspring
    The Android Browser removes @font-face support in v2.0. Enjoy your web font goodness while you have it! Even if it doesn’t load properly.

  39. Fontspring said on

    Thank you for the critical feedback. When we launched this seemed a reasonable tradeoff in order to mildly protect the foundry’s IP. Obviously FOUT, http requests, and Opera compatibility are making that direction less and less a good option. Work is already underway to eliminate the double font. I’ve already been able to create asingle working webfont that will not install on a desktop.

    @zeldman – I’d be happy to provide you with this new version for testing if you are interested.

  40. Sylvain Galineau said on

    TypeKit also splits fonts.

  41. Jeffrey Zeldman said on

    Fontspring:

    Glad to hear you’re working on that, and thanks for the kind offer. I generated a single web font version via FontSquirrel and then used Base64 encoding to obscure it (making it unsteal-able) while also making it load faster in Safari and Firefox.

    Details here.

    Problem solved, speed improved, Opera pleased, font protected.

  42. Richard Fink said on

    @allesandro

    I’m quite OK!
    This will explain my deep interest:

    EOTFAST
    Readable Web

    Web fonts are a big part of my beat. Exasperating work, but somebody’s got to do it. ;)

Comments off.