@Font-Face Worsens In Opera 10.5 Beta, But Honestly, It’s OK

Feb 14, 2010

As I reported only two posts ago, @font-face support in Opera’s 10.5 Pre-Alpha release was awful. But when I saw that Opera had released 10.5 Beta my pulse raced. Did they fix it? I clicked “Download” and then, in an adrenalin rush, I raced over to the Opera Developer blog in search of information. There, all hope was lost.

Regressed Regressed Regressed Regressed Regressed

@Font-Face in 10.5 Beta was worse!

Andreas Bovens writes:

One caveat: I recently blogged about improved Web Fonts support in our pre-beta snapshots, but for the beta release, this has unfortunately regressed again. Web Fonts work under certain circumstances, but break in others. Don’t let this spoil the fun though — our devs are working on a fix.

I could show you screen shots, but I’d probably have to remove them: some readers might find them too upsetting.

When I did network consulting on Wall Street, I remember a trading floor where one of the managers used to pace around behind his group of about 16 traders while slapping the fat end of a baseball bat against his palm. Boy, those traders were focused. I betcha they could get @font-face right. Now, I am tempted to fly to Norway with a baseball bat but instead I’ve decided to offer a reward.

Here it is: if the next release of Opera has a decent implementation of @font-face, Andreas Bovens gets a $100 Amazon gift card from Readable Web. If it doesn’t, the entire Opera development team will get a set of steak knives as a consolation prize and bitter reminder. (With a grateful nod to David Mamet for the idea of the steak knives.)
Fair deal? Don’t let Andreas down, now!

Attention Opera Devs:
Fix @Font-Face And Help Andreas Get His $100 Gift Card!

Related Articles:

  1. @Font-Face News: Opera 10.5 Beta2 Comes Through!
  2. @Font-Face In Opera 10.5 Pre-Alpha Stinks, Despite “Snapshot” Hype
  3. @Font-Face Works Automatically In New Google Chrome Beta
  4. Opera Admits @Font-Face Bugs In Opera 10

Sharing Options:

{ 7 comments… read them below or add one }

dan bloom February 15, 2010 at 6:10 pm

Richard

Hear ye, hear ye, Juneau Empire prints my oped today on snailpapers, your reax and POV, pro or con?

Danny

dan bloom February 15, 2010 at 6:11 pm

click on my name to see LINK

James John Malcolm February 25, 2010 at 3:05 am

I’ve run into the same problems with Opera 10.x as you have (funnily enough while creating a design for an opera-sponsored event). In my testing Opera 10.5b (on mac) has improved slightly over 10.5a (and certainly over 10.10). I’m miffed they’ve added ligature support before proper family support.

I’d love to hear your comments on my browser support table: http://james.gameover.com/index.php/2010/css3-font-face-browser-support-table/
I’d be especially interested in extending it with IE’s results.

Richard Fink February 25, 2010 at 8:15 am

Hi James,
I came upon your post and test pages awhile ago with a promise to myself to double-back and analyze because I was having a little trouble following the methodology. Probably my fault, not yours. I will take a close look though, and repro using EOTs and check your results. I can tell you that with a four member font family, IE synthesizes Bold, Italic, and Bold Italic, exactly as you would expect – from the regular/normal font of the family, not from a fallback font.
I also know from applying @font-face to this blog that it will synthesize “Small Caps”. (For example, the heading “Recent Posts” uses font variant and IE handles it OK. Chrome, for example doesn’t.)
I’d be interested to know why your tests didn’t include IE – what were the barriers to testing? Was it file conversion?

James John Malcolm February 25, 2010 at 3:35 pm

Hi Richard,
Good to hear about IE synthesizing fonts properly. IE not being included in my results is primarily due to my lack of time and the limited availability of IE on my machine (convert to eot, boot into windows, run IE tester, etc.).

The methodology is simple. The test case is made up of 3x the same text. Nr. 1 has a font file assigned to each member in the family (myfont-bold.ttf to font-weight:bold), Nr. 2 has a font file assigned to the regular member of the family and Nr. 3 has simply Georgia (&Serif) defined because it’s so different from Fontin Sans. The fallback font for Nr. 1 and 2 is also Georgia to make clear when fallback is happening.

The optimal results should show nr. 1, 2 and 3 all matching each other in terms of text styles (what’s bold italic in one should be bold italic in the other). Nr. 1 and 2 should match each other quite closely, although small differences are allowed as the browsers have to guesstimate all the other weights and styles.

The resulting support table is just a summary of all the screenshots. If you have a screenshot of IEs rendering, it’d be very welcome.

Richard Fink February 27, 2010 at 4:51 pm

James,
Thanks. I’ll catch up with your work ASAP. Might be a few weeks though, realistically.
However, I’ll try to get you any IE screenshots I can, sooner.
BTW – do you have any free time to spare for additional testing outside the sphere of synthesized text? Do you intend to expand your investigations of @font-face support?
Help is always needed. And input on related typographical stuff.
Let me know.
(Don’t think I have an email address for you, either.)

Rich

James John Malcolm March 1, 2010 at 3:58 am

Thanks – I’ve got more time in a few weeks, so that’s fine. Synthesized text is the biggy for me as it represents how well fallback will work. (I’m thinking about font-weight:number; it’s a natural extension, but probably of limited use.) What other @font-face support would you like to have tested?

Mail address should be in your cms, attached to the comment.

Leave a Comment

Previous post:

Next post: