The "wobblies" are probably due to bad or non-existent hinting...

Yes, the problem is with the font... Like Nick says, it is missing the hinting needed to render properly in Windows. You can download an auto-hinted @font-face kit from us here:

http://www.fontsquirrel.com/fonts/Linux-Libertine

Hi Ethan, that's precisely where I downloaded the kit from!

In some more testing, I found that the "U" is appearing at the same size at 14px and 15px. So when the type is set at 14px, it all looks wobbly. Oddly, as well, the clipped tails go away when not on 14px, too!

What browser are you using?

Browser? Font? Hinting? This is a "marketing problem". Someone took a font not designed or engineered for "web text" put it in a bin that said "web text" and voilá, instant support issue.

Cheers!

Not a problem if the face is TRUE "to an authentic feeling of Caslon" :-)

Not a problem if the face is TRUE "to an authentic feeling of Caslon" :-)

That’s one way to market unhinted fonts!

Linux Libertine is available in TrueType format with TrueType instructions, at least this what its website says: http://www.linuxlibertine.org/index.php?id=88&L=1 (the bottom of the page), so I wonder why you are using an auto-hinted version?

DB>Browser? Font? Hinting? This is a "marketing problem".

Uh, wrong. It's a "fun" problem!

@devi

The clipped lowercase "g" might be due to an absence of a line-height setting in the CSS. Does the g get clipped like that without another line of text underneath?

The spacing also looks extremely tight and I'm wondering why.

The problem with the capital "U" is the hinting. How does it look in, say, Chrome as an CFF? Same thing? Or is it just TrueType?

rich

@tevih - I KNEW you were going to say that. The autohinting definitely works better on some fonts than others. At such small sizes though, not many fonts are going to look good in Windows without a lot of man-hours hand-hinting them.

@Khaled - Interesting. I will try to integrate that hinted version into our system.

@David - One man's trash is another man's treasure I guess. I know you've invested your life into this... but when will you be delivering the goods? I've seen some of the screen-font work you've done and it is impressive. We're all standing by though waiting for webtype.com to show us how it is done.

@ Richard

A CSS line-height setting is not required. Fortunately, because I assume, that there is still a problem with Firefox! (Firefox spreads out the line height differently in case of units like em and pt, because they have to be converted to pixel. The values have to be rounded, but Firefox rounds up and down in the same text block with the result, that some lines are 1 px higher than others. I see this at once and I hate this behavior of Firefox. I am not sure, if it is meanwhile fixed.)

I assume there is something wrong with the dimensions of the font. Some values are wrong chosen. (Not all programs make use of the same values! On Windows there is nothing clipped in the font preview.)

@ Richard

Out off topic, but here you can hopefully see the Firefox leading bug (caused by line-height).

@arno
Thanks for the info on FF's line height issues.
(How come, in browsers, the simplest things are so hard?) :)

rich

How come, in browsers, the simplest things are so hard?

Clearly you haven’t known many F/OSS developers ;)

Indeed the webfonts sometimes get "Wobbly". Its worst if you have a transform rotate CSS propriety on. I think that its not especially due to the low font quality as much as is a browser misbehavior. Try to do see the page in an WebKit browser like Safari or Chrome. Their font rendering engine is better. Line-height, even with negative values, do not cause "clipped tail".

Does anyone know if installing GDI++ to disable ClearType and mimic OS X rendering, will give better rendering with @font-face?

Perhaps I could just go ahead and try it..