[mod.computers.laser-printers] Scribe Metafont file format?

dplatt@TEKNOWLEDGE-VAXC.ARPA.UUCP (02/27/87)

Recently, a program called "drawimp" was posted to the Macintosh
newsgroups by its author, Allan Weber of USC.  This program is designed
to convert a Macintosh "MacDraw" file into Impress format, so that it
can be printed on an Imagen laser-printer.  I'm trying to get this
program to work, and could use some help.

So far, the program works as documented, except for the conversion of
text strings to Impress format.  The program as-released is designed to
work with the TeX Metafont files (of the "cm" variety).  Our site
doesn't have TeX, but does have Scribe.  For some reason, drawimp isn't
able to interpret the Scribe metafont files, and as I lack
documentation on their format I'm not sure what changes I need to
make.

Originally, drawimp opens and reads Metafont files in the
/usr/lib/tex/fonts directory, and selectively downloads the necessary
glyphs to the Imagen printer.  I was able to modify drawimp to
accomodate the different location and names of the Scribe font files,
but the files that we have in our /usr/lib/scribe/fonts directory seem
to have a different internal format than what drawimp is expecting.  As
released, drawimp expects files named something like "cmr10.MMMMpxl",
where MMMM is the magnification factor multiplied by 1000.  The Scribe
font files are named (e.g.) "cmr10.rMM", where MM is the magnification
factor multiplied by 10.  So far so good... but when drawimp tries to
read the "pixel tail" structure at the end of the file, it doesn't see
what it expects, mumbles a warning, tries to load the raster
definitions anyhow, becomes extremely confused, generates a segment
fault, and dumps core.

So, some questions:

1) Is there a difference in the formats of the "pxl" files expected by
   drawimp (and, apparently, TeX also), and the "r" files used by Scribe?

2) Are the structures of "pxl" and "r" files documented, and can anyone
   send me a copy via email?

3) Has anyone out there already done what I'm attempting to do (i.e.
   convert drawimp to work with Scribe, rather than with TeX)?

advTHANKSance for your help in this matter!

                Dave Platt

Internet:  dplatt@teknowledge-vaxc.arpa
Usenet: {hplabs|sun|ucbvax|seismo|uw-beaver|decwrl}!teknowledge-vaxc.arpa!dplatt
Voice: (415) 424-0500
USnail: Teknowledge, Inc.
        1850 Embarcadero Road
        Palo Alto, CA  94303

Science is what happens when preconception meets verification.

A.ERIC@GSB-WHY.STANFORD.EDU (Eric M. Berg) (03/08/87)

In talking about METAFONT (and other) font files, you have to distinguish
several types of file formats:  pixel files, raster files, "generic font" 
files, and METAFONT source files.  Here's a brief introduction written
by a non-expert (me!):

.MF files:  source file containing the METAFONT code for a font design;
an ASCII file which is processed by the METAFONT program to create....

.GF ("generic font") files: the font file format created by METAFONT;
an 8-bit file.  Most up-to-date printer "device drivers" used with TeX 
are capable of using .GF files directly, but some of the older ones
must get their font information from....

.PXL files: another 8-bit representation of the font, created from the .GF 
file by running the program GFtoPXL.  The original METAFONT (released in 1978)
created .PXL files directly, and they are used by lots of older-vintage device
drivers, as well as (apparently) some newer ones like "drawimp".  However, the
very first Imagen printers (the Imagen Imprint-10) used still another font
file format....

Raster Files (e.g. CMR10.R10): yet another 8-bit representation of the font,
created from the .PXL files by running the program PXLtoRST.

Furthermore, each individual file-name includes some numbers indicating
it's "size", the numbers being a (different) function of the font
"design size", the magnification of that particular font file, and the
dots-per-inch of the printer it was generated for.

Now... for some reason, Scribe continues to use Raster (rather than .GF or
.PXL) files in creating .IMP files for Imagen printers.  Moreover,
Scribe supports only the "old" (circa-1978) Computer Modern fonts and
not the "new" (circa-1985) Computer Modern fonts, and some of the character
positions within the fonts changed between the two versions.

I don't have the references to file formats at hand, but I know they're
available.  However, the easiest approach would probably be to get a set
of the .PXL files rather than trying to re-write "drawimp" to use raster
files.

					Eric Berg
					Graduate School of Business	
					Stanford University
-------

X230GV@TAMVM1.BITNET.UUCP (03/10/87)

Well, Eric, your survey of font file formats was correct (as far as I can
tell), but a little incomplete.  I realize that if we listed all font file
formats in use we could clog the whole network, but you left out one important
one related to Metafont: packed files.

The packed file format was developed by Tomas Rockiki after gathering
statistics on many pixel files.  The PXL format was very wasteful of space
(by the admission of its authors), but the packed file format is extremely
space-efficient.  I don't know any exact stats, but I've observed that packed
files (also called PK files) are usually about 60% of the size of GF files
(which in turn are *much* smaller than PXL files).  Four PK utilities by
Rockiki are on the distribution tapes: GFtoPK, PKtoPX, PXtoPK, and PKtype.

One might expect that the packing and unpacking process would slow things
down, but it seems not to.  The packing algorithm is fairly simple, and
on most systems you save about as much on I/O as you lose in unpacking.
Many DVI drivers are now using PK files, and old ones are fairly simple to
convert; some code from PKtoPX can be patched directly into a WEB driver
without much difficulty.  I believe it was Rick Furuta or Pierre MacKay who
observed in a TUGboat last year that this is a good argument for writing
TeX related software in WEB.

Well, this message got long fast; I'd better fire it off before it gets
unmanageable . . .

Regards,
Glenn Vanderburg
X230GV@TAMVM1.Bitnet