More about fonts

["Daniel L. Weinreb" <DLW@alderaan.scrc.symbolics.com>]

    Date: Tue, 3 Mar 87 00:26:57 -0100
    From: unido!gmdzi!jc@seismo.CSS.GOV (Juergen Christoffel)

    For me 'corresponding' is simply: looks about the same on screen and
    paper.  

Oh.  In that case, Genera 7.0 already has "corresponding fonts", for
the FIX, DUTCH, and SWISS families, for four faces and five sizes, on
the screen and on the LGP2.

       Simply use a generic font description instead of all those particular
    fonts. From this you may generate almost all pixel sizes you'll want and
    almost any variation you'll like (i.e. bold, slanted, italics and so
    on). 

It would be nice if it were really that simple.  Unfortunately, it
doesn't work for resolutions as low as that of a screen.
Screen-resolution fonts generated by Metafont would be unusable.  (The
screen-resolution fonts that the original Metafont generated were worse
than unusable; they were undecipherable by anyone except Knuth.
Metafont II might be somewhat better, but still not at all usable.)

       I admit that there might be problems generating (readable) small
    fonts with this approach. It could be tried and should be solvable.

We did try.  A few years ago, one of our most skilled developers joined
forces with some extremely skilled font experts at Bistream, Inc, to
develop software to scan-convert fonts from Bitstream's outline form
down to screen-resolution rasters.  Bitstream, as you may know, is a
company whose sole business is selling digitized fonts.  They primarily
supply several phototypesetter manufacturers, and their experts are some
of the best in the typography world.

It turns out to be an extremely tough problem.  The software is so
sophisticated that I'm sure it deserves the title "expert system" a lot
more than many other things that are called "expert systems" these days.
The software needs to know, for example, that the character that it's
converting right now is a lower-case "h", and it has to find and
recognize thick stems, thin stems, serifs, and so on.  We developed the
software to the point where it was doing a pretty good job, and turned
it over to Bitstream.  They acquired some Symbolics machines and hired a
hacker from the MIT AI lab, and further developed the software.  They
improved it more, and got it doing a better job.  Even now, in order to
get a screen-resolution font that looks good, you have to run FED on the
output of this program (or pay Bitstream extra to do so for you, for
your particular output device -- not all screens are the same!).

By the way, the Symbolics/Bitstream scan-conversion software does an
excellent job at LGP2 resolution.  Our documentation set is typeset in
Century Schoolbook on an LGP2, using such a font, downloaded from a
Symbolics machine.  The resulting typographic quality is higher than
that provided by the LGP2 itself, which is using on-the-fly
scan-conversion.  (You might not notice the difference if you're not
"into" typefaces, though, since even the built-in fonts are pretty good;
I couldn't tell the difference easily.)

You mentioned compatibility with future devices.  We don't expect this
to be a problem, because we expect that providers of future devices will
also provide the usual typefaces along with the devices.  Things have
always worked this way in the phototypesetter field, and now they work
this way for printers such as the LGP2 as well.  Alternatively, we might
use fonts scan-converted from Bitstream outlines.

I hope this helps explain what's going on in Genera.  As RWK said, we'd
still appreciate hearing more about what kind of application you're
working on, and what your requirements are in this area.  Thanks.

-- Dan