Font rasterization techniques

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

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 t<span>h</span>i<span>s</span>. 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 <b>rendering</b>, 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...