FreeType 2.6.2 ships with three interesting details for users and developers of rendering libraries that deal with - text.
- - -
-
- 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. 2015-12-07: 3rd revision: Proof-read by Graham Asher.This worked out well so far, Ubuntu has been using this
setting for every font for years now. Werner Lemberg is
- adding support for more and more scripts and even spun off
+ adding support for more and more scripts and has also spun off
the code
into ttfautohint,
to help font designers ease the pain of manual
@@ -204,7 +142,7 @@
sound because the native hinting mechanics for Postscript
(.pfa, .pfb), TrueType
(.ttf) and OpenType/CFF (.otf)
- were … subpar for the longest time. The PostScript
+ were subpar for the longest time. The PostScript
hinter still is, but with Adobe's high-quality
OpenType/CFF engine contributed to FreeType and recent
advances of the TrueType driver towards full ClearType
@@ -215,7 +153,7 @@
auto-hinter before and has now been changed to mean
“Use native vertical-grid-only-snapping if driver
and font supports it and vertical-grid-only auto-hinter
- otherwise.” Right now, only the OpenType/CFF driver
+ otherwise”. Right now, only the OpenType/CFF driver
is supported. In the future, this will hopefully include
the TrueType engine once full support for ClearType
arrives.
Stem darkening emboldens glyphs at smaller sizes to make
them more readable on common low-DPI screens. If this
sounds familiar to you, that's because Adobe's CFF engine
- has been doing it since it has been contributed in 2013.
+ has been doing it since it was contributed in 2013.
You might have noticed that OpenType/CFF fonts (commonly
suffixed .otf) like GNOME 3's default UI
font Cantarell
@@ -262,15 +199,15 @@
this release. The auto-hinter can do the exact same thing
now, it is just disabled by default.
- But why would you do this if small glyphs have been - fairly readable already? It turns out that font rendering - in the Linux ecosystem has been done wrong since scalable +
But why would you do this if small glyphs are already + fairly readable? It turns out that font rendering + in the Linux ecosystem has been wrong since scalable fonts were introduced to it. Text must be rendered with linear alpha blending and gamma correction, which no toolkit or rendering library do by default on X11, even though Qt5 - and Skia (as used Google + and Skia (as used by Google Chrome and other browsers) can do it.
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 @@ -328,16 +265,9 @@ Skia can and will do it on other platforms. Windows and Mac OS X do it natively. This procedure is especially important if glyphs should be subpixel-rendered - (ClearType and Mac OS X!) + (ClearType and Mac OS X) with as - little color-fringing as possible.
- - -
-
- We want to get to ‘Gamma 1.8, darkened’. - Note how it is the cleanest rendering of all.
+ few color fringes as possible.
+
+ "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 it should always be done.
+
+ The autohinter has a new toggleable 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 +
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.
+
+ 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 fringes. For + this reason it is necessary to filter a subpixel-rendered + glyph to reduce those color fringes 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 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 + Unix-like operating systems 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 screen gamma + (viewing angles) and rendering systems without linear + alpha blending. Note that color fringes 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