Xft subpixel rendering patch

[John Coiner]

Keith Packard wrote:
> I do remain a bit shy about using an inter pixel filter in Xft as it
> will break simplistic character cell applications like xterm

Keith, thanks for your feedback.

You know something funny? I was going to use xterm as one of my test 
programs -- but TrueType font rendering in xterm seems to be broken, 
with or without my patch, and with or without subpixel rendering.

I don't have time to debug it now... but you can see the symptom:

   http://people.brandeis.edu/~jcoiner/subpixel/xterm.png

This was the result of the command:

   xterm -fa 'Times New Roman:11'

> However, the suggested filter appears to blur the edges of vertical
> stems and produce color fringes there. An important piece of the current
> filter is that it doesn't do this, taking advantage of the sharp edges
> available at pixel boundaries to provide better glyph definition.

That's true, the current Xft filter yields very sharp stems. The 
trade-off is that stems are coerced to pixel boundaries -- but who 
cares, that doesn't impact readability too much.

I got to messing with the filter after changing from antialiasing to 
monochrome rendering. The current filter doesn't work as well on text 
that was rendered to 3 monochrome subpixels per whole pixel -- stems 
were OK, and non-stem features were rainbow-colored.

The 6-micropixel filter in the patch does blur the edges of stems. So do 
Apple and Microsoft. People may prefer text that has uniformly soft 
edges over text that mixes sharp-edged stems with soft-edged 
everything-else. (When I first observed that Xft output appeared "washed 
out", this juxtaposition of sharp and blurry features was probably 
contributing.)

With the patch, stems appear black and white at viewing distance, 
despite the color fringes.

Psychological tangent: I just switched back to Linux after having to use 
Windows for a year, on an identical LCD. I was psyched about freetype 
and Xft, so I read up, set it up, and ... was disappointed. Windows 
looked better. I set out to fix things. A cynic would say that my 
"better" is whatever I was used to -- whatever Windows does. So either 
the patch improves Xft LCD support to the same quality as Windows -- or 
it moves Xft laterally so that it is a half-ass'd copy of everyone's 
favorite collection of mouse drivers.

Either way, the patch is a decent fake of popular desktop OSes.

 > One possibility would be to expose the filter constants in the font
 > configuration mechanism and let people explore this space on their own

The topology of the render-and-filter pipeline is more influential over 
the final result than the filter constants for any given topology. The 
important variables are:

   * monochrome rendering vs. antialiasing
   * number of micropixels per whole pixel
   * inter-pixel vs. intra-pixel filter
   * linear vs. non-linear filters

All those variables leave a pretty big space to explore. That's 
especially true if you look at nonlinear filters, where you are varying 
more than weights -- you are varying the code. How to manage that? I 
know: we let users embed a bytecode string in their fonts.conf, which 
implements a filtering routine. The bytecode interpreter will be 
ambiguously specified and patent-encumbered. A cinch!

Just kidding... ;)

Thanks,

John