From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.fonts,gnu.misc.discuss
Subject: Re: "Hinting" using antialiasing? A GNUish alternative...
Date: 31 Dec 92 12:28:38 GMT
	<1992Dec27.225347.28173@pasteur.Berkeley.EDU>
	<PCG.92Dec29154125@decb.aber.ac.uk>
	<1992Dec29.193853.17902@pasteur.Berkeley.EDU>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth


A point of order: I will eventually post a summary of the e-mail
suggestions I have received. If any of my correspondents objects, please
let me know; after all I did not say explicitly that I might do a
summary. Thanks!

On 29 Dec 92 19:38:53 GMT, johnm@cory.Berkeley.EDU (John D. Mitchell) said:

johnm> The Nimbus font driver for GEOS is the fastest rasterizer
johnm> implementation I've ever heard of, seen, and/or used for that
johnm> class of hardware.

Some info about Nimbus? Some details about the rasterizer? :-)

pcg> For example I don't like the few seconds of latency that existing
pcg> renderers make me wait while the rasterize the fonts contained in an
pcg> imported document.

johnm> I'd say that it's most likely a matter of poor
johnm> design/implementation of the ImpEx code rather than (just) a
johnm> problem of the rasterizing of a bunch of fonts/characters.

No, because the delay does not appear when prebuilt bitmap fonts are
used...

johnm> Perhaps the systems that you're using are doing something silly
johnm> like building out all of the characters in each font that's used?

Neither, because it is easy to see a small pause as a previously unseen
character is rasterized in each of the first few paragraphs; after the
first few paragraphs virtually all the letters are done, so it's quick.

johnm> Fixed point arithmetic, when intelligently applied, is a great
johnm> thing. :-? :-)

Quite so, but not so easy; I imagine from your smileys that you have had
your little time with it.

johnm> Seriously though, I don't see any way of producing the kind of
johnm> quality output that you desire without non-local contextual
johnm> information and that must dramatically increase you resource
johnm> needs.

Bah, I can only hope some sucker (maybe myself :->) sees to it that non
local information filtering be not that slow. For example, instead of
averaging a 4x4 cell to 1x1, one could do with 8x8 to 2x2; or indeed one
could go for the really expensive and do 8x8 to 1x1. But it may be still
be fast enough: I still think that simple bitmap sweeps might be more
suited to current hardware than drawing a curve and then filling.

pcg> I think it would be more general because I guess it could be
pcg> patterned after the rather universal properties of human vision;

johnm> The same argument as above.  Any typeface designer worth anything
johnm> must take into account the biases and pecularities of human
johnm> vision.

pcg> As agreed above, but they do so *manually* (and "unconsciously":
pcg> they basically assume that what looks right to them looks right to
pcg> everybody). I think instead that it can be done, with tolerably
pcg> satisfying results, algorithmically.

johnm> I think this moves off into discussions about expert sytems and
johnm> other AI shme.

Not really; I think more straight image processing; there is an amazing
wealth of work that has been done on bitmap/pixmap filtering.

johnm> I do believe that many of the 'standard' tricks and rules of the
johnm> human vision trade can be codified into algorithmic 'filters' but
johnm> I don't see how that will be 'good enough'.

The only evidence I can offer are that automatically applied hints, as
in FontoGrapher, are often 'good enough'; also METAFONT, see below.

johnm> As they say, knowing when to break rules is at least as important
johnm> as the rules themselves.

Ah, but then this amounts to adjusting by hand the output bitmap for the
very most elegant output; and for this I think that just doing that and
recording the differences from the scaled one would do.

pcg> I like more what is done in METAFONT; there adaptation to the
pcg> resolution and quirks of the intended output device is done by
pcg> adjusting various parameters, like the shape of the "nib". This is
pcg> virtually equivalent to choosing a different filtering algorithm
pcg> (the "nib" is a filter!).

johnm> Hmm... Sounds interesting.  So instead of a single 'virtual' pen
johnm> you can have a multitude of drawing tools?

Indeed; when the countour of the outline is drawn, this is done with a
shaped "nib", and the size and characteristics of the nib can be
adjusted; for example METAFONT will rasterize to different bitmaps
depending on whether the output device is a write white or write black
laser (something no outline rasterizer that I know can be parameterized
about, except at times those embedded in the printer itself, that get
hand-tuned and hardwired, but not always, to its characteristics -- even
with Adobe, two printers with different technologies are more liable to
give different results with Type 1 fonts than with METAFONT ones). An
e-mail correspondent (Brian Bartolemew) observed:

Brian> I've long suspected metafont knows more about low resolution (~90
Brian> dpi) than it lets on - witness the comments-in-passing about
Brian> using diamond- shaped nibs instead of elliptical ones because
Brian> they produce fewer artifacts at lower resolutions.

Indeed even CM fonts, which have fairly fine details, come out quite
well at screen resolutions, without any hints whatsoever.

johnm> P.S.	I'm certainly for more/better 'free' scalable font
johnm> technology and building this stuff on top of filters may or may
johnm> not prove to be a good thing.  As an issue more relevant to the
johnm> gnu side of this discussion, I worry that the 'filters' being
johnm> 'programs' would thus be much easier to control (in the
johnm> copyright/patent sense).

Ah yes, but virtually all the image processing techniques around are
well known art, and thus free. Not that this has stopped anybody ever;
as the comp.compression FAQ reports, RLE encoding has been patented in
1986...

--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta