[comp.text.tex] Why not change METAFONT to produce pk fonts?

jtc@van-bc.wimsey.bc.ca (J.T. Conklin) (11/22/90)

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

	--jtc
-- 
J.T. Conklin	Toolsmith, Language Lawyer
		UniFax Communications Inc.
		...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca

teexdwu@ioe.lon.ac.uk (DOMINIK WUJASTYK) (11/25/90)

In article <527@van-bc.wimsey.bc.ca> jtc@van-bc.wimsey.bc.ca (J.T. Conklin) writes:
>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.  "Eh?" I hear
you cry.  Well, if you print out smoke proofs of MF characters, then
Knuth has set up macros in the plain and cm bases that use specials
extensively to format the output.  The "byline" telling what the
character is, and several other features, are all done with specials.

There are more substantive issues too, but I don't have my MF book to
hand, and I can't remember them.

Perhaps Tom Rokicki, who created the PK format, could chip in?

Dominik

gm@wsrcc.com (Greg McGary) (11/26/90)

jtc@van-bc.wimsey.bc.ca (J.T. Conklin) writes:
>Has anyone considered changing METAFONT's output font format from gf
>to pk fonts?  What are the drawbacks of doing this?

GF format contains "specials" in addition to the raster.  Specials are
not included in the PK format, since only the raster is typically used
by DVI drivers for document production.  So, PK is *not* a substitue for
GF.  The question now becomes: Has anyone considered changing the GF
format to use the compression techniques employed by the PK format?  At
this late date in the evolution of METAFONT, I imagine that Knuth (and
the rest of the TeX/MF community) is more concerned about preserving
stable, standard interfaces, than saving the CPU cycles it takes to
convert GF to PK.  I also doubt that anyone is eager to rewrite
GFtoDVI, GFtype, or any of the other MFware tools that understand the
GF format.  Again, stability of standard interfaces is a higher
priority than micro-efficiencies.
-- 
Greg McGary		gm@wsrcc.com -or- uunet!wsrcc!gm
(703) 318-8698		10310 Main Street, #109, Fairfax, Virginia  22030

mdeck@acsu.buffalo.edu (Mary Deck) (11/27/90)

In article <1990Nov25.194312.16829@wsrcc.com> gm@wsrcc.com (Greg McGary) writes:
>jtc@van-bc.wimsey.bc.ca (J.T. Conklin) writes:
>>Has anyone considered changing METAFONT's output font format from gf
>>to pk fonts?  What are the drawbacks of doing this?
>
>GF format contains "specials" in addition to the raster.  Specials are
>not included in the PK format, since only the raster is typically used
>by DVI drivers for document production.  So, PK is *not* a substitue for
>GF.  ...

Ok, then, how about having PK be the default output format, and having
a switch for GF format output?  Since PK format is used by almost
everything, I wouldn't think that this is too far fetched.  And when
one is building hundreds of fonts, it would (IMHO) save a lot of time
and make a lot of sense to create the correct format in one pass.

				.......Mary
---
Mary M. Deck
Student Assistant, User Services  |  Internet:  mdeck@cs.buffalo.edu 
University Computing Services     |  uucp:      rutgers!ub!mdeck
SUNY at Buffalo                   |  Bitnet:    mdeck%cs.buffalo.edu@ubvms

rokicki@Neon.Stanford.EDU (Tomas G. Rokicki) (11/27/90)

>>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

ken@csis.dit.csiro.au (Ken Yap) (11/27/90)

>Ok, then, how about having PK be the default output format, and having
>a switch for GF format output?  Since PK format is used by almost
>everything, I wouldn't think that this is too far fetched.  And when
>one is building hundreds of fonts, it would (IMHO) save a lot of time
>and make a lot of sense to create the correct format in one pass.

In my *experience* the time for the gftopk conversion was a tiny
fraction of the time spent by metafont. If it bothers you that it
takes two passes, why just write a wrapper program to call mf, then
gftopk then you don't see the stuff under the bonnet. :-)

Sure one pass is neater, but it's this way because pk was designed
after mf and gf.  It's also not an issue worth worrying about.

fj@iesd.auc.dk (Frank Jensen) (11/27/90)

In article <...> gm@wsrcc.com (Greg McGary) writes:

   jtc@van-bc.wimsey.bc.ca (J.T. Conklin) writes:
   >Has anyone considered changing METAFONT's output font format from gf
   >to pk fonts?  What are the drawbacks of doing this?

   GF format contains "specials" in addition to the raster.  Specials are
   not included in the PK format, since only the raster is typically used
   by DVI drivers for document production.  So, PK is *not* a substitue for
   GF. [...]

The PK format allows "specials" to occur between individual character
packets (but not inside the raster data itself).  I'm not sure whether
"proof" output from Metafont contains specials in the "middle" of a
character; certainly(?), it doesn't need to do that as the proof
annotations could easily be specified outside the raster part of the
data.

So, I would conclude that the PK format could be used as a substitute
for the GF format.

   The question now becomes: Has anyone considered changing the GF
   format to use the compression techniques employed by the PK format?  At
   this late date in the evolution of METAFONT, I imagine that Knuth (and
   the rest of the TeX/MF community) is more concerned about preserving
   stable, standard interfaces, than saving the CPU cycles it takes to
   convert GF to PK.  I also doubt that anyone is eager to rewrite
   GFtoDVI, GFtype, or any of the other MFware tools that understand the
   GF format.  Again, stability of standard interfaces is a higher
   priority than micro-efficiencies.
 

That's a better argument.

   -- 
   Greg McGary		gm@wsrcc.com -or- uunet!wsrcc!gm
   (703) 318-8698	10310 Main Street, #109, Fairfax, Virginia  22030


-----
Frank Jensen	fj@iesd.auc.dk
Department of Mathematics and Computer Science
Aalborg University
DENMARK