% Compiled 1991, 92, 93, 94 by Karl Berry. This file is not copyrighted % and may be used freely. You can retrieve the latest version by ftp as % {\tt ftp.cs.umb.edu:pub/tex/modes.mf}. % % You can run this file through {\tt mft} to generate a \TeX\ % file, if you like reading typeset output instead of computer screens. % % Feel free to change the definitions of |localfont|, |screen_cols|, and % |screen_rows| at the end of file (see explanations below). % % If you make a new |mode_def|, please send it to {\tt karl@cs.umb.edu}. % Please mention what fonts at what sizes you tested it on. This will % help other people wondering where particular values came from. % Ideally, you would try normal, bold, and italic variants, at sizes % around 5$\,$pt, 10$\,$pt and 15$\,$pt. % %%% def mode_def %%% addto font_size coding_scheme font_face_byte landscape landscape_ % % @mffile{ % author = "The Metafont community", % version = "2.3", % date = "Sun Apr 16 07:47:48 EDT 1995" % filename = "modes.mf", % contact = "Karl Berry", % email = "karl@cs.umb.edu" % address = "135 Center Hill Rd. // Plymouth, MA 02360" % checksum = "1783 8695 63796", % codetable = "ISO/ASCII", % supported = "yes", % docstring = " % % This file is a collection of (putatively) all extant \MF\ modes. % % If you have a device which is not mentioned in this file, the best % thing to do is try to find a device with similar resolution (search % for the appropriate lines), and see if that suits (a list of fonts to % try is given above). Otherwise, methods for fiddling with the % parameters are described in detail below. % % Unfortunately, the number of modes eats up a lot of memory; if your % \MF\ has not increased the table sizes, you may need to remove some of % the modes from this file (please name it something else then, e.g., % {\tt local.mf}). If you can suggest a way to redefine |mode_def| % and/or |mode_setup|, even better; right now, the amount of memory used % is approximately four times the length of the |mode_def| names. % % The primary names are all eight characters or less, and strictly % lowercase. This makes it feasible to use them for portable directory % names. The synonyms are historical equivalents. % % It also makes definitions to put specials identifying the mode % in the \MF\ GF output, and to put the coding scheme and other % so-called Xerox-world information in the TFM output. % % It also defines a macro |landscape| that inverts |aspect_ratio| and % changes |pixels_per_inch|, so you can say {\tt mode := whatever; % landscape; ...} to get landscape fonts. But I can't think of any % reasonable way to reflect the |landscape| in the directory name, so % there are also |mode_def|'s for the devices with non-square aspect % ratios in landscape mode. % % Finally, it has some code to handle write-white devices better; this % code comes into play if a |mode_def| includes the statement % |mode_write_white_setup_;|. This only works for those fonts which % follow Computer Modern's conventions for using |font_setup|. For % further discussion of write/white and white/black devices, see the % file ftp.cs.umb.edu:pub/tex/write-white, and also Pierre MacKay's % article in the proceedings of the 1991 Raster Imaging and Digital % Typography conference: % % \begingroup \tt % @String{proc-RIDT91 = "Raster Imaging and Digital Typography II"} % @String{pub-CUP = "Cambridge University Press"} % % @Inproceedings{Mackay:RIDT91-205, % author = "Pierre A. MacKay", % title = "Looking at the Pixels: Quality Control for 300 dpi % Laser Printer Fonts, especially {\MF}s ", % pages = "205--215", % crossref = "Morris:RIDT91", % } % % @Proceedings{Morris:RIDT91, % title = proc-RIDT91, % booktitle = proc-RIDT91, % year = "1991", % editor = "Robert A. Morris and Jacques Andr{\'e}", % publisher = pub-CUP, % address = pub-CUP:adr, % acknowledgement = ack-kb, % } % \endgroup % % This file is typically loaded when making a \MF\ base; for example, % the command line % {\tt inimf plain input modes dump} % makes a file {\tt plain.base} (or {\tt plain.bas}, or something like % that) with all the modes herein defined (plain itself defines modes % called |proof|, |smoke|, and |lowres|.) % % You can make the Computer Modern base with the command line: % {\tt inimf plain input modes input cmbase dump} % % On Unix systems, you then install the base file in the system % directory (/usr/local/lib/texmf/ini as distributed) as {\tt mf.base}. % TeX and Metafont use the name they were invoked as to determine the % format or base file to read; thus running {\tt mf} reads {\tt % mf.base}, running {\tt cmmf} reads {\tt cmmf.base}, and so on. {\tt % plain.base} and {\tt mf.base} should be the same file (i.e., a hard % link is ok), so the examples in the {\sl Metafontbook} work properly. % % A user selects a particular mode when s/he runs \MF, by assigning to % the variable |mode|. For example, % {\tt \char`\\mode:=cx; input cmr10} % sets up values appropriate for the CanonCX engine. % % If no mode is assigned, the default is |proof| mode, as stated in {\sl % The \MF book}. This is the cause of the ``{\tt .2602gf}'' files which % are the subject of periodic questions. The remedy is simply to assign % a different mode---|localfont|, for example. % % Every site should define the mode |localfont| to be a synonym for the % mode most commonly used. This file defines |localfont| to be |cx|. % The values for |screen_rows| and |screen_cols|, which determine how % big \MF's window for online output is, should perhaps also be changed; % certainly individual users should change them to their own tastes. % % This file defines {\tt ?} to type out a list of all the known % |mode_def|s (once only). % % Technically, a |mode_def| is a \MF\ definition that typically consists % of a series of assignments to various device-specific variables, % either primitive or defined in plain. These variables include the % following (page numbers refer to {\sl The \MF book\/}: % % |aspect_ratio|: the ratio of the vertical resolution to the horizontal % resolution (page 94). % % |blacker|: a correction added to the width of stems and similar % features, to account for devices which would otherwise make them too % light (page 93). (Write-white devices are best handled by a more % sophisticated method than merely adding to |blacker|, as explained above.) % % |fillin|: a correction factor for diagonals and other features which % would otherwise be ``filled in'' (page 94). An ideal device would % have |fillin=0| (page 94). Negative values for |fillin| typically % have either gross effects or none at all, and should be avoided. % % |fontmaking|: if nonzero at the end of the job, \MF\ writes a TFM file % (page 315). % % |o_correction|: a correction factor for the ``overshoot'' of curves % beyond the baseline or x-height. High resolution curves look better % with overshoot, so such devices should have |o_correction=1|; but at % low resolutions, the overshoot appears to simply be a distortion % (page 93). Here some additional comments about |o_correction|, % courtesy of Pierre MacKay (edited by Karl): % % At present, I find that |o_correction| works nicely at 80 pixels per % em, and gets increasingly disturbing as you move down towards 50 % pixels per em. Below that I do not think it ought to happen at all. % % The problem, of course, is that full |o_correction| is supposed to % occur only at the zenith and nadir of the curve of `o', which is a % small region at high resolution, but may be a long line of % horizontal pixels at medium resolution. The full |o_correction| % does not change a 300$\,$dpi {\tt cmr10}, but it changes a 21-pixel % high {\tt cmr12} to be 23 pixels high. The extra height and depth % is seen along a line of seven pixels at the bottom and five at the % top. This is a pronounced overshoot indeed. % % For high-resolution devices, such as phototypesetters, the values % for |blacker|, |fillin|, and |o_correction| don't matter all that % much, so long as the values are within their normal ranges: between % 0 and 1, with the values approaching 0, 0, and 1 respectively. % % |pixels_per_inch|: the horizontal resolution; the \MF\ primitive % |hppp| (which is what determines the extension on the GF filename, % as among other things) is computed from this (page 94). (An % ``inch'' is 72.27\thinspace pt in the \TeX\ world.) % % To be more precise, you can determine the resolution of a font given a % |mode_def| and a magnification |m| by simply multiplying % |pixels_per_inch| for that |mode_def| by |m|. (Your results may % differ from \MF's if you don't use equivalent fixed-point % arithmetic.) Then you can determine the number used in the name of % the GF font output by rounding. For example, a font generated at % |magstep(.5)| (which is $\sqrt{1.2}$, which \MF computes as 1.09544) % for a printer with |pixels_per_inch=300| will have a resolution of % 328.63312 dots per inch, and the GF filename will include the number % {\tt 329}. % % |proofing|: says whether to put additional specials in the GF file for % use in making proofsheets via, e.g., the utility program {\tt % GFtoDVI} (page 323--4). % % |tracingtitles|: if nonzero, strings that appear as \MF\ statements % are typed on the terminal (page 187). % % Neenie Billawala's article in the April 1987 issue of {\sl TUGboat} % describes how to test your printer for the best set of values for the % magic numbers above. Here are some brief comments on the subject, % courtesy of Rocky Bernstein, again edited by Karl: % % For medium-to-low resolution devices, you can first set the |blacker| % and |o_correction| to~0 and decide on a |fillin| value by looking at % the diagonal of a lowercase `z' in {\tt cmtt10}, or various % lines in LaTeX's line10 font. The diagonal should be the same % thickness as the horizontal bars of the `z'. Then I decide on the % |blacker| value, generally by checking the smaller fonts for too much % filling in. Finally, you can set the |o_correction| using the % guidelines suggested above. %" % } % Identify ourselves in the format file. base_version := base_version & "/modes 2.3"; % Here are useful macros (also called definitions) we use throughout. % First, some comments about how the |mode_defs| are constructed (from % {\tt rocky@panix.com}). In the past, |mode_defs| unconditionally % assigned a value to the various mode-dependent parameters. For % example, they contained an assignment |fontmaking:=1|, which tells % \MF\ to write a TFM file. % % But suppose you want to generate a font using all of the setup for % some mode |m|, but do not want to generate a TFM? One could create % another mode that doesn't have the assignment, but this seems a bit % wasteful since the rest of the code in the mode would be duplicated. % Furthermore, given the way the mode definitions were written, it was % not possible to change the mode parameters. To see why, I review how % a \MF\ run typically works. % % First, \MF\ is invoked with some base file to load. Then you might % want give additional instructions, such as |scrollmode|, or |mode:=cx|. % Next, you input a parameter file, say {\tt cmr10}. The parameter file % calls a driver file, such as {\tt roman}, with the command |generate % roman|. Finally, the driver finished by saying |bye| or |end|. Thus, % any additional commands you give after the input of the parameter file % are ignored. % % Usually, one of the first things a driver file does is to call % |mode_setup|. It is here that the mode parameters are set. (In our % hypothetical mode, it would be here that |fontmaking| is assigned.) % % To allow a flexible setting of |fontmaking|, we can make a simple % change: in the |mode_def|, first test to see if a value has been % defined prior and only make the assignment if not. That is: % |if unknown fontmaking: fontmaking := 1; fi|. % % Alas, this doesn't work. Primitives, like |fontmaking|, are always % |known|. So instead we create ``guard'' variables, specifically, % |mode_guard_.fontmaking|; we set the guard when we assign the % parameter. Then we test whether the guard is |known| before we % actually do an assignment. This allows more flexible definitions: you % can specify some of the parameters, and keep the defaults for others. % % It is also possible to write a program that creates a |mode_def| on % the fly. Although useful, this has a slightly different focus than % starting with an existing |mode_def| and changing a couple of % parameters. In particular, one still has to peek inside the % file to see what the old values were and set them again (in the % new context). Also, such on-the-fly |mode_def| generation programs are % inherently less machine-independent than a scheme that does % everything in \MF\ itself. % % The upshot of all this is the following: we say, e.g., % |mode_param (fontmaking, 1)| below, instead of using the assignment % primitive directly. The name (``|mode_param|'') is kept somewhat % short because you can also use this to override a mode assignment on % the command line or in response to the {\tt **} prompt. % def mode_param (suffix v) (expr e) = if unknown mode_guard_.v: v := e; mode_guard_.v := 1; fi enddef; % This macro is invoked by all the modes, after |pixels_per_inch| % has been defined, thus saving some space and time. def mode_common_setup_ = mode_param (proofing, 0); mode_param (fontmaking, 1); mode_param (tracingtitles, if pixels_per_inch > 700: 1 else: 0 fi); enddef; % In a similar spirit, here are definitions to change to ``landscape'' % mode. You just say {\tt mode := whatever; landscape; ...}, and when % |mode_setup| is executed, the |aspect_ratio| will be inverted, and % |pixels_per_inch| changed. def landscape = extra_setup := extra_setup & "landscape_;" enddef; def landscape_ = begingroup interim warningcheck := 0; pixels_per_inch := aspect_ratio * pixels_per_inch; aspect_ratio := 1 / aspect_ratio; fix_units; % Too bad we can't do this after any |extra_setup|. endgroup enddef; % Here are macros to add specials with mode information to the GF file. % % Specifically, we add the |pixels_per_inch|, |o_correction|, % |aspect_ratio| (if not 1), |mag|, |fillin|, and |mode_def| name. This % information can be used to automatically verify that a font file name % matches the specification within the file. For example, you could % check that the number in the filename matches |mag*pixels_per_inch|. % Or, if the |mode_def| name is part of the font directory path (e.g., % you put fonts in {\tt $\ldots$/tex/fonts/CanonCX}), that all of the % bitmap files in the directory have the expected |mode_def| name. def mode_special_ (suffix $) = string s, d; s := str $; d := decimal scantokens s; special s & "=" & d; enddef; def mode_output_specials_ = begingroup save d, s, p, p_p_i; string p; interim warningcheck := 0; % In case |pixels_per_inch>4096|. % We need the old |pixels_per_inch| to compute the true device % resolution. p_p_i = pixels_per_inch / mag; % But now we want to change |pixels_per_inch|, so |save| the old value. save pixels_per_inch; pixels_per_inch := p_p_i; special "jobname=" & jobname; mode_special_ (mag); p := if string mode: mode else: substring (0, length (mode_name[mode]) - 1) of mode_name[mode] fi; special "mode=" & p; mode_special_ (pixels_per_inch); if aspect_ratio <> 1: mode_special_ (aspect_ratio); fi; mode_special_ (blacker); mode_special_ (fillin); mode_special_ (o_correction); endgroup enddef; % Here are macros for Xerox-world font info, which can be useful even % if you never use a Xerox printer. For instance, {\tt crudetype} uses % the |coding_scheme| and it is nice to have the font family on record. % This goes into both the TFM file (as |headerbyte| information), and % into the GF file (as a |special|). % Make the string |s| be |n| bytes long. def BCPL_string (expr s, n) = for l := if length (s) >= n: n-1 else: length (s) fi: l for k := 1 upto l: , substring (k - 1, k) of s endfor for k := l + 2 upto n: , 0 endfor endfor enddef; % The string |s| names the encoding scheme, e.g., {\tt TeX text}. def coding_scheme expr s = headerbyte 9: BCPL_string (s, 40); special "codingscheme=" & s enddef; % The string |s| names the font family, e.g., {\tt CMR}. def font_family expr s = headerbyte 49: BCPL_string (s, 20); special "fontid=" & s enddef; % The integer |x| gives the family member number, which should be % between 0 and 255. def font_face_byte expr x = headerbyte 72: x; special "fontfacebyte"; numspecial x enddef; % So users can say |if known Xerox_world: $\ldots$ fi|, per the {\sl MFbook}. Xerox_world := 1; % Redefine |end| to put the extra information above in the GF and TFM % files. This code is based on that on page 321. inner end; let primitive_end_ = end; def end = if fontmaking > 0: font_family font_identifier_; coding_scheme font_coding_scheme_; font_face_byte max (0, 254 - round 2designsize); mode_output_specials_; fi; primitive_end_. enddef; % The {\sl \MF book} gives |bye| two different definitions (on pages 278 % and 321). The first is used in {\tt plain.mf} and is merely a synoynym % for the primitive |end|. The second, which is not part of {\tt % plain.mf}, is similar to the code given above. We want the extra % information to get into the output files regardless of whether the % \MF\ source used |end| or |bye|. The above changed |end|; now we have % to redefine |bye| again (as on page 278). outer end, primitive_end_; let bye = end; % Here are macros to handle write-white devices. % % The basic correction for write-white fonts occurs in the definition of % |font_setup|. This can be used to extend or change the write-black % definition in Computer Modern's {\tt cmbase.mf} or other base files % based on CM, such as {\tt dxbase.mf}. This has no effect at 1200$\,$dpi. def mode_write_white_setup_ = begingroup let black_setup = font_setup; def font_setup = black_setup; min_Vround:=max(fine.breadth,crisp.breadth,tiny.breadth,2); if min_Vround