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. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype