The difference is pretty clear in Google Chrome 6.0.447.0 dev (screenshot from my machine: http://i46.tinypic.com/t67ckx.jpg). The text/kerning treated with optimizeLegibility is slightly more compact.
Admittedly, at this point, I do not see it being terribly useful.
You _can_ see the difference in both Chrome and Safari for Windows. Other platforms, not so much. Firefox for Windows has slightly different logic, where optimizeLegibility is on by default for sizes 20px and over, off by default for smaller text, but still settable (see MDC article on text-rendering).
Great tip okonomiyaki3000 – I was about to post that as well. Only works in Chrome/Windows, but it does make a big difference.
On a different note, for those in a Mac using a webkit browser, I have found adding “-webkit-font-smoothing:antialiased;” improves the rendering as well.
For those confused about what this does: it’s a proprietary (non-standard) CSS declaration that looks for any ligatures in the font currently in use, and applies them at certain font sizes. Here’s a noticeable example, a screenshot taken in Chrome: http://cl.ly/6063f079fe74a76ec817
@okonomiyaki3000, @Jonny: the text-shadow rule does enable anti-aliasing, but it disables ClearType (if the user is using it). So you go from sub-pixel anti-aliasing to full-pixel anti-aliasing, which is not as good.
@Jonny – I observed this using Chrome on Windows 7 (not over remote desktop, and only on a flat panel monitor). Look at the pixels up close (maybe with a magnifying glass if your dot pitch is high) — cleartype does subpixel anti-aliasing. When you use the text-shadow rule it seems that Chrome takes over the text rendering and applies full-pixel anti-aliasing, which to me is not as precise.
Six months back, jxegrd asked this question that I regrettably saw only today:
‘Does anyone know if the performance impact of optimizeLegibility vs optimizeSpeed has been benchmarked/researched? Just curious.’
The proof that there is no significant performance difference between the two is illustrated by the following web site: http://LovataSinhala.com
The majority of letters. you see are ligatures. The behavior under geometricPrecision is also the same.
This site is entirely in Sinhala that uses a font that has 2200 ligatures. (English has only 5). You can verify this by copying the text into an editor and counting the glyphs of the Sinhala font and the Latin text it actually represents.
This text is really transliterated Sinhala, shown by making Latin letters look like Sinhala letters. Then there are these ligatures that make even more complex letters sometimes in multiple steps. The Sinhala font is downloaded in WOFF format.
Sinhala script is the most complex of all Indic. It covers Sinhala (simplest), Sanskrit (more complex) and Pali (Entirely an additional set of ligatures). The font makes the ligatures by default (if the application understands). There are situations that you have a Sinhala word that looks odd with too much of combining. In those situations, I typed ZWNJ to prevent the joint.
I think restricting the ligature formation in Firefox to above 20px is only to compete with Chrome for speed. Actually Chrome shows speed by caching the pages. If you are a developer like me, Chrome does not show updates of pages as soon as you make them. It simply picks the old copy from memory!
Now in Chromium 9.0.597.83, I see difference. I was sure most browsers use kerning by default. So was it disabled, or less accurate/precise? Kerning (ligatures maybe slightly more) is quite simple process and do not increase algorithm time. Why anybody would disable it on the first place?
I actually tested it now in Chromium 9.0.597.83, and optimizeLegiblity indeed enables ligatures, but kerning is still disabled. Strange, as in Epiphany-webkit, is difference both in ligatures and kerning (normally off). Same fonts. System is Linux.
In fact in Firefox 4.0 I see kerning and ligatures enabled by default. Nice.