Font rasterization techniques [LWN.net]

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 this that 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)

Font rasterization techniques

Posted Sep 24, 2007 23:44 UTC (Mon) by quotemstr (subscriber, #45331) [Link]

I don't see why a browser has to snap glyphs to a pixel grid. Why can't it just render the text like any other application would? If you really do need pixel-level precision (say, a span with a mouseover effect), you can just use a pixel-level approximation for that purpose. The text rendering itself can still use subpixel positioning.

Also, "colouring the fringes of fonts" isn't mutually exclusive with the article's proposed technique. I don't think you fully understood the article. Sub-pixel rendering, the "colouring the fringes," is just one kind of anti-aliasing. It gives you a higher effective resolution on an LCD monitor, but there's no reason the author's technique wouldn't work with conventional antialiasing too.

I'm with you when it comes to gamma correction though; it'd be nice for that to be implemented consistently and correctly throughout the OS. (Though I don't see why you couldn't use a 256*256 lookup table for the blending instead of on-the-fly exponentiation).

As for the benefits: I, and I suspect most people reading this, spend a great deal of time reading computer displays.

Font rasterization techniques

Posted Sep 25, 2007 10:42 UTC (Tue) by alankila (subscriber, #47141) [Link]

> I don't see why a browser has to snap glyphs to a pixel grid.

I didn't really say it would have to. All I said was that HTML *elements* (tags) probably have to. When I talked about in-word snapping, I meant for HTML like this. As to whether elements could be positioned with finer than pixel granularity, it'll likely take a long time, if ever, before that happens.

> Also, "colouring the fringes of fonts" isn't mutually exclusive with the
> article's proposed technique. I don't think you fully understood the
> article. Sub-pixel rendering, the "colouring the fringes," is just
> one kind of anti-aliasing. It gives you a higher effective resolution on an
> LCD monitor, but there's no reason the author's technique wouldn't work
> with conventional antialiasing too.

On this point you are absolutely correct. Subpixel rendering isn't really the focus of the article. It is the focus for me, because I hunger for higher DPI displays, and subpixels have a chance to triple the value in one direction. I confess I have not read the article for months, but I did read it attentively back then and even ran his wine binaries showing the alternative font rendering.

However, in the context I used the phrase you quoted above, I was actually talking about the fact that a lot of work is required before Linux font support raises to the level of the other two operating systems. The "cleartype rendering" is generally taken to be the highest quality rendering, and on Linux we have xft or freetype producing coloured glyphs, but haven't done the required job in the other parts of the system. I started my comment with a desire to simply highlight the issues that are wrong in Linux font rendering currently.

> As for the benefits: I, and I suspect most people reading this, spend a
> great deal of time reading computer displays.

Yes, but I suspect for most people the rendering is already good enough. The subtle benefit in correct gamma blending for instance isn't likely to woo a lot of people over, if the cost is noticeably slower display updates. As to using 256*256 lookup table, sure it's possible. But if it has to be done by the CPU, then it's still replacing something that there probably exists MMX/SSE instructions for with something that goes much slower.

There's also the minor issue that if you do a repeated blendings, errors inherent in constantly quantizing to 8-bit become apparent. Ideally, one would render everything to a gamma 1.0 off-screen 16-bit per color channel canvas, and periodically render snapshots of that to screen...