i tested it too.
i tested it in my computer and my friend’s computer, the same result, i dont’ think this is a big issue, but it make me feel not comfortable. i wish the opera team will soon fix it!

Is it possible to somehow share these (even without sharing the font file itself), so I can have a look at them and file the issues you mention?

The operlaps can be seen on my demo page:
http://opentype.info/demo/webfontdemo.html

The test of the different styles uses the free font family Delicious: http://www.josbuivenga.demon.nl/delicious.html
with numeric weight values and font-variant:small-caps.

PS – I also tested Opera 10b on OS X 10.3.9. @font-face works there as well. Kudo’s to Opera for pulling that one off.

(and yeah, I know @font-face is a very difficult thing to implement, particularly on Windows, having followed the gecko development of @font-face very closely).

Dustin is right when he says our support for @font-face is still a work-in-progress. Some features are not supported yet, and we’ll probably need to iron out a couple of bugs in our current implementation.

That being said, I’m interested in the source of the examples you feature in your post. Is it possible to somehow share these (even without sharing the font file itself), so I can have a look at them and file the issues you mention?

Opera’s error console aside from displaying javascript errors displays CSS errors as well. A quick glance at the error console would show you that specifying font-weight or font-style within an @font-face rule would produce an error, meaning that Opera doesn’t yet understand such within an @font-face rule. So, when you specified that the font needed to be a different weight as a property of whatever you were styling Opera attempted to pseudo-bold the typeface, resulting in the unreadable mess you experienced, including the double serifs and whatnot. It’s not the only bug its current implementation has either. Opera’s support is still a work-in-progress.

Your supposition on how long Opera has actually been working on @font-face support is incorrect as well. Håkon Lie did indeed make a public statement about it before Opera 9.5 was even released, but he’s made numerous statements about it, campaigning for web type for the better part of a decade. Just because a company’s CTO is badly wanting something doesn’t mean that the corporation will instantly drop what they’re doing and implement what he wants. I was one of the ones looking for it in Opera 9.5, but Opera didn’t intend on @font-face support until Opera 10.

Embedding type like this is extremely difficult thing to do, especially considering that platforms handle fonts differently from one another among other numerous and incredibly difficult hurdles. It’ll take time, and considering the changes between the first appearance of web fonts support in the alpha and now there’s going to be much better support by the time the final appears.

On another note I’d personally find local() to be the most important thing to implement after getting initial support working properly. It’s already supported by Safari, and it will be quite useful in reducing bandwidth in the event the CSS author specifies a local font as his/her preferred choice when embedding, only resulting to one specified on the server when the font isn’t available on the viewer’s machine. It will also be useful to the advanced end user, allowing the user to specify in user stylesheets overrides for irksome typefaces such as Arial or Comic Sans, forcing a local copy of say, Helvetica, to replace the two.