[cairo] Sub-pixel Font Filtering in 1.10

[Keith Packard]

On Fri, 15 Jan 2010 20:56:26 +0000, Freddie Witherden <freddie at witherden.org> wrote:

> Interesting. All of the information I have seen (including viewing my own 
> screens under a microscope) showed there to be no perceptible gap between the 
> sub-pixels of adjacent pixels.

Yes, I've also studied many screens with a magnifying glass and found
their subpixel elements spaced evenly across the screen.

However, that's not relevant here. The point is that you want glyph
features to share the same minimum feature size in both directions and
the smallest such available dimension is one pixel high and three
sub-pixels wide. Thus, you need to snap glyph feature widths (and
heights) to a full pixel. This is easily done by ignoring the subpixel
boundaries for the purposes of glyph hinting, and only using it for
sub-pixel filtering.

Of course, if you want to lay text at an arbitrary sub-pixel boundary,
this continues to work correctly, you just slide the whole glyph over by
a subpixel unit and recompute the RGB values for the new position. This
works quite well, as seen here:

      http://keithp.com/~keithp/subpixel

This provides for sub-pixel boundary positioning while glyph features
remain fitted to pixel-sized units in both dimensions.

However, it seems like you're not understanding our primary objective
for displaying text on the screen.

The goal is to take full advantage of the extremely high frequency
feature available to us on a typical LCD screen -- the edges of each
sub-pixel unit. Those edges allow us to generate a discontinuous step in
color which is unmatched by any other system where the term 'FIR' would
normally apply. This step function is precisely what we want to make
glyphs appear as sharp as possible. No wishy-washy gradient will do, we
want white on one side of the step and black on the other.

Of course, this only works for vertical and horizontal edges; it doesn't
work for curves or diagonal strokes. And, it can only reproduce those
edges accurately when they are perfectly aligned with the edges of the
LCD sub-pixel units on the screen.

For those other elements, we use anti-aliasing to eliminate jaggies,
while recognising that they will make the glyphs look inconsistent, with
some sharp edges and some fuzzy edges. What sub-pixel hinting does is
increase the frequency response possible across these fuzzy edges,
getting them closer to our ideal step function edges.

Careful selection of font style (slab or sans serif faces) allows the
user to select glyphs which have more sharp edges and fewer fuzzy
edges.

What is also important here is that you have no large continuous block
of the same color caused by this hinting -- get the blob small enough
and the eye won't be able to detect the color.

This is where we get into trouble with vertical elements which do not
cover a triad of subpixel elements exactly. Vertical elements of this
nature will generate a visible color fringe when the area becomes large.
What this argues for is to not use sub-pixel hinting where glyphs will
have vertical elements that are not carefully adjusted to avoid
fringing, or at least to reduce the frequency response of the filter to
make the fringe less objectionable.

The Bitstream company graciously donated a complete set of faces
specifically designed for use with Xft and cairo. All of the instructed
hints (which were not machine generated) were adjusted using Xft to
produce the desired results on an LCD screen. As such, the current Cairo
sub-pixel filter *is* the target for this important family of fonts (and
at least some of the glyphs in the DejaVu derivative). Any other filter
moves away from the font designers intent.

The other extreme (taken by Apple and others) is to essentially ignore
*all* hinting, treat the pixels on the screen as gaussian blobs (like we
used to have with CRTs) and use regular signal processing techniques to
reproduce the glyphs. This eliminates any change in glyph shape at
different pixel densities, eliminates all need to hint glyphs. In this
environment, I think a 'real' FIR filter for sub-pixel elements probably
makes sense.

Implicit in this architecture is the assumption that pixels are 'small
enough' that the Nyquist limit is high enough to provide an effective
edge to the viewer. As display resolutions top 200dpi, I believe this
will likely become true. At this point, with desktop displays still
hovering around 100dpi (my external monitor is 101dpi), I still need my
physical pixel edges to make text look good. On my laptop, with a 140dpi
screen, it's getting closer, so perhaps it's only a matter of
time.

> A couple of points here. Firstly, very few professional fonts (such as those 
> in Adobe's Font Folio collection of OpenType fonts) contain TypeType bytecode 
> hinting. In fact, nearly all OpenType fonts contain Type1 outlines (which have 
> limited support for hinting, certainly nothing close to pixel-perfect bytecode 
> hinting).

Of course -- the Type1 format was originally used solely to deliver
fonts to a PostScript printer driver. Hinting in Type1 was bolted on
after the fact, and was clearly never a central design feature of that
technology. When your goal is pre-press, then the requirement is that
the screen presentation match the paper presentation, and not that the
screen presentation be valuable in itself.

In contrast, TrueType was specifically designed for on-screen scalable
fonts, and the byte code hinting technology allowed designers to create
precisely the desired outline at any pixel size (in fact, good fonts
have per-size outline adjustment values for many popular pixel sizes).

OpenType is just the union of these two technologies, permitting fonts
sourced in either Type1 or TrueType form to live in the same container
format.

> At this point our candidate set is reduced to .ttf fonts and OpenType fonts 
> with .ttf outlines. It is true that many do contain bytecode hinting 
> instructions. However, they are nearly always generated mechanically rather 
> than being 'hand tuned.' Ironically the FreeType auto-hinter often does a 
> better job here than the actual bytecode.

Sure, getting decent fonts is hard, and sometimes expensive. This does
not justify wrecking the presentation of these good fonts just to make
the presentation of cheaper fonts a little bit less ugly.

What you don't want to do is mix two different rasterization techniques
on the screen at the same time. That's like mixing anti-aliased and
non-antialiased text; the eye is distracted by the jarring differences,
making reading much more difficult.

So, we essentially have two worlds -- one where people have carefully
hinted TrueType fonts for which intra-pixel filtering and pixel-boundary
snapping preserves as much of the available desirable high-frequency
edges as possible and one where the fonts have no useful hints and one
simple trusts classic signal processing techniques to make the raw
outlines as good as possible.

-- 
keith.packard at intel.com
-------------- 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/5cb8bfa7/attachment.pgp