[Fontconfig] Greatly improved subpixel filtering in Xft
anders at kaseorg.com
Fri May 7 11:35:18 EST 2004
Keith Packard wrote:
> Perhaps, but I would hope most users can use the bytecode interpreter,
> which means that the current filter would be a better default. Throwing
> away the carefully constructed outlines produced by the bytecode
> interpreter is a huge waste.
As I'm sure you know, many users might not be legally allowed to use the
bytecode interpreter... Don't tell Apple, but I did some tests with
bytecode-enabled Freetype, on some of Microsoft's TrueType fonts, to see
what kind of differences we're talking about:
I still think my filter is an improvement, but even if you consider this
to be a worst case--do you really think I'm "throwing away the
outlines," and the difference really great enough to warrant defaulting
to a filter that produces output nearly equivalent to grayscale for
heavily hinted text, and bad color artifacts in all other cases?
If you still think so, fine, but I hope that I've at least convinced you
that making the filter configurable is worthwhile. Should I try to do that?
> Yes, so we'd have to adjust the bounding box to cover the expanded pixels
> touched by the filtered output.
Oh, I thought I already am, by adjusting left/right (or bottom/top, for
vertical subpixels), which get propogated to the metrics. Am I missing
> This may be a problem for terminal
> emulators which assume that glyphs don't ever overlap, and other
> applications which assume that adjacent lines of text don't overlap.
Monospace fonts get clipped to a box anyway by the current code. I've
had no problems except that GTK underline bug, which is hardly noticable
and could be fixed in GTK by using the offsets instead of the bounding
box (again, Mozilla gets it right). I even tested with a pathologically
wide 5 pixel blurring filter in all four subpixel layouts (okay, maybe
that constitutes throwing away the outlines :-)).
More information about the Fontconfig