Xref: utzoo comp.graphics:3549 comp.text:2721
Newsgroups: comp.graphics,comp.text
Path: utzoo!utgpu!jarvis.csri.toronto.edu!dgp.toronto.edu!avi
From: avi@dgp.toronto.edu (Avi Naiman)
Subject: Re: Gray-scale antialiasing (yes, it can work)
Message-ID: <8811080203.AA15665@explorer.dgp.toronto.edu>
Keywords: grayscale fonts
Organization: University of Toronto, CSRI
References: <74013@sun.uucp> <148@internal.Apple.COM> <4763@mnetor.UUCP> <174@internal.Apple.COM> <19809@apple.Apple.COM>
Date: Mon, 7 Nov 88 21:03:37 EST

In article <19809@apple.Apple.COM> jp@Apple.COM (John Peterson) writes:

>> David Casseres
>John Peterson

>> As to its being cheap to implement, it's true there is less hardware cost
>> in anti-aliasing than there is in greater pixel density.  But until someone
>> makes a breakthrough or two, it requires some very intense computation
>> right where you don't want it, i.e. right in the middle of your character-
>> display loop where it trashes your display performance.

> This is incorrect.  I would not consider BitBlt (aka CopyBits) to be an
> "intense computation."  Like all other screen fonts, anti-aliased fonts are
> pre-computed and cached.  To display them, you copy rectangles of pixels onto
> the screen.  For the vast majority of applications (page layout, word 
> processing, etc) that's all the "computation" you need to do.  

If the approach taken is to pre-compute a single version of a grayscale
font (for each font size and display resolution possible), then I would
agree with John that copying bytes is not much more intensive a
computation than copying bits.  However, this approach restricts the
flexibility of using grayscale for sub-pixel positioning of edges.  In
particular, one could not move a character left or right by less than a
pixel of space; each character exists on an integral lattice which must
coincide with the device's pixel grid.

Alternatively, one could generate many grayscale versions of the same
font at a particular size and for a specific device, each differing
only slightly from the next in terms of the sub-pixel position of the
target resolution sampling grid relative to the master resolution of
the filtered characters.  In this manner, one could do a more accurate
job of approximating the spacing required between successive
characters, by using the particular version of the character which
minimizes the spacing error.

In our context, if we have a half pixel error in the positioning of a
character, one character pair may appear too 'closely' set by half a
pixel, while the next pair seems too 'loosely' set by half a pixel.
Where the size of a pixel is large relative to the size of the
character, this can lead to disastrous spacing problems.  Even for
state-of-the-art monitors with a resolution of approximately two pixels
per typographer's point (in each of x and y), when setting 10-point
text (about .35 cm), a half pixel of error is about 10% of the average
inter-character spacing (one quarter of the point size) while the
variation between the spacing of pairs of characters can be as much as
20%.  By using 8 different x-phases in generating the grayscale
characters, this error can be reduced to 1.25% and 2.5%.  For more
common monitors (about 1 pixel per typographer's point), the errors are
20% and 40%, and 8 phases can reduce this to 2.5% and 5%.  [Note that
different y-phases can be utilized when there is a necessity for leading
which is a non-integral multiple of the pixel size, as well as for
superscripts, subscripts, and tabular data.]

Due to the abundance of digital fonts available today (at virtually any
size) and the requirement of sub-pixel positioning for accurate
spacing, prefiltering all possible grayscale characters is impractical
(in fact, it is impossible, since the user may always want a size which
has not been made available).  Therefore, I would agree with David
Casseres' comment above, that what we need is the capability to
dynamically generate the requested characters at the appropriate size,
resolution, and phase, coupled with font-caching software to reduce the
need to recompute already-generated characters.  I contend that the
research reported in the below-cited paper is a step in that direction.

Naiman 88 Naiman, A. and A. Fournier, ``Rectangular Convolu-
          tion  for Fast Filtering of Characters,'' Computer
          Graphics, Volume 21,  Number  4,  July  1987,  pp.
          233-242.
-- 
Avi Naiman
avi@dgp.toronto.edu