Fontconfig - Nov 2005 - Greatly improved subpixel filtering in Xft

Keith Packard wrote:
> The current filter was designed to be used in conjunction with well hinted 
> text, that''s for sure.  I wonder if you might compare the results
of
> correctly hinted glyphs with your new filter; I''m concerned that
extending
> the filter beyond a single pixel will cause those edges to be fuzzier.
We might disagree about what correct hinting is--I happen to think that 
Freetype''s medium autohinting (shown in my screenshots) gives the best 
fonts I''ve ever seen on a computer screen. I''m sure
it''s a matter of
opinion.

If by correct hinting you mean Freetype''s full hinting, here are some 
screenshots of that under the two filters:
   <http://www.kaseorg.com/~anders/subpixel-before-fullhinting.png>
   <http://www.kaseorg.com/~anders/subpixel-after-fullhinting.png>
Again, my filter seems to give reduced color artifacts, and doesn''t
look
significantly blurrier. Is that what you wanted, or should I compare 
something else?

A closeup of full hinting with the current filter shows that subpixel 
antialiasing only gets applied to diagonal and curved strokes; the rest 
is black and white. I think that''s wrong, because a row of white,
black,
white gets shown as "RGB___RGB", and the red and blue parts are off 
center by 1/3 of a pixel. Indeed, if I look really closely at the 
screen, I can see fringes of blue and red surrounding the vertical black 
lines. My filter borders those lines with very light orange and cyan to 
maintain balance. In xmag, that looks as if it would blur things, but on 
the actual screen, it results in sharp black lines.

However, with subpixel rendering (and good filtering :-)) there isn''t 
much of an advantage to snapping things to whole-pixel boundaries (at 
least horizontally), as full hinting currently does. It would make more 
sense to hint to pixel boundaries vertically and subpixel boundaries 
horizontally. Is it possible to make Freetype do that?

Anders

[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

Around 20 o''clock on May 5, Anders Kaseorg wrote:
> We might disagree about what correct hinting is--I happen to think that 
> Freetype''s medium autohinting (shown in my screenshots) gives the
best
> fonts I''ve ever seen on a computer screen. I''m sure
it''s a matter of
I mean TrueType fonts with the bytecode interpreter enabled.  In that 
environment, vertical and horizontal elements align to the pixel grid, 
which is not the case even with the FreeType autohinter set on
''full''.

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.

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.
> However, with subpixel rendering (and good filtering :-)) there
isn''t
> much of an advantage to snapping things to whole-pixel boundaries (at 
> least horizontally), as full hinting currently does. It would make more 
> sense to hint to pixel boundaries vertically and subpixel boundaries 
> horizontally. Is it possible to make Freetype do that?
Yes, it''s quite possible to do that; you hack Xft to apply the times-3 
transformation before the hinting rather than afterwards.  I recall trying 
that and being quite disappointed with the results because neighboring 
edges tended to really magnify the color fringing effects.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20040505/5b70da08/attachment.pgp

Around 14 o''clock on May 6, Anders Kaseorg wrote:
> 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.
Perhaps, but I would hope most users can use the bytecode interpreter, 
which means that the current filter would be a better default.  Throwing 
away the carefully constructed outlines produced by the bytecode 
interpreter is a huge waste.
> 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?
Yes, so we''d have to adjust the bounding box to cover the expanded
pixels
touched by the filtered output.  This may be a problem for terminal 
emulators which assume that glyphs don''t ever overlap, and other 
applications which assume that adjacent lines of text don''t overlap.
> Subpixel hinting might be more useful if Xft could do subpixel 
> *positioning* of glyphs. Are there any plans for that?
Not in Xft.  Sub-pixel positioning requires an API with (duh) sub-pixel 
coordinates, and Xft is strictly a pixel-based API.  I''ve done some 
cheesy experiments which demonstrate that this will actually work, so
perhaps the cairo library could implement this.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20040506/a59e4559/attachment.pgp

Keith Packard wrote:
> Perhaps, but I would hope most users can use the bytecode interpreter, 
> which means that the current filter would be a better default.  Throwing 
> away the carefully constructed outlines produced by the bytecode 
> interpreter is a huge waste.
As I''m sure you know, many users might not be legally allowed to use
the
bytecode interpreter... Don''t tell Apple, but I did some tests with 
bytecode-enabled Freetype, on some of Microsoft''s TrueType fonts, to
see
what kind of differences we''re talking about:
   <http://www.kaseorg.com/~anders/subpixel-before-bytecode.png>
   <http://www.kaseorg.com/~anders/subpixel-after-bytecode.png>

I still think my filter is an improvement, but even if you consider this 
to be a worst case--do you really think I''m "throwing away the 
outlines," and the difference really great enough to warrant defaulting 
to a filter that produces output nearly equivalent to grayscale for 
heavily hinted text, and bad color artifacts in all other cases?

If you still think so, fine, but I hope that I''ve at least convinced
you
that making the filter configurable is worthwhile. Should I try to do that?
> Yes, so we''d have to adjust the bounding box to cover the expanded
pixels
> touched by the filtered output.
Oh, I thought I already am, by adjusting left/right (or bottom/top, for 
vertical subpixels), which get propogated to the metrics. Am I missing 
something?
> This may be a problem for terminal 
> emulators which assume that glyphs don''t ever overlap, and other 
> applications which assume that adjacent lines of text don''t
overlap.
Monospace fonts get clipped to a box anyway by the current code. I''ve 
had no problems except that GTK underline bug, which is hardly noticable 
and could be fixed in GTK by using the offsets instead of the bounding 
box (again, Mozilla gets it right). I even tested with a pathologically 
wide 5 pixel blurring filter in all four subpixel layouts (okay, maybe 
that constitutes throwing away the outlines :-)).

Anders

Well, here''s a first attempt at making the filter configurable:
   <http://www.kaseorg.com/~anders/libXft-improved-filtering.patch>

Set Xft.filtertype: 0 in /etc/X11/Xresources for the my inter-pixel 
filter, 1 for the existing intra-pixel filter. (Yeah, my filter is the 
default for now.) New filters can be added in xftglyphs.c, and will 
accessible by setting filtertype to their index. I wasn''t sure whether 
the setting should have been XFT_BLAH or FC_BLAH, but I made it 
XFT_FILTER_TYPE because I didn''t want to muck around with fontconfig
too.

It works great for the most part, but there seems to be a problem: the 
setting isn''t getting applied in gnome-terminal, even though it is 
applied in gedit with the same font. I''m not sure why that would be.

Anders

Around 16 o''clock on May 5, Anders Kaseorg wrote:
> The current subpixel filtering in Xft is nearly useless, as black text 
> tends to come out as a distracting mixture of red and blue:
The current filter was designed to be used in conjunction with well hinted 
text, that''s for sure.  I wonder if you might compare the results of 
correctly hinted glyphs with your new filter; I''m concerned that
extending
the filter beyond a single pixel will cause those edges to be fuzzier.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20040505/5411fd60/attachment.pgp

The current subpixel filtering in Xft is nearly useless, as black text 
tends to come out as a distracting mixture of red and blue:
   <http://www.kaseorg.com/~anders/subpixel-before.png>
That''s because the filter is currently limited to staying within pixel 
boundaries. I wrote this patch to fix it:
   <http://www.kaseorg.com/~anders/libXft-improved-filtering.patch>
The result:
   <http://www.kaseorg.com/~anders/subpixel-after.png>

This is a *huge* improvement--even without proper gamma correction, I 
see almost no color fringing at all. It works for RGB, BGR, VRGB, and 
VBGR. The only side effect I''ve noticed is that the underlines for 
access keys in some GTK menus become a tiny bit wider (which is probably 
GTK''s fault, since the menus in Mozilla applications are fine).

It currently uses a simple box filter, [1,1,1]/3, because that looked 
sharper to me than things like [1,3,4,3,1]/12, but the filter is trivial 
to change, and it can go outside the current pixel by arbitrary amounts.

Anders