Font rasterization techniques
Posted Sep 24, 2007 23:13 UTC (Mon) by
alankila (subscriber, #47141)
Parent article:
Font rasterization techniques
The article is rather depressing because good font rendering is so complicated. Here's a bit of a summary where Linux needs work in.
Firstly, truetype hints. Microsoft fonts are apparently badly hinted for use with freetype, for instance the curve of 2 tends to vanish in times new roman or the diagonal stem at z. This is because the algorithms differ on the ways they handle thin areas (especially those that are reduced to just lines): microsoft version always renders them 1px wide, but freetype can make them vanish completely. This looks like an artifact.
For some fonts, therefore, it would seem that freetype would have to forget calculating areas for things that are too narrow and simply opt to render them at some minimum width. Of course, this only needs to be done for fonts intended for a different rendering engine from freetype, because fonts with freetype as target probably make use of this.
To properly blend the fonts against background, one should compensate for the gamma of the display. Doesn't seem likely to happen any time soon, this should probably land into X server or preferably GPU hardware. It's no good to gamma correct the ARGB pixmap generated by freetype because freetype doesn't know what kind of background it will be applied on, so it has to go into the blending step. It's a simple summation now; the gamma-correct path should perform linear blending in the physical intensity and needs fractional roots and exponentiation to do that (read: is slow).
If you highlight a piece of text with mouse, simple invertion of colours will not do, again because of gamma. Everything needs to be redrawn for the background.
Then there's the trouble with kerning and getting accurate advance widths for text. (The agg guy seems to suggest abolishing horizontal hinting completely for accurate representation of width. Well, that's good idea if you care about that sort of thing, but at the same go, you'll get lots of variants for every letter, making glyph pixmap caching more memory consuming... and if you don't do gamma correction right, these glyphs will not look even nearly identical because a pattern like 0x00 0xff has very different brightness from 0x80 0x80, although the average values for both patterns are the same. Yet you could naively get the latter from the former if you imagine that a pixel is shifted to left by half a pixel, and therefore occupies two slots equally. For a gamma 2.0 display, the correct brightness is approximately 0xb4.)
As an aside, most LCD screens seem to have horrible scalers because they ignore gamma issues, and as a result have noticeably different brightness for features that are modified by the scaling. Ideally, scaling only makes things blurrier but shouldn't affect pixel intensity. In practice, things often look darker when scaled. Across a wide range of shades, it seems that
LCD displays do not really have a constant gamma either, but it's often not very big deviation from some value such as 2.0.
Even worse, everything that needs to know the precise position of a glyph needs to become aware of the fractional positioning of everything. And it still won't be perfect. For instance, in a browser, all elements need to be snapped to pixel grid, so there's always going to be compromises, uneven spacing between words or even letters, etc. (Think <span>this</span> <span>that</span> etc.) I imagine fixing this means an avalance of api changes, and might even introduce incompatible things like elements that you can't hover on with mouse because they are narrower than 1 pixel and fall between the gaps.
All in all, subpixel rendering is much more complicated than just colouring the fringes of fonts. It touches *everything* on the system when properly done. And it absolutely needs all that gamma correction crap if you are serious about not ever wanting to see any fringes.
In conclusion: Here's to hoping that 200 dpi displays (and/or 16-bit gamma 1.0) screens or something come one day and solve the problem for us. I don't have much faith in that it will ever get properly solved by software.
To put it bluntly, the problem is too intricate to understand, depends on features not in user control (display gamma value, and its constantness), imposes performance penalties to all users (unless GPU vendors rush to implement gamma-corrected blending), and the benefits (beautiful font rendering) are in the end rather small.
(
Log in to post comments)