Thank you for bringing this to the attention of the Firefox team. I was going to write a similarly themed article, but nobody reads my blog so it wouldn’t have made much impact. :]

Right now I’m a bit reluctant to use @font-face with Firefox 3.5 simply because the font is always displayed too heavily. Kudos to the Firefox team for making progress with web fonts, but they can definitely borrow one from WebKit’s playbook here.

FF 3.5/Win is clipping some descenders in several Typekit fonts; I noticed this both in the Typekit admin and on the site I’ve been using it with. Firefox on the Mac has no trouble. Here’s a screenshot of Bello Pro in the Typekit admin.

Most of the issue I have with font rendering differences between FF and Safari come down to the OS.

Windows produces text that’s too thin and spidery a lot of the time. Safari on Windows can use either the OSX or Windows algorithms, and the OSX one’s produce clearly better characters. However, the situation reverses once you hit light text on dark backgrounds - where OSX produces vastly overweight characters and Windows looks far better.

My issue with FF’s text handling are actually issues with Window’s text handling - trying to use -moz-transform on text in a Windows environment results in incomprehensibly ugly and “broken” looking type, to the point where I simply won’t use it at all. Chrome on Windows looks just as shoddy, and so does Safari if you switch to the Windows text renderer.

Discrepancies in effects are a little annoying too, text-shadow is especially obvious with the -webkit and -moz varieties producing clearly different looks.

“trying to use -moz-transform on text in a Windows environment [on Firefox] results in incomprehensibly ugly and “broken” looking type, to the point where I simply won’t use it at all.”

@Matt Wilcox I would agree, some sort of combination of Firefox’s effects seemed to be destroying text rendering on Firefox, but I can’t figure out what it was exactly.

Chrome on Windows looks just as shoddy, and so does Safari if you switch to the Windows text renderer.

Not sure what you mean here because both Chrome and Safari look like they are rendering correctly on Windows here. The difference between Windows’ ClearType rendering strategy and the OS X text rendering strategy are apparent (ClearType more heavily hints text, forcing it to the pixel grid, which gives it a more crisp, if ‘thin’ appearance; OS X rendering does not hint giving it a less sharp appearance, but one that respects the shape of the glyph more closely), but I wouldn’t say either are ‘shoddy’. If you’re not accustomed to it, ClearType can look too thin, but, equally, if you’re not accustomed to OS X style (as seen in Safari on Win) rendering, it can look to fat and fuzzy. It’s mainly just a matter of perception and taste. As a general rule, I find discerning designers prefer Safari rendering, while ‘normal folk’ seem to prefer the crisp qualities of ClearType.

It’s a massively subjective issue, though, as illustrated in this article and the resulting comments.

Something to note is that Windows 7 has a new text rendering API called DirectWrite which produced something they call Natural ClearType. It sounds to me a lot like the Quartz way of doing things. Details here. From the demo I found here, that does indeed seem to be the case.

Something that has me particularly excited about DirectWrite is much better support for OpenType (see Font Art heading), which will allow contextual letterforms and the rest of the loveliness full OpenType support brings. More cool demos can be found in this video (16 minutes onwards).

So the question is, when are the browser-makers going to support DirectWrite?

Robert, does it support DirectWrite’s new sub-pixel rendering? This will not only yield much improved glyph rendering, but better animation and transform quality. See this video at 22 minutes onwards. It’s not looking like it is there on my Firefox 3.5 running on Windows 7 Release Candidate.

But it’s planned? (he says, fingers-crossed)