Xft subpixel rendering patch
jcoiner at stanfordalumni.org
Sun Aug 28 19:52:41 PDT 2005
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:
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
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... ;)
More information about the xorg