[cairo] Sub-pixel Font Filtering in 1.10

[Tobias Wolf]

Keith Packard <keithp <at> keithp.com> writes:
>
>

Hello,

this topic has popped up many times already and every time we get these 
reactionary views that want to preserve the state-of-the-art anno 1995.


> 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.

[snip]

> 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).

> 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.
 
For you the Vera/DejaVu family maybe the be all end all of fonts on free 
desktops but do we really want to be looking at these fonts (and the old 
msttcorefonts) only until the end of time?

Conventional TrueType instructions are fading into irrelevancy:

- Conventional instructions prevent freely scalable canvases.
- Microsoft does not commission fonts like that anymore. They have something 
  new now. They even began to ignore x-axis hints in old fonts.
  Some interest/work to support this came up in FreeType recently [1]
- There is a rich treasure trove free-software/free-beer fonts available for
  display/ornamental/even body copy use that almost never have TT 
  instructions. I would not call them cheap at all because of that. 
- Expensive, new commercial fonts are predominantly sold as PostScript-like 
  CFF OpenType.
- The web will soon see an explosion of web fonts coming via @font-face, 
  SVG, or WOFF. They will be either commercial or free and likely not have 
  “quality” TT instructions.

Finally, many people are sick of DejaVu Sans for everything. Even if they were 
a valuable gift and still important. Besides them and msttcorefonts, what 
other fonts do lend themselves to pixel snapping and intra-pixel filtering?

> 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.


Precisely. And it so happens, as established many times before, that there is 
no other way to achieve consistency across the board than to use the signal 
processing approach you outlined above.
 
--Tobias

[1] http://lists.gnu.org/archive/html/freetype/2009-12/msg00004.html