[Doh. Forgot to send to the list.] Keith Packard wrote: > In any case, it does appear that the filter to be used may indeed > need to be specified with some kind of preference; in your > auto-hinted example, I preferred the sharper appearance of the > intra-pixel hinting to the softer (but less colored) appearance of > the inter-pixel hinting. 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. > I used an intra-pixel hinter to ensure the pixel metrics returned by > the library matched the actual coverage of the glyphs; inter-pixel > hinting will stretch the glyphs by one or more pixels in the filtered > dimension, which seemed less desirable to me. We could just fix up > the metrics though; that seems relatively easy. 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? >> It would make more sense to hint to pixel boundaries vertically and >> subpixel boundaries horizontally. I got this working. As I expected, horizontal spacing is a bit better, and I don't see color fringing, although the vertical strokes in full hinting are somewhat blurred (about as much as medium hinting). I guess it's hard to filter strokes whose width isn't a multiple of a whole pixel. It may also be because whole-pixel hinting ends up optimizing most for the green channel, which the eyes are best at perceiving. Subpixel hinting might be more useful if Xft could do subpixel *positioning* of glyphs. Are there any plans for that? Anders
