🚀 go-pugleaf

In article <3300@internal.Apple.COM> casseres@apple.com (David Casseres):
>
>Anti-aliased fonts MAY be more desirable in some applications.  We don't 
>know, because the research hasn't been done, whether they give less 
>eyestrain -- they may give MORE eyestrain.  Remember, the essence of 
>anti-aliasing is that it removes the "jaggies" by blurring them.  So 
>eyestrain is a question, and so is readability.  The only "better quality" 
>that we KNOW about from anti-aliased fonts is that they LOOK better when 
>you just look at them (as opposed to sitting down and doing some reading).

I don't have the studies, but I believe that the studies suggesting that
readability increases was done either be IBM (as suggested on the net) or
XEROX (my belief).  However, I suggest that computer screens are not
"so clear" that a small amount of controlled blurring would not be
beneficial.  I even remember it being suggested that the ringing done
when the circuitry driving the electron beam goes from "full on" to "full off"
is a major component of eyestrain, which can be relaxed somewhat by using
greyscales.

>Furthermore, the technology is not simple, especially if you are creating 
>the fonts on the fly and don't want it to take all day.  It's not worth 
>doing unless you implement sub-pixel positioning, i.e. the ability to 
>place a character (logically) on a grid that is finer than the screen 
>resolution, using gray to "blur" it into the right place.  This is because 
>character positioning, not jaggies, is the main thing that makes text look 
>funky and unreadable at low resolutions.  But to do this means redoing the 
>anti-aliasing every time each character has to be drawn, or else caching 
>several versions of each character image.
>
Anti-aliasing merely requires generating a bitmap in a larger (double) 
resolution and then averaging some number of pixels (four) to
determine the shade of gray to use.  This intermediate step can of course
be skipped when computing bitmaps from curves (the averaging being done
in the process of computing the curves), but it seems that this would be
a small amount of cpu time compare to calculating b-splines (or bezier 
curves) and grid shifting.

Furthermore, there are more reasons for doing it than implementing sub-
pixel positioning:  It would allow oblique (italic) characters to be slanted
at a less severe angle.  It would remove the problem of highlighted text
being completely black on a grayscale monitor (or am I the only one
with this problem).  It would be another first for the Macintosh
software, and a huge experiment; if they really don't increase readibility,
then no big deal, they go away.  If they do, then Apple scores big (I see
adds with pc's and people with glasses and big bottles of Excedrin vs.
happy people with macintoshes :).  It would give them a chance to work out
the bugs before system 8.

Someone else wrote: (sorry, I saved without the header)
>One thing, though, for both of you.  Anti-aliasing is going to require some
>computation.  If you watch the demo that apple has (or the one I saw, anyway)
>of the new outline fonts, it starts printing slowly, then speeds up as it
>begins to repeat characters it's already built.  The demo was "filmed"
>on a Mac II (I don't know if it was a IIx or IIcx, but I suspect that it
>was) and it was still fairly slow.  Now imagine throwing in all the
>computation for the anti-aliasing.  The first characters are going to crawl
>Displays with, say, 24-bit depth would be particularly hard-hit, I think.
>And Quick Draw won't be quick if it does anti-aliasing, either, since it
>doesn't use a build-once-then-reuse process...

I don't think that most people work in 32 bit color.  Especially for text
oriented things.  And I am not encouraging 24 bit averaging.  Two would
be sufficient.  Further even if it takes noticibly longer to produce the
anti-aliased fonts (I believe unlikely), what you describe seems sufficient
to convince alot of people to leave their macs on all of the time (if they
don't already to save wear and tear on their hard drives).

Bob Truel





Robert N. Truel			"Life sucks, of course, but it didn't have
				 to suck quite like this" -- RJSJR
truel@silver.bacs.indiana.edu
truelr@iubacs.BITNET