On 8/27/06, Keith Packard <[EMAIL PROTECTED]> wrote:
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.
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.
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?
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. Yes, yes, I know you and Carl
Worth are obsessed with precision, as evidenced by the aa discussions
on the Xrender mailing list. That is, before all the X11 lists changed and
killed off the discussion :( That was a sad day, I really enjoyed reading
that list...
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.
Would a separate set of Xft functions to get fonts that does a
subpixel grid be too much to ask for?
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.
Tor
_______________________________________________
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
