[Fontconfig] Greatly improved subpixel filtering in Xft

Keith Packard keithp at keithp.com
Fri May 7 09:17:10 EST 2004

Around 14 o'clock on May 6, Anders Kaseorg wrote:

> Fair enough. I think my filter is a better default though, since it is 
> much better for medium-hinted text, only marginally blurrier at worst 
> for full-hinted or (probably) bytecode-hinted text, and an improvement 
> over grayscale in either case.

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.

> Is that really the right thing to do? Since there are separate offset 
> metrics, don't width, height, x, y just bound the pixels that would be 
> affected if the glyph were drawn somewhere?

Yes, so we'd have to adjust the bounding box to cover the expanded pixels 
touched by the filtered output.  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.

> Subpixel hinting might be more useful if Xft could do subpixel 
> *positioning* of glyphs. Are there any plans for that?

Not in Xft.  Sub-pixel positioning requires an API with (duh) sub-pixel 
coordinates, and Xft is strictly a pixel-based API.  I've done some 
cheesy experiments which demonstrate that this will actually work, so
perhaps the cairo library could implement this.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20040506/a59e4559/attachment.pgp

More information about the Fontconfig mailing list