[comp.text] METAFONT & PostScript

smithda@cpsvax.cps.msu.edu (Daniel Smith) (10/20/88)

As I was working on installing a new DVI driver to handle resident
PostScript font, I began to think about the relationship between
METAFONT and PostScript.  It occured to me that the two do about the 
same thing, its just that they do it at different times.  METAFONT
translates source code describing fonts into bit maps, and so
does PostScript.  The difference is that PostScript does it when the
document is printed, and METAFONT does it when the font itself is
created.  

I began to wonder if anyone has tried to make METAFONT spit out
PostScipt outline fonts?  Such a scheme would seem to combine the best
of both worlds.  METAFONT is a real programming language, written by
a computer scientist.  This makes is "easy" to describe
fonts accurately and formally.  PostScript on the otherhand
is not very easy to read.  While it is possible to make sense out
of PostScript code, it is not as good as METAFONT.  

Here is a list of pros and cons for such a scheme:

METAFONT doing just what it does now:
   * The fonts produced will work on just about ANY printer.  One
     does not need a PostScript printer to use TeX/METAFONT.
   * However, these fonts take up A LOT of disk space, espically
     when compared to PostScript fonts.  For example, a PostScript
     outline for for say Times-Roman is basically one file.  That is
     one file for ALL sizes of Times-Roman, for ALL device resolutions.
     Since the PostScript software in each printer has "lots of smarts"
     this method works.
   * DVI drivers are non-trivial pieces of software.  Each driver must
     deal with the bitmaps in the GF/PK/PXL files and convert those
     to a scheme for the current printer.

METAFONT producing PostScript
   * A LARGE savings in disk space can be realized, because very few
     files are required for a font.
   * Of course, the output is only of use to those who have PostScript
     printers.
   * PostScript is fast becoming a standard for desktop-publishing.
   * Writing a DVI driver is quite simple.  One no longer needs to
     deal with bitmaps of fonts.  The DVI file and TFM files for the
     fonts are all that are needed.  In some cases, the TFM may not
     even be necessary.
   * TeX fonts (Computer Modern) behave just like any other
     PostScript font.
=========================================================================
J. Daniel Smith                           smithda@cpsvax.cps.msu.edu
Michigan State University

"An average English word is four letters and a half.  By hard, honest
labor I've dug all the large words out of my vocabulary and shaved it 
down till the average is three and a half..."
      Mark Twain
=========================================================================

sean@ms.uky.edu (Sean Casey) (10/23/88)

In article <902@cps3xx.UUCP> smithda@cpsvax.cps.msu.edu (Daniel Smith) writes:
[A good article comparing METAFONT and Postscript]

I'm no great fan of either, but I have to point out that METAFONT does a lot
more to generate fonts of a certain size than Postscript does. You can always
send font outlines to Postscript for scaling, but the results aren't going to
look as good as if you let METAFONT do it.

I'd like to see the functionality of both combined, but I'm not sure how it
could be done. I don't like the idea of storing bitmaps on the host system
because (1) it uses a lot of disk space and (2) someone always seems to want
something in a size that isn't there.

If you generate stuff on the fly, you either do it really slow and good with
METAFONT, or fast but not quite so good with Postscript.

Perhaps this will all be a moot point in the future, when output device
resolution will be so high that finicky differences in rasterization won't
be visible.

Sean
-- 
***  Sean Casey                        sean@ms.uky.edu,  sean@ukma.bitnet
***  The Hacker from Spaaaaaaaaace.    {backbone|rutgers|uunet}!ukma!sean
***  U of K, Lexington Kentucky, USA  ..where Christian movies are censored.
***  ``The World... she's a flat! She's a round! Flat! Round! Flat! Round!''

hess@iuvax.cs.indiana.edu (Caleb Hess) (10/24/88)

In article <902@cps3xx.UUCP> smithda@cpsvax.cps.msu.edu (Daniel Smith) writes:
>...  I began to think about the relationship between
>METAFONT and PostScript.  It occured to me that the two do about the 
>same thing, its just that they do it at different times.  METAFONT
>translates source code describing fonts into bit maps, and so
>does PostScript.

One very important difference is that METAFONT makes no attempt to be 
scalable.  While it might be possible to make METAFONT produce 
PostScript code, the resulting fonts would not behave like normal 
METAFONT fonts, which are designed for one point size, or like Adobe's 
fonts, which contain coded-in scaling hints.

mrd@sun.soe.clarkson.edu (Michael DeCorte) (10/26/88)

smithda@cpsvax.cps.msu.edu (Daniel Smith) writes:

>METAFONT translates source code describing fonts into bit maps, and so
>does PostScript.  The difference is that PostScript does it when the
>document is printed, and METAFONT does it when the font itself is
>created.  I began to wonder if anyone has tried to make METAFONT spit
>out PostScript outline fonts?

[lots of other useful observations]

I have been thinking of how to do this for quite some time now.  There
are a few things that have to be first examined: (I am calling these
things .psf for PostScript fonts)

1) As I understand it, under postscript, when you scale a font you are
doing the equivalent of magstep under TeX.  This is unacceptable for
TeX.  Therefore it won't be possible to have cmr.psf but there is
nothing to stop you from having cmr10.psf.  There are several
advantages to this: 

a) it is portable between different PS printers of different
resolutions

b) it should be portable between write-white and write-black engines

c) the .psf file may be smaller than the cmr10.pk but I am only
guessing

d) the cmr10.psf file will DEFINITELY be smaller than the cmr10.pk @
magstep 0,0.5,2..5. (I really like this)

e) it may be faster to download as you don't have to download multiple
mag of the same font and it may even be possible to make the cmr10.psf
very small by having a set of ps libraries that you download before
any fonts

2) if we ever get a PostScript previewer on our Sun, I won't have to
have fonts at every size and dots/inch know to mankind

3) this could be generalized for vector output devices in general.
Wouldn't it be nice to be able to use that 4105 to preview?  I suppose
you could get plotters going also.

4) internal PostScript fonts will be easier to handle I assume, as
they will be handled the same as external fonts.

5) it will be necessary to use the .tfm files or duplicate them in the
.psf file. I think it is better to just use the .tfm file

6) this is probably portable but... Donald Knuth spent a lot of time
figuring out how to make a { look like a }.  Did Adobe?  Rounding
leads havoc on low res fonts.

7) we will have to redo LaTeX's definition of fonts.  With all of
these fonts that we now have available, it will be necessary to have a
font defined in three parts: family, style, size.  

Eg. right now we have Computer Modern, Italic, 12.  We will have
Helvetica, Bold, 10.  This means that you would to choose a font you
would do something like \rm\it\large or \hv\bf\normalsize.  If you
only want to change the style of the font from bold to italic but
nothing else you would only do \it. Likewise, to change the family
but not the size or style you would only do \rm.  One minor problem
is that \rm stands for Computer Modern not Roman. 

9) If the .psf fonts are defined correctly, it will be possible to
use fonts from TeX in non TeX stuff.

--

Michael DeCorte // (315)268-2292 // P.O. Box 652, Potsdam, NY 13676
Internet mrd@sun.soe.clarkson.edu  // Bitnet   mrd@clutx.bitnet        
------------------------------------------------------------
Clarkson Archive Server
archive-server@sun.soe.clarkson.edu
archive-server%sun.soe.clarkson.edu@omnigate.bitnet
dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server
------------------------------------------------------------

john@trigraph.UUCP (John Chew) (10/28/88)

In article <10417@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes:
>I'm no great fan of either, but I have to point out that METAFONT does a lot
>more to generate fonts of a certain size than Postscript does. You can always
>send font outlines to Postscript for scaling, but the results aren't going to
>look as good as if you let METAFONT do it.
...
>If you generate stuff on the fly, you either do it really slow and good with
>METAFONT, or fast but not quite so good with Postscript.

The criticism of PostScript is misleading.  Certainly if you create
a pure bitmap or pure outline PostScript font, it will be scaled as
a bitmap or an outline: poorly.

If however you design a proper algorithmic PostScript font (one 
which makes rasterization decisions based on the current font size),
then the result will be every bit as good as, and quite possibly
identical to that of METAFONT.

The automatic translation of METAFONT source to PostScript source
would not be an impossible task.  My guess is it would be about
as difficult as and remarkably similar to writing a Pascal to
Forth translator.

John Chew
-- 
john j. chew, iii   		  
trigraph, inc., toronto, canada   {uunet!utai!utcsri,utgpu,utzoo}!trigraph!john
dept. of math., u. of toronto     poslfit@{utorgpu.bitnet,gpu.utcs.utoronto.ca}
Opinions?  All mine.  My company never yawns openly.