Friday, July 2nd, 2010

text-rendering: optimizeLegibility; //Can you read me now?

Category: Typography

text-rendering: optimizeLegibility;.


Posted by Dion Almaer at 6:27 am

3.2 rating from 5 votes


Comments feed TrackBack URI


Seriously – what does it do?

Example page is just as vague. No differences observed in chrome & safari 5 for windows.

Comment by ProPuke — July 2, 2010

same here…no difference in Chrome…

Comment by darktalker — July 2, 2010

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.

Comment by joolss — July 2, 2010

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?

Comment by ProPuke — July 2, 2010

No difference in Firefox 3.6 on Windows….

Comment by wukfit — July 2, 2010

I can’t see any difference with either Chrome or Firefox either … Chrome renders all text ugly, Firefox all text beautiful.

Comment by hansschmucker — July 2, 2010

The difference is pretty clear in Google Chrome 6.0.447.0 dev (screenshot from my machine: The text/kerning treated with optimizeLegibility is slightly more compact.

Admittedly, at this point, I do not see it being terribly useful.

Comment by MadManMoon — July 2, 2010

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”

Comment by okonomiyaki3000 — July 2, 2010

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).

Comment by raphlinus — July 2, 2010

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+.

Comment by hansschmucker — July 2, 2010

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.

Comment by Jonny — July 2, 2010

If you use Safari 5, I threw together a quick Extension that enables this on all sites:


Comment by inxilpro — July 2, 2010

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: (I have DejaVu Serif)

Comment by jxegrd — July 2, 2010

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:

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:

Does anyone know if the performance impact of optimizeLegibility vs optimizeSpeed has been benchmarked/researched? Just curious.

Comment by jdbartlett — July 2, 2010

Very noticeable in Chrome 5.0.375.86 on Windows 7. Looks much nicer for the sans-serif fonts.

Comment by Trilibi — July 2, 2010

No difference in Chromium 6.0 under Linux. :/

Comment by movax — July 2, 2010

Does Freetype even suffer from the problem?

Comment by hansschmucker — July 2, 2010

@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.

Comment by pianoroy — July 6, 2010

@pianoroy Interesting. I’m running Windows 7 – and ClearType was enabled by default – and this method still helped. Am I missing something?

Comment by Jonny — July 6, 2010

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.

Comment by Joeri — July 6, 2010

@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.

Comment by pianoroy — July 7, 2010

@pianoroy Yeah, the differences are very minimal, but I did think it looked better. I did a little test, check it out here:

Comment by Jonny — July 7, 2010

second does look easier to read, definitely rocks on a news site, NYT etc.

Comment by johnantoni — July 9, 2010

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:
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!

Comment by ahangama — December 29, 2010

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:

Comment by ahangama — December 29, 2010

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.

Comment by movax — March 5, 2011

Leave a comment

You must be logged in to post a comment.