samperi@marob.masa.com (Dominick Samperi) (09/23/89)
Considering the fact that many device drivers (dvi2ps, dvijet, dvi2ln3, etc.) look for different types of pixel files (gf,pk,pxl), how is one to avoid keeping a full complement of pixel files for all interesting sizes, three times? Is there a set of drivers (for postscript and laserjet, at least) that use the same type of pixel files? Wouldn't it be reasonable if everyone just used gf files, to avoid confusion? -- Dominick Samperi -- Citicorp samperi@Citicorp.COM uunet!ccorp!samperi
ken@cs.rochester.edu (Ken Yap) (09/23/89)
|Considering the fact that many device drivers (dvi2ps, dvijet, dvi2ln3, |etc.) look for different types of pixel files (gf,pk,pxl), how is one |to avoid keeping a full complement of pixel files for all interesting |sizes, three times? Is there a set of drivers (for postscript and Patronize only the drivers that use pk files. |laserjet, at least) that use the same type of pixel files? Wouldn't it |be reasonable if everyone just used gf files, to avoid confusion? No. Pxl can be junked. Gf has to be retained because MF generates that and also it is easy to generate. Pk is the most compact but is complicated to decode, but the reading routines have to be written only once (borrow code from MC-TeX, or the Utah drivers).
chris@mimsy.UUCP (Chris Torek) (09/24/89)
In article <1989Sep23.154108.13738@cs.rochester.edu> ken@cs.rochester.edu (Ken Yap) writes: >... Gf has to be retained because MF generates that >and also it is easy to generate. Pk is the most compact but is >complicated to decode, but the reading routines have to be written only >once (borrow code from MC-TeX, or the Utah drivers). Actually, PK fonts are easier to read than GF. The GF format has two design botches (actually, they are tied together): - bounding boxes are not minimal and - bounding boxes are given as closed (rather than half-open) intervals, but MF does not give a completely empty box as [x..x-1][y..y-1] (a pair of empty closed intervals) but rather as [x..x][y..y] (usually 0..0). This box encloses one point. If bounding boxes were always minimal, the second would have to be false (by definition); or it could be the only special case. As it is, font readers have to be prepared for a bounding box that allows 100x100 pixels but actually encloses 3x15 or whatnot. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jbw@unix.cis.pitt.edu (Jingbai Wang) (09/24/89)
In article <251AB757.452@marob.masa.com> samperi@marob.masa.com (Dominick Samperi) writes: >Considering the fact that many device drivers (dvi2ps, dvijet, dvi2ln3, >etc.) look for different types of pixel files (gf,pk,pxl), how is one >to avoid keeping a full complement of pixel files for all interesting >sizes, three times? Is there a set of drivers (for postscript and >laserjet, at least) that use the same type of pixel files? Wouldn't it >be reasonable if everyone just used gf files, to avoid confusion? METAFONT produces TFM and GF files, and GF format can converted into PK and PXL formats. According the trend, PXL is already obsolete, and the standard is going be to PK instead of GF. Pk files are much smaller than GF files carrying exactly the same amount of information and all in binary. Why should we still stick to GF? After TeX 2.94 (UNIX), I think the standard font files are distributed in PK instead of GF. Beebe's colloection of dvi->* can recognize all of the formats, and you can find them in science.utah.edu. JB Wang jbw@pittvms.bitnet jbw@cisunx.UUCP
samperi@marob.masa.com (Dominick Samperi) (09/25/89)
The responses to my gf,pk,pxl posting unanymously suggested that the compressed pk font files should be used. The nicest driver that we use is dvi2ps (other drivers are rarely used), since it handles psfig, generates transportable PostScript output, has convenient options, etc. (a similar program, dvips, does not seem to handle psfig figures). Unfortunately, dvi2ps will handle gf or pxl font files, but NOT pk format fonts. I have version 2.11 of dvi2ps. Is there a version that will handle pk fonts? If not, could someone give a few pointers on how pk support could be added? -- Dominick Samperi -- Citicorp samperi@Citicorp.COM uunet!ccorp!samperi
jbw@unix.cis.pitt.edu (Jingbai Wang) (09/27/89)
In article <251D440F.1E2C@marob.masa.com> samperi@marob.masa.com (Dominick Samperi) writes: >The responses to my gf,pk,pxl posting unanymously suggested that the >compressed pk font files should be used. The nicest >driver that we use is dvi2ps (other drivers are rarely used), since >it handles psfig, generates transportable PostScript output, has >convenient options, etc. (a similar program, dvips, does not seem >to handle psfig figures). Unfortunately, dvi2ps will handle gf or pxl >font files, but NOT pk format fonts. I have version 2.11 of dvi2ps. Is >there a version that will handle pk fonts? If not, could someone give >a few pointers on how pk support could be added? I am already very tired of advertising it. There is a version of dvi2ps that can be ftped from june.cs.washington.edu that can handle PK format, psfig nad much much more. It is officially under ~/tex in name of w_dvi2ps (since my last name is Wang), but I always wonder why the new version is left outside in ~/tmp. Thus, if you do ftp, get the one from ~/tmp under the name of dvi2ps.tar.Z. The on-line help of dvi2ps and TeX/LaTeX is built in this dvi2ps. JB Wang