ken@csis.dit.csiro.au (Ken Yap) (04/08/91)
>Last things first; creating a whole rasterized metafont in a nice >selection of sizes can take literal days; I ran mine overnight to get >just a few sets of fonts built. You _really_, _really_ don't won't this >overhead in your printing loop, which is why TeX/Metafont users have >megabytes of already rasterized fonts online and ready to use. Metafont >makes lovely fonts, but it makes a snail look turbocharged. Yes, running MF to make fonts is slow, especially if you don't have a workstation, but many DVI to foo converters have scripts that will run MF on the fly and *thereafter the filter uses the newly made pk file*. So if the users are happy to wait a little while on their first print run, you're ok. Otherwise, the installer should run a bunch of documents through the system (you don't actually have to print the documents, just redirect the PDL output to /dev/null) to make the most commonly occuring fonts.
dhosek@euler.claremont.edu (Don Hosek) (04/09/91)
In article <1991Apr7.231813.10310@csis.dit.csiro.au>, ken@csis.dit.csiro.au (Ken Yap) writes: >>Last things first; creating a whole rasterized metafont in a nice >>selection of sizes can take literal days; I ran mine overnight to get >>just a few sets of fonts built. You _really_, _really_ don't won't this >>overhead in your printing loop, which is why TeX/Metafont users have >>megabytes of already rasterized fonts online and ready to use. Metafont >>makes lovely fonts, but it makes a snail look turbocharged. > Yes, running MF to make fonts is slow, especially if you don't have a > workstation, but many DVI to foo converters have scripts that will run > MF on the fly and *thereafter the filter uses the newly made pk file*. > So if the users are happy to wait a little while on their first print > run, you're ok. Otherwise, the installer should run a bunch of > documents through the system (you don't actually have to print the > documents, just redirect the PDL output to /dev/null) to make the most > commonly occuring fonts. It's not too bad on my 25mhz 386 messy dos box. I do strongly recommend the approach of only generating fonts as they're needed. If you primarily use LaTeX and are willing to assume that few documents will load fonts (which is not that unreasonable of an assumption) a fairly small archive can be created. For an in-house pc TeX distribution I did recently, I created a font set containing all the fonts referred to in fontdef.ori (M&S font selection ymir.claremont.edu [anonymous.tex.inputs.latex-contrib]), all the CM fonts at magstep0, all the preloaded magnifications of plain.tex and all the actually defined fonts of plain.tex at magsteps 0, half, 1 throught 5. The whole thing lharc'd was almost small enough to fit on a single 1.4M floppy (six archives of 300-359K each). Unpacked it took around 2.5M. My personal system currently has a mere 815K of fonts in 143 files which has covered a very large variety of documents. Incidentally, this approach also makes it practical to do things like arbitrary scaling of MF-based fonts (I'm currently making Kanji fonts with the jemtx package (see ymir.claremont.edu [anonymous.tex.babel.japanese]) at sizes from 6 to 10pt with 1/30pt intervals as necessary in an application where text must be fit into an arbitrarily sized region (bottle labels). -dh -- Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique.