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.cateexdwu@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