As I’ve reported before, Opera’s @font-face “support” in 10.00 and 10.10 is so botched it doesn’t even deserve the verb “supports”. It’s so limited and lacking in interoperability with @font-face in Safari, FF, IE, and Chrome that they might as well have not bothered at all.
Paul Irish tweeted a few days back about a post by Andreas Bovens on the Opera Developer Network Odin blog titled Updated Web Fonts Support In Opera 10.5 Snapshot Build.
Updated Support For @Font-Face: Where Is It Hidden?
First, the link to their “snapshot” is not a link to anything resembling a snapshot, it’s a link to. . . . . another Opera blog! It links to a post on the Opera Desktop Team blog titled Continued Stabilization. In other words, the “snapshot” is a blog post by Opera desktop devs reporting on all the improvements they’ve made in 10.5.
Or so they say.
There’s only one problem, folks. If anything, Opera’s support in 10.5 seems worse than before.
Take This Test Page, Please, Take This Test Page
Droid Serif Font Family Test
I’ve been spending a lot of time crafting test pages for @font-face. This test page measures support for a complete font-family. Regular, Italic, Bold, Bold Italic. In this case, I’ve used the Droid Serif family. It renders perfectly in IE, Firefox, Chrome, and Safari. In Opera, the Regular weight renders as Bold Italic.
Here’s a real “snapshot” for comparison.
Droid Serif Regular at 24px Rendered Correctly In Firefox 3.6:
Droid Serif Regular Rendered As Bold Italic In Opera Pre Alpha 10.5:
Try designing a cross-browser page using @font-face with this kind of crap going on.
Dear Opera: Please Stay Quiet Until I Can Link An Entire Font-Family Of Regular, Italic, Bold, and Bold Italic Without A Problem
Back when Opera 10 came out on September 1st last year, I wrote that specifying different weights and styles for a single font-family name was not working: only the last font specified (typically an italic/bold variant) would be applied, thereby overriding other weights and styles of that font family. In other words: a mess.
And now, four months later, comes what – damage control? hope? – which turns out to be untrue:
Fixing this issue took us a bit longer than originally expected (ahem), but I’m happy to announce that a much improved Web Fonts implementation has landed in the latest Opera 10.5 snapshot!
Yes, it took them a bit longer and it will take them a bit longer still because it’s still broken.
I’m hard on Opera, I know. But it’s tough love. Message to Opera: stop the talking, stop the excuses, and just get it right. And for heavens sake, change the fracking name of your browser to something that sounds like a browser people might actually want to use.
{ 9 comments… read them below or add one }
Sweet, good coverage, Richard.
There are some bug reports mentioned on the Opera post.. Check, if you can, if your issues are covered.
I’d also leave them a link to this post over there.
Will do, Paul. Tweet it, baby. Enough of this. They might as well disable @font-face completely for the time being if this is all they’ve got.
rich
No, a snapshot is an Opera build released specifically to allow people out there to test unfinished Opera versions.
If you want them to get it right, the right way to do it is to report bugs.
But then I guess ranting and raving is much easier.
Thanks for the info, now I know that in Operaland, “snapshot” has another meaning.
So, before I wrote this post, I downloaded the “snapshot”. And found @font-face messed up beyond diagnosis. A bug report is besides the point. You’ve got an infestation. I provided a solid test page. Something along the lines that a browser company working on an @font-face implementation must surely already have if you’re going to measure conformance.
And I notice you haven’t taken substantive issue with anything I’ve said in my “rant and rave”.
I like Opera, I want my code to work in it. It’s holding me and other web developers back.
Seriously.
Snapshot has another meaning? Whatever gave you that idea? It has the meaning it has. It’s a build released for testing.
If you want people to discuss anything of substance in your posts, maybe you should focus more on substance, and less on flaming and trolling?
Strange… I take it that Fx3.6 is the reference that other browsers have to compare with. Keeping that in mind I really do not understand what the problem is: I’m using Vista and the testpage looks good on O10.50 – almost the same as on Fx3.6 aside from the synthesized parts. Out of the 30 lines of text to compare, Opera breaks 3, IE8 breaks 27, Chrome4 breaks 21. So where is all the hatred coming from? 3 lines wrong in a pre-alpha snapshot?
I was using @font-face on my blog for a while. The only browser breaking up was (surprise!) Firefox, due to “security resctrictions”. A lame excuse, imho.
@David
Sorry to have released your post so late. It slipped by me.
All I can say is that I don’t know what you’re talking about.
Opera 10.5 renders what should be the “Regular” font as Bold Italic. IE, Chrome, FF, and Safari render it correctly. If displaying Bold Italic instead of Regular is no problem for you, then it’s no problem for me.
And there is no hatred. The day I start wasting my hatred on browser bugs is the day I hang it up.
Regards,
Rich
Hi guys,
I recently get into @font-face through Nice Web Type article and I am enjoying it, even with IE boilerplates and Opera bugs (btw, thx Paul Irish, your article really rox).
Anyway, I was using Opera 10.50 on Windows XP machine, and my surprise was when I get to Opera problem/workaround page I saw both working fine.
After some search about when Opera fixed the problem, I arrived in this post and took a look into your test page (very nice, dude, very nice). I could see it seems not fixed. In FF 3.6 it renders well and in Safari 4.0.5 it looks kinda weird (synthesized italics looks more lean than the true italics).
But I went a little bit further and looked into the source-codes. And here is where I got tricked. In my understanding, Opera guys states they fixed one problem, and you seem to be testing another principle.
Let me explain. Before, if you declare the same family, importing two different files, let’s say one normal and one italic, assert the same font-family to them, and make the difference using the attribute font-style into the respective @font-face, it didn’t work. You need to declare different font-family names, in order to get Opera working to use the correct fonts and so forth. This is bad, I agree.
But now, with Opera 10.50 you can do that – you did that in your test page in the “true” lines. So, for me, the bug is fixed.
The problem, or the advantage Opera does not have in comparison to other browsers is: it does not dinamically render the fonts.
The wrong lines in your test set were declared with the control font. You just imported one regular font, and used them declaring bold or italic, expecting the browser to render those styles itself, without any reference (this explains why Safari rendered them different).
This is a band-width saver feature that Opera lacks, but not something I can consider a bug. More than that, letting the browser render styles based into a base-font does not seems fair enough, hence it can or cannot render it propely as expected when importing a proper file.
Well, that’s it pal. And thanks again for this page.
@davis
The Opera guys are working on the problem you describe which is synthesizing bold and italic and bold italic from the regular font. The other browsers do it – but as you mentioned regarding Safari, it is not standardized.
See this for the particulars:
Opera 10.5 Beta Comes Through
Also, it appears that Opera still has problems with the fallback font stack when @font-face is used.
See:
http://www.zeldman.com/2010/04/11/opera-hates-my-web-font/
http://www.zeldman.com/2010/04/13/opera-loves-my-web-font/
Regards,
Rich