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. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://freedesktop.org/pipermail/fontconfig/attachments/20040506/a59e4559/attachment.pgp
