Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!shelby!neon!rokicki
From: rokicki@Neon.Stanford.EDU (Tomas G. Rokicki)
Newsgroups: comp.text.tex
Subject: Re: Why not change METAFONT to produce pk fonts?
Message-ID: <1990Nov27.002915.9450@Neon.Stanford.EDU>
Date: 27 Nov 90 00:29:15 GMT
References: <527@van-bc.wimsey.bc.ca> <1990Nov24.204011.20458@ioe.lon.ac.uk>
Organization: Computer Science Department, Stanford University
Lines: 35


>>Has anyone considered changing METAFONT's output font format from gf
>>to pk fonts?  What are the drawbacks of doing this?

>It's a good question.  However, the GF format *is* more generic than
>PK.  For one thing, a PK file cannot include MF specials.

A PK file can indeed contain the various types of specials that a GF
file can include.  The only restriction is that a PK file cannot
contain specials *during* a character, only between them, but since
METAFONT only generates specials between characters, this is not a
problem.

It's actually not difficult to modify METAFONT to generate PK files
directly; it's just not standard.  (And there are serious doubts as to
whether such a program can be called METAFONT.)

The first difficulty is that the PK format specifies the length of
each character as part of the character preamble (so it can be `skipped'
easily with no interpreter overhead); this length can be supplied by
generating the character in an internal buffer and then filling in the
preamble.

On the other hand, running gftopk after MF is easy.  If you are just
generating fonts, a script such as MakeTeXPK (supplied with dvips)
should hide the call to MF and gftopk from you . . .

Also note that the PK format was designed *after* MF was most of the way
through testing, and Knuth didn't want to make such a radical change so
late in the design cycle.

Finally, GF format fits in better with DVI format, in that it is a
byte-oriented format.  Of course, this is not a `real' advantage.

-tom