Re: [ft] Tweaking/Improving FreeType Antialiasing

[Keith Packard]

On Sun, 2006-08-27 at 23:57 +0200, Tor Andersson wrote:

> I'm not sure I understand this. What's your definition of character metrics
> here? I'm grounded in the postscript world where the only metrics that
> matter are the origin and advance width.

For many applications, the extent of the rendered pixels is relevant for
redraw to work incrementally. Postscript doesn't need this most of the
time, although you can still get the actual glyph extents if you want
them.

> How does it change metrics? The resulting bitmap will be of a different
> size and have different lsb/top offsets, but apps have to cope with varying
> bitmap sizes anyway (as returned by FT_Render_Glyph), or am I totally
> ignorant about how xterm & co draw their text?

Terminal emulators often assume that each glyph fits within a fixed size
box and do not touch pixels beyond that box. For updating the screen
image, this is significantly easier than computing which set of glyphs
need to be repainted to erase a glyph.

> You can also cheat and do the interpixel filtering without changing
> the bitmap size. The slight error at the edge is not visible; and is still
> a lot better than what Xft does now.

Sure, that might be a good thing to try with the existing Xft codebase.
I didn't bother; on my monitors, given suitably hinted glyphs, it didn't
provide enough improvement to be worth the effort.

> Would a separate set of Xft functions to get fonts that does a
> subpixel grid be too much to ask for?

Yes. Xft uses only pixel positioning, so there's no way to ask it to
draw glyphs on a sub-pixel grid. Xft is designed to plug into existing
pixel-based applications using integer coordinates. Applications which
have moved to sub-pixel coordinates would do better to choose a better
rendering API anyways. Cairo already exposes sub-pixel coordinates, and
you can experiment with sub-pixel positioned text as well, although the
'fast' code paths there are strictly pixel-aligned at the present time.
Fixing cairo to display text on sub-pixel coordinates would be
reasonably easy; patches are welcome.

> I know there's nothing in the RENDER protocol to prohibit it,
> and if it's an easily accessible piece of functionality it might be
> more likely to be used.

Sounds like you should start experimenting with patches to cairo and
pango then; that'll fix up all gtk+ apps and allow you to build the
cairo/pango-based Mozilla and get your fixes working there as well.

-- 
address@hidden

signature.asc
Description: This is a digitally signed message part