Friday, July 2nd, 2010
text-rendering: optimizeLegibility; //Can you read me now?
Category: Typography
Awesome.
Related Content:
- CMIO breaks down HIT challenges for provider ACO participation
Our latest Q & A features Northshore University HealthSystem CMIO Arnold Wagner, M.D., who explains the HIT aspects of ACO... - Read data from parallel port
2.7 rating from 3 votes
What?
Seriously – what does it do?
Example page is just as vague. No differences observed in chrome & safari 5 for windows.
same here…no difference in Chrome…
It’s only on Windows, Mac browsers have this enabled by default. You can see the difference on Chrome, in the distance between the A’s and V in “AVAST”. I e kerning.
I’m still waiting for text-rendering: useTheSameFontMetricsInAllBrowsers; , and then do my own kerning.
Are you sure? It doesn’t make any difference for me in windows, either.
They’re pixel identical in chrome (5.0.375.99)
I’m sorry to be the one to complain, but this is a p**s poor example of an article.
What is this setting? What does it do? What does it work in? When should we use it? When shouldn’t we?
No difference in Firefox 3.6 on Windows….
I can’t see any difference with either Chrome or Firefox either … Chrome renders all text ugly, Firefox all text beautiful.
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.
Here’s a neat trick to try in chrome for windows:
* { text-shadow: 0px 0px 1px rgba(0,0,0,0); }
It forces anti aliasing. Doesn’t do anything on Mac because Macs already render text properly. Cool thing about it is, it will even smooth asian fonts which seem to be immune to “Clear Type”
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).
Neat trick indeed (I’ve tried it with this:
javascript:var txt=document.createElement( ‘style’ );txt.appendChild( document.createTextNode(‘* { text-shadow: 0px 0px 1px rgba(0,0,0,0); }’));document.getElementsByTagName(‘head’)[0].appendChild(txt);void(0);
)
However, it doesn’t work too well on small fonts. Better try to limit it to 20px+.
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.
If you use Safari 5, I threw together a quick Extension that enables this on all sites:
http://cmorrell.com/misc/optimize-legibility-safari-5-810
Chris
Because of the font they use, I also don’t get any difference in Windows in any of the mentioned browsers. This works as advertised: https://developer.mozilla.org/en/CSS/text-rendering (I have DejaVu Serif)
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
Firefox and Webkit support this CSS declaration, though there may be some differences in behavior. Information on Firefox’s implementation is available at Mozilla Dev Center:
https://developer.mozilla.org/en/CSS/text-rendering
Does anyone know if the performance impact of optimizeLegibility vs optimizeSpeed has been benchmarked/researched? Just curious.
Very noticeable in Chrome 5.0.375.86 on Windows 7. Looks much nicer for the sans-serif fonts.
No difference in Chromium 6.0 under Linux. :/
Does Freetype even suffer from the problem?
@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.
@pianoroy Interesting. I’m running Windows 7 – and ClearType was enabled by default – and this method still helped. Am I missing something?
Define “helped”. Some people like the look of regular anti-aliasing to the look of cleartype, even if cleartype more accurately reproduces the shape of each character.
@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.
@pianoroy Yeah, the differences are very minimal, but I did think it looked better. I did a little test, check it out here: http://dl.dropbox.com/u/8770731/chrome-font-test.png
second does look easier to read, definitely rocks on a news site, NYT etc.
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!
I forgot to mention in the earlier comment that only recent versions of Firefox, Safari, Lunascape and Arora respond to the text-rendering CSS property. IE8 tries as well somewhat pathetically.
The PHP script that tests for the browser to advise which browsers could be used was removed from the following page to help testing:
http://www.lovatasinhala.com/test.php
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.