NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/fonts/3773

Internet Message Format | 1992-12-25 | 1.8 KB

Xref: sparky comp.fonts:3773 gnu.misc.discuss:4108
Newsgroups: comp.fonts,gnu.misc.discuss
Path: sparky!uunet!think.com!spool.mu.edu!agate!pasteur!cory.Berkeley.EDU!johnm
From: [e-mail] (John D. Mitchell)
Subject: Re: "Hinting" using antialiasing? A GNUish alternative...
Message-ID: <[e-mail]>
Sender: [e-mail] (NNTP Poster)
Nntp-Posting-Host: cory.berkeley.edu
Organization: University of California, at Berkeley
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 25 Dec 1992 21:49:16 GMT
Lines: 21

Hmm... I must be missing something in this discussion...  All of the
rasterizer code that I've seen makes calls to an implementation defined
function to handle the actual drawing of each section of the given
character (well, they could be told to generate a bitmap too, but that's
irrelevant IMO to this discussion).  The rasterizer is passing me things
like "there's a line segment from point (x,y) to point (r,w)" and I can
draw the line on the screen (or printer or plotter...).  What's to stop me
from optimizing the horizontal and vertical lines and then using an
anti-aliasing line drawing routine for everything else?  At some point the
choice to light a given pixel in the character box for the character over a
pixel immediately adjacent becomes arbitrary due to the physical device
resolution (i.e., I don't understand how this 'intelligent' bitmap scaling
filter system can produce output that is 'better' than hinted fonts).
Unless a person goes over every single character generated at each size,
style, etc.  There's still going to be in essence arbitrary decisions made
by the filters that I don't see how they could be any more correct then an
hinted, outlining rasterizer.

Thanks,
    John
    [e-mail]