diff --git a/index.html b/index.html index c92d541..e4493a0 100644 --- a/index.html +++ b/index.html @@ -106,71 +106,9 @@

FreeType 2.6.2 ships with three interesting details for users and developers of rendering libraries that deal with - text.

- - -
The default LCD filter for subpixel rendering has been - changed
- - - Comparison of the old and new filter. - -

When you look at subpixel-rendered text, no matter - whether it is on some kind of Unix, Windows, or Mac - OS X, you might notice that it is slightly colored. - Using subpixel rendering on LCD panels is a trade-off; you - get three times higher resolution in the direction of the - pixel-substripe (usually horizontal RGB) in exchange for - color artifacts, also called color fringing. For - this reason it is necessary to filter a subpixel-rendered - glyph to reduce those color-fringing before putting it - somewhere on the screen. The filter distributes the - values of a subpixel to its neighbors, sacrificing some of - the higher resolution and making the resulting glyph image - blurrier – but the positioning improvement remains! The - ideal filter for you depends on your screen (gamma - curves!), the capabilities of the used rendering system - (linear alpha blending and gamma correction!), your vision - and your taste, probably in that order.

- -

A filter should have two properties: it should be - normalized, meaning the values used in the filter should - sum up to a figurative 1 (here: 0x100 or 256) and it - should be color-balanced, meaning that values for one - subpixel are equally distributed to all other subpixels of - a pixel to sacrifice some of the higher resolution to - drastically reduce color-fringes.

- -

Previously, FreeType's default LCD filter was neither - normalized nor color-balanced. That was a deliberate - choice because there is still no rendering system on - *nixes that does linear alpha blending and gamma - correction by default to render glyphs correctly. Going - above a filter sum of 1 increased contrast somewhat - at the expense of slight distortions and increased - color-fringing, so this can be seen as a hack. You might - have noticed that thumbnails in various places on your - computer that show text could be quite colorful. Now you - know why.

- -

The new default filter is both normalized and - color-balanced. It is indeed ever so slightly blurrier - than the previous default one, but also lacks its - harshness and is less color-happy. The blurriness also - means higher tolerance for non-ideal gamma of screens - (viewing angles!) and rendering systems without linear - alpha blending. Note that color-fringing can only be - really minimized when the rendering system will do linear - alpha blending of text.

- -

The ‘light’ filter that has accompanied the - default one for so long stays unchanged: it already is - normalized and color-balanced. It is sharper than the - default one but less tolerant of uncalibrated screens and - rendering systems without linear alpha blending, producing - more color-fringes.

- + text. This is the 2nd revision of my post, done on 2015-12-06. + I reorganized the headings and tried to better explain the blending + examples.

(S)light hinting will invoke the native hinter if possible
@@ -243,8 +181,7 @@ one, as Ubuntu has proven over the years.

-
Stem darkening for the auto-hinter (disabled by default), also - disabling stem darkening for the OpenType/CFF driver
+
Experimental: Stem darkening for the auto-hinter

This is relevant because all our screens have a second - problem: they are not linear. 1 + 1 is + problem: they are not linear. 1 + 1 is not 2. Twice the value does not result in twice the brightness. When a pixel is only 50% covered, the coverage map says 50% black, and this translates to a @@ -332,13 +269,6 @@ with as little color-fringing as possible.

- - Comparison of different ways of blending. - -

We want to get to ‘Gamma 1.8, darkened’. - Note how it is the cleanest rendering of all.

-
Back to stem darkening.

Assume we render fonts correctly. Gamma correction @@ -358,20 +288,49 @@ prevents ‘thinning out’ of glyphs. Text remains readable at smaller sizes.

+ + Comparison of different ways of blending. + +

"Gamma 1.0" shows what happens when you take a grayscale coverage + bitmap from FreeType and blend it onto a surface in linear space. + Black-on-white is heavier than white-on-black and red-on-green has + dark halos or ‘dirt’ around it. Note that this picture is unrealistic + in the sense that no rendering system on X11 does linear alpha + blending, so imagine something worse. “Gamma 1.8” is the + result of linear alpha blending and gamma correction. It is + much better, but text ‘thins out’, making it harder to read. Adding + stem darkening gets us to “Gamma 1.8, darkened”. Note how it's the + cleanest rendering of all. “Gamma 1.0, darkened”, meaning linear + alpha blending without gamma correction but with stem darkening, + exaggerates the effects of “Gamma 1.0”. Stem darkening should only be + enabled when doing gamma correction, so ideally always ;)

+ Waterfall comparison of non-emboldening and emboldening autohinter. +

The autohinter has a new toggable stem darkening property that + works like the stem darkener in Adobe's CFF engine. Note how it makes + text slightly bolder with the default parameters, down to small pixel + sizes. Gamma correction active to demonstrate the ‘thinning out’ of + text especially at smaller pixel sizes with lots of gray pixels.

And that is the story behind this feature.

-

It is disabled by default because no library supports - linear alpha blending and gamma correction out of the box. - Existing libraries will get the same glyphs they have - always gotten. Qt5 actually had gamma correction enabled +

Disabled stem darkening for the autohinter and Adobe's CFF (.otf) engine
+ +

No library supports linear alpha blending and gamma correction out + of the box on X11. Turning on stem darkening leads to heavy and fuzzy + looking glyphs as in “Gamma 1.0, darkened” above, so it's + better to disable it.

+ +

Qt5 actually had gamma correction enabled for a short while until someone complained that text was too light and unlike rendering in other toolkits, so the maintainers disabled it for the XCB-backend. Skia (Chrome) can do - gamma-correction, but turns it off for X11. I see the - this feature as a technology preview for playing around + gamma-correction, but turns it off for X11.

+ +

I see autohinter stem + darkening as a technology preview for playing around with until we get stem darkening generic within FreeType. The plan is to provide it for all font drivers and make it toggable per FT_Library just like @@ -386,6 +345,68 @@ no longer heavy and fuzzy. Slight hinting will result in consistent font rendering.

+
The default LCD filter for subpixel rendering has been + changed
+ + + Comparison of the old and new filter. + +

When you look at subpixel-rendered text, no matter + whether it is on some kind of Unix, Windows, or Mac + OS X, you might notice that it is slightly colored. + Using subpixel rendering on LCD panels is a trade-off; you + get three times higher resolution in the direction of the + pixel-substripe (usually horizontal RGB) in exchange for + color artifacts, also called color fringing. For + this reason it is necessary to filter a subpixel-rendered + glyph to reduce those color-fringing before putting it + somewhere on the screen. The filter distributes the + values of a subpixel to its neighbors, sacrificing some of + the higher resolution and making the resulting glyph image + blurrier – but the positioning improvement remains! The + ideal filter for you depends on your screen (gamma + curves!), the capabilities of the used rendering system + (linear alpha blending and gamma correction!), your vision + and your taste, probably in that order.

+ +

A filter should have two properties: it should be + normalized, meaning the values used in the filter should + sum up to a figurative 1 (here: 0x100 or 256) and it + should be color-balanced, meaning that values for one + subpixel are equally distributed to all other subpixels of + a pixel to sacrifice some of the higher resolution to + drastically reduce color-fringes.

+ +

Previously, FreeType's default LCD filter was neither + normalized nor color-balanced. That was a deliberate + choice because there is still no rendering system on + *nixes that does linear alpha blending and gamma + correction by default to render glyphs correctly. Going + above a filter sum of 1 increased contrast somewhat + at the expense of slight distortions and increased + color-fringing, so this can be seen as a hack. You might + have noticed that thumbnails in various places on your + computer that show text could be quite colorful. Now you + know why.

+ +

The new default filter is both normalized and + color-balanced. It is indeed ever so slightly blurrier + than the previous default one, but also lacks its + harshness and is less color-happy. The blurriness also + means higher tolerance for non-ideal gamma of screens + (viewing angles!) and rendering systems without linear + alpha blending. Note that color-fringing can only be + really minimized when the rendering system will do linear + alpha blending of text.

+ +

The ‘light’ filter that has accompanied the + default one for so long stays unchanged: it already is + normalized and color-balanced. It is sharper than the + default one but less tolerant of uncalibrated screens and + rendering systems without linear alpha blending, producing + more color-fringes.

+

[1] This process can cost performance. There is an approximation that does not need to know about the background