On Sun, 2006-08-27 at 22:48 +0200, Tor Andersson wrote: > On 8/27/06, Roman Shaposhnik <[EMAIL PROTECTED]> wrote: > > On Sun, 2006-08-27 at 14:24 +0200, Tor Andersson wrote: > > > It still won't be perfect, since all Linux toolkits snap metrics to > > > pixel integer coordinates which gives somewhat uneven spacing. > > > Don't even think about CoolType or ClearType in Linux; the Xft code > > > does not do filtering across pixel borders so it's a *lot* worse than > > > it could be. > > > > Thanks for the info, but let me ask you this -- is there somebody > > working on Xft to make it possible ? Are they pursuing a different > > route ? > > I'm not sure. If I remember correctly, Keith Packard explicitly decided > that he didn't want the filtering to cross pixel borders because that > might possibly confuse xterm and other character cell based software. > Stupid reason, if you ask me.
Lame, perhaps, but still important -- filtering that extends beyond the pixel changes all character metrics, which is relevant for applications which cannot handle overlapping glyphs. As Xft was designed largely as a migration API for existing applications, trying to preserve as much of the semantic environment as possible seemed important. We can certainly change how this works in new rendering APIs like cairo where applications are moving beyond pixel-oriented drawing. Sub-pixel positioning is another important area; you can explore this with cairo today by converting glyphs to paths and filling them rather than using the simple text filling APIs. Making this 'go fast' is somewhat tricky as you need to cache rendered glyphs for acceptable performance these days, which means picking a sub-pixel grid for positioning. > I used pure freetype. The filtering can be done with a minor patch > to Xft; the hard part is not the code, it's the convincing the right people. Changing Xft in this way will change character metrics, which will break many existing applications. One option is to experiment with doing this only for non-character cell fonts and see what that does; many of these fonts already expose applications to overlapping glyphs. -- [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