[cairo] Sub-pixel Font Filtering in 1.10

[Carl Worth]

On Fri, 15 Jan 2010 09:15:09 +0000, Freddie Witherden <freddie at witherden.org> wrote:
> It is not a band-aid at all. Cairo currently uses an intra-pixel filter taken 
> from libXft. This filter is *technically inferior* to finite impulse response 
> filter (FIR) which is used by: CoreText (OS X), ClearType (Windows), Qt (pre 
> 4.5) and FreeType (post 2.3 as an option). The FIR type filters are inter-pixel 
> filters (so the filtering is performed across sub-pixel boundaries --- just as 
> it should be).

So we'll have to agree to disagree on that point. For me---and with the
display devices I have currently available, (on which individual pixels
are still visible---for me, I still really like being able to take
advantage of the high-frequency output that's available in the output
device at a pixel boundary. When a font's vertical stem bleeds from one
pixel column to the neighboring pixel column, the resulting lack of
contrast is unacceptable for me.

As display devices improve, those pixel boundaries will become less
meaningful, and then I'll agree with you that the filtering should
ignore them.

> The hinting argument is also heavily flawed; it is hinting itself that is a 
> band-aid --- a hack from a time when anti-aliasing was not practical. The 
> effect of hinting is to distort the outlines of glyphs --- and hence it *can 
> not* be used when rendering freely scalable text, such as that in a PDF 
> document. So if you want your system to be able to render PDF documents with 
> sub-pixel rendering you need an FIR-type filter.

I've always thought "hinting" was a bad name for this. What we should be
talking about is "instructed" fonts since the fonts themselves contain
instructions (from the font designer) on how the shape should be
constructed at various glyph sizes. Even modern fonts, created after "a
time when anti-aliasing was practical" seem to be shipping with these
instructions still. (And it's a fairly expensive job for a font designer
to create them). So it's not obvious to me that this is going away, (nor
does it seem fair to describe the process of implementing
font-designer-supplied instructions as "distortion").

> I discuss these hinting- and implementation-related issues at length in my 
> article on font rasterisation:
> 
>  http://freddie.witherden.org/pages/font-rasterisation/

A very nice writeup of many of the issues. Thanks for pointing this out.

I see a couple of things that I would disagree with. For example, after
figure 10 you claim that all three of the filters "are successful in
eliminating colour fringing". I take issue with that claim---it
definitely depends on the output device and viewing conditions.

For me, with my laptop's builtin panel, I would agree that there's no
unacceptable color fringing in any of the images. But with an external
LCD monitor that I have next to the laptop, (so identical viewing
conditions), the color fringing is noticeable and objectionable with all
three samples, (particularly when seen next to the web-browsers
rendering of well-hinted, intra-pixel filtered text in the surrounding
text).

The external is obviously brighter and higher-contrast than the laptop's
display. And to me, it makes the shortcomings of the approach used in
those samples quite obvious.

The other point I would disagree with is the attempt to dismiss
intra-pixel filtering as objectively "technically inferior". I'll agree
with you that this filtering only makes sense with well-hinted text. But
I would go beyond that to say that sub-pixel rendering only makes sense
with well-hinted text. (Since otherwise, the color fringing is *always*
objectionable given sufficiently capable display hardware).

> Personally, I am not convinced there is a need to directly configure the sub-
> pixel filter. (Unlike say with hinting and anti-aliasing where a sound 
> technical case can be made for changing these --- such as when requiring 
> freely scalable text.) Just respect Fontconfig and everyone wins.

So after all the disagreement described above, I think we're in violent
agreement here. I think I'd accept a patch that makes cairo accept
fontconfig options and pass them through to freetype, (without adding
cairo API). At that point, the technology successfully routes around any
opinions I have here.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20100115/d27fccec/attachment.pgp