chris@mimsy.UUCP (Chris Torek) (12/13/86)
In article <187@sol.warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes: >... the TeX cm* fonts [on the] 2700 ... are really weedy. ... >I assume this is a write-white vs. write-black problem, so >that's my first question - Am I right ? Yes. >Now, I have all the metafont input to these fonts, so I'm thinking it must >be possible to produce some more appropriate fonts. It is indeed possible. Don Knuth, genius that he is, foresaw this problem when he wrote Metafont84 and the Computer Modern fonts. Either that or it hit him in the face after he wrote the original Metafont. :-) Anyway, what you need to do is to define a `mode' for the 2700. I have not yet had time to play with Metafont, so I am not sure just what these are, but here is the `Imagen 8/300' mode: mode_def imagen = % imagen mode: for the Imagen 8/300 (Canon engine) proofing:=0; % no, we're not making proofs fontmaking:=1; % yes, we are making a font tracingtitles:=0; % no, don't show titles in the log pixels_per_inch:=300; blacker:=0; % Canon engine is black enough fillin:=.2; % and it tends to fill in diagonals o_correction:=.6; % enddef; `blacker', `fillin', and `o_correction' are the knobs to tweak. I believe `blacker' controls a generic pixel-emphasiser, while `fillin' adjusts diagonal lines, and `o_correction' is for `overshoot': lines that print slightly longer than intended. This problem brings up another point (which, incidentally, is the reason I am posting this, rather than mailing it): One set of fonts is not sufficient. If fonts are to be downloaded---which seems unavoidable, at least for now---then any site that maintains more than one kind of print engine will need more than one rasterisation of each font. At present it is possible to do this, but it is an administrative nightmare. Each device driver has its own idea of where to find fonts; in many cases this is a compiled-in pathname such as `/usr/lib/tex/fonts'. Other drivers allow a path variable, e.g., PXLPATH in my older C-TeX drivers. This allows a user to override the compiled-in path, to use, say, `/usr/lib/tex/fonts.2700'. I now think that this is too clumsy, especially given the recent proliferation of font file formats: GF, PK, PXL, Imagen's RST, and whatever else is out there. The solution I have adopted now is better, but (I think) still not ideal. I have a single configuration file `/usr/lib/tex/fontdesc' that looks something like this: # # C-TeX font configurations # # N.B.: choose only one of `box' or `blank' TFM fonts. # # %f expands to the font, %m to the appropriate magnification. # SLOP is a hack, to pick up `nearby' fonts in case of roundoff # error in magnification computations. # current directory always searched first # TYPE SPEC SLOP PATH font pk * 2 %f.%mpk font gf * 2 %f.%mgf font pxl * 2 %f.%mpxl font box * 0 %f.tfm # `invisible' SLiTeX fonts font invis * 0 /usr/lib/tex/fonts/invis/%f.tfm # Canon (Imagen 8/300, et alii) fonts font pk canon 2 /usr/lib/tex/fonts/canon/%f/%f.%mpk font gf canon 2 /usr/lib/tex/fonts/canon/%f/%f.%mgf # Raven (Xerox 2700, et alii) fonts font pk raven 2 /usr/lib/tex/fonts/raven/%f/%f.%mpk font gf raven 2 /usr/lib/tex/fonts/raven/%f/%f.%mgf # If all else fails, draw boxes. font box * 0 /usr/lib/tex/fonts/%f.tfm The font description file name can be set in the environment variable TEXFONTDESC. The major problem with this scheme is that it is difficult to set up a font description file. Once that has been done, however, it is easy to describe any arrangement of fonts. I hope that this scheme will prove useful, and that others will implement something compatible in their drivers. (The C-TeX font code is freely available to software developers, or will be when I can get at it again: it is on a machine that is down with hardware troubles.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu