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

Internet Message Format | 1992-12-29 | 7.6 KB

Xref: sparky comp.fonts:3805 gnu.misc.discuss:4120
Newsgroups: comp.fonts,gnu.misc.discuss
Path: sparky!uunet!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: Tue, 29 Dec 1992 19:38:53 GMT
Lines: 133

In article <[e-mail]> [e-mail] (Piercarlo
Grandi) writes:
>On 27 Dec 92 22:53:47 GMT, [e-mail] (John D. Mitchell) said:
>johnm> You might want to take a look at the documentation for GeoWorks'
>johnm> GEOS platform.
>Can you give some more info? I seem to remember it is kind-of a DOS GUI,
>only cheaper/faster/simpler than Windows 3.1 (not that it's difficult :->).

[...Semi-commercial product blurb, since it was specifically asked for...]
The GEOS system produced by GeoWorks (Berkeley, CA) is a multi-threaded,
fully preemptive multi-tasking, graphical user interface, object oriented
operating system that runs on Intel 80x86 based harware ranging from sub-1
pound palmtops through the original 512Kb, CGA IBM XT to the latest
workstation class 486s.
[...End of blurb...]

The features of GEOS(r) relevant to the current discussion is its "Single
Imaging Model" (ala Postscript(tm)).  Basically, the system is built around
a font manager that fulfills requests for fonts/characters.  The exact same
font generation calls are used by the graphics system (for the screen) as
is used by the printer drivers (for printing).  The font manager manages
font drivers for each of the major rasterizers (e.g. Nimbus, Speedo,
etc.).  The font manager handles caching the built characters as well.  The
Nimbus font driver for GEOS is the fastest rasterizer implementation I've
ever heard of, seen, and/or used for that class of hardware.

>Yes, but this holds true for both technologies; so if one has less space
>for caching, then a faster technique is preferable. For example I don't
>like the few seconds of latency that existing renderers make me wait
>while the rasterize the fonts contained in an imported document. Maybe I
>am spoilt for speed, or maybe I cannot afford the latest Quadra or
>DX2-66.

Import/Export is always going to be relatively slow (there's a helluva lot
that goes on).  I'd say that it's most likely a matter of poor
design/implementation of the ImpEx code rather than (just) a problem of the
rasterizing of a bunch of fonts/characters.  Perhaps the systems that
you're using are doing something silly like building out all of the
characters in each font that's used?  That's a tragic waste of resources
and I could certainly understand that causing a noticeable slow down.  I'd
recommend switching to a better platform.  :-)

>However, given that in most common day use one uses only two sets of
>fonts, one for the screen and one for printer, I am particularly
>thinking of keeping around printer resolution bitmaps, which are the
>ones that after all matter most, and then scaling them on the fly to the
>screen resolution. I am even thinking that it would make sense putting a
>font server *into the printer*, which, for networked printers, is the
>right thing to do. And non networked printers can be turned into
>networked ones for a few hundred dollars by way of a PC as gateway.

The font usage patterns depend very much on the ease of use of multiple
fonts in the document creation/modification applications (e.g., word
processor).  Speed makes a difference too.  I.e., people tend to use more
fonts (and more graphics, etc.) if it's easy (and fast) to do so on
whatever system they are using.  If it's difficult then they'll pick the
very small number that they use most often and stick to them pretty much
exclusively.

The problem with offloading the work to the printer is that of cost.  It
might make sense as you propose to have an intelligent network printer but
you still have problems of supporting that printer along with all of the
other 84 gadzillion makes and models out there (unless you don't care about
that market :-).

>I think too one would need context sensitive filtering; but I think this
>would still be a win. It is often non obvious how to implement
>Bezier/quadratic splines using integer only arithmetic, while all sorts
>of bitmap filtering I can envision use only integer arithmetic and
>pretty simple as well, and very predictable memory access patterns. This
>can be an advantage.

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

After thinking about this more, I don't believe that you can come up with a
solution that is as fast as a well implemented rasterizer based system and
yet produces comparable (as good or better :-) output.  Heck, I'll win
either way, you can make an idiot out of me by raising the state of the art
or I'll look omniscient.  :-? :-)  Seriously though, I don't see any way of
producing the kind of quality output that you desire without non-local
contextual information and that must dramatically increase you resource
needs.

[...]
>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.
>
>As agreed above, but they do so *manually* (and "unconsciously": they
>basically assume that what looks right to them looks right to
>everybody). I think instead that it can be done, with tolerably
>satisfying results, algorithmically. Moreover the situation for hints in
>existing font specification languages is less than satisfying:

I think this moves off into discussions about expert sytems and other AI
shme.  I do believe that many of the 'standard' tricks and rules of the
human vision trade can be codified into algorithmic 'filters' but I don't
see how that will be 'good enough'.  As they say, knowing when to break
rules is at least as important as the rules themselves.

[...]
>In practice designing a well tuned TrueType font is exactly identical to
>designing the bitmaps at the various low resolutions that must be
>supported, and then just encoding this as a fairly inefficient
>programmatic outline and a series of fairly inefficient programmatic
>(even if I seem to remember that one can actually specify bit-by-bit)
>patches to it.

Sounds like a lame excuse for an outline based typeface system.  Sounds
like somebody just wanted to get some new 'standard' to market(ing) and
didn't give a crap about it's usefulness/quality/etc.

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

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

Thanks,
    John
    [e-mail]

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