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.


42 thoughts on “Opera hates my web font”

  1. 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.

  2. 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.

  3. 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).

  4. (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).

  5. 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

  6. 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.

  7. 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.

  8. 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).

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

  10. 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?

  11. 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.

  12. 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.

  13. @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.

  14. @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.

  15. @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;
    }

  16. 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?

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

  18. 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?

  19. @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!

  20. @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.

  21. 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.

  22. 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….

  23. 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”?

  24. 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.

  25. @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?

  26. 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.

  27. @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 :(

  28. 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/

  29. 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.)

  30. @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.

  31. 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.

  32. 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.

Comments are closed.