This is Info file dvips.info, produced by Makeinfo-1.64 from the input file /ade-src/contrib/unixtex/dvipsk/dvips.texi. START-INFO-DIR-ENTRY * DVIps: (dvips). DVI-to-PostScript translator. END-INFO-DIR-ENTRY File: dvips.info, Node: Top, Next: Why dvips, Up: (dir) Dvips ***** This manual documents Dvips, a program to translate a DVI file into PostScript. It corresponds to version 5.58f of the Dvipsk distribution, a slightly modified variant of the original `dvips' progam with path searching rules consistent with TeX, the GNU font utilities, and Xdvik. Tom Rokicki wrote and maintains `dvips'; `kb@cs.umb.edu' made the Dvipsk modifications. * Menu: * Why dvips:: Why use dvips? * Using dvips:: Minimal usage information. * Paper Size and Landscape:: * Including PostScript:: Including PostScript graphics. * PostScript fonts:: Using PostScript fonts, resident or downloaded. * Invoking dvips:: Command-line options, etc. * Config File:: Configuration file(s) and how they're found. * Font Generation:: Automatic font generation with MakeTeXPK. * Environment Variables:: * Bells and Whistles:: Other nifty things * MS-DOS:: MS-DOS support in dvips * Installation:: How to compile and install dvips. * Problems:: Diagnosing problems. * Color:: Using color with dvips. * Index:: -- The Detailed Node Listing -- Including PostScript Graphics * Bounding Box:: The Bounding Box Comment * EPSF Macros:: Using the EPSF Macros * Header Files:: Header Files * Literal PS:: Literal PostScript * Literal headers:: Literal Headers * Graphics Support:: Other Graphics Support * Dynamic Creation of Graphics:: Using PostScript Fonts * afm2tfm:: * Changing Encodings:: * Special Font Effects:: * Non-resident Fonts:: * Invoking Afm2tfm:: Configuration File Searching * Config File Options:: Diagnosing problems * Debug Options:: * No Output:: No Output At All * Small or Inverted:: Output Too Small or Inverted * Printer Errors:: Error Messages From Printer * 400 DPI:: 400 DPI Is Used Instead Of 300 DPI * Long Documents Fail:: Long Documents Fail To Print * Including Graphics Fails:: Including Graphics Fails * Unable to Generate Fonts:: Unable to Generate Fonts Using Color with dvips * Macro Files:: * User Definable Colors:: User Definable Colors * Color Subtleties:: Subtleties in Using Color * Ted Turner:: Printing in Black/White, after Colorizing * Color Configuration :: Configuring dvips for Color Devices * Color Support Details:: Color Support Details File: dvips.info, Node: Why dvips, Next: Using dvips, Prev: Top, Up: Top Why Use dvips? ************** The `dvips' program has a number of features that set it apart from other PostScript drivers for TeX. This rather long section describes the advantages of using dvips, and may be skipped if you are just interested in learning how to use the program. *Note Installation::, for details of compilation and installation. The dvips driver generates excellent, standard PostScript, that can be included in other documents as figures or printed through a variety of spoolers. The generated PostScript requires very little printer memory, so very complex documents with a lot of fonts can easily be printed even on PostScript printers without much memory, such as the original Apple LaserWriter. The PostScript output is also compact, requiring less disk space to store and making it feasible as a transfer format. Even those documents that are too complex to print in their entirety on a particular printer can be printed, since dvips will automatically split such documents into pieces, reclaiming the printer memory between each piece. The dvips program supports graphics in a natural way, allowing PostScript graphics to be included and automatically scaled and positioned in a variety of ways. Printers with resolutions other than 300 dpi are also supported, even if they have different resolutions in the horizontal and vertical directions. High resolution output is supported for typesetters, including an option that compresses the bitmapped fonts so that typesetter virtual memory is not exhausted. This option also significantly reduces the size of the PostScript file and decoding in the printer is very fast. Missing fonts can be automatically generated if METAFONT exists on the system, or fonts can be converted from `gf' to `pk' format on demand. If a font cannot be generated, a scaled version of the same font at a different size can be used instead, although dvips will complain loudly about the poor aesthetics of the resulting output. Users will appreciate features such as collated copies and support for `tpic', `psfig', `emtex', and `METAPOST'; system administrators will love the support for multiple printers, each with their own configuration file, and the ability to pipe the output directly to a program such as `lpr'. Support for MS-DOS, OS/2, and VMS in addition to UNIX is provided in the standard distribution, and porting to other systems is easy. One of the most important features is the support of virtual fonts, which add an entirely new level of flexibility to TeX. Virtual fonts are used to give dvips its excellent PostScript font support, handling all the font remapping in a natural, portable, elegant, and extensible way. The dvips `afm2tfm' driver even comes with its own `afm2tfm' program that creates the necessary virtual fonts and TeX font metric files automatically from the Adobe font metric files. Source is provided and freely distributable, so adding a site-specific feature is possible. Adding such features is made easier by the highly modular structure of the program. There is really no reason to use another driver, and the more people use dvips, the less time will be spent fighting with PostScript and the more time will be available to create beautiful documents. So if you don't use dvips on your system, get it today. File: dvips.info, Node: Using dvips, Next: Paper Size and Landscape, Prev: Why dvips, Up: Top Using dvips *********** To use dvips, simply type dvips foo where `foo.dvi' is the output of TeX that you want to print. If dvips has been installed correctly, the document should come out of your default printer. If you use fonts that have not been used on your system before, they may be automatically generated; this process can take a few minutes. The next time that document is printed, these fonts will already exist, so printing will go much faster. Many options are available; they are described in a later section. For a brief summary of available options, just type dvips File: dvips.info, Node: Paper Size and Landscape, Next: Including PostScript, Prev: Using dvips, Up: Top Paper Size and Landscape Orientation ************************************ Most TeX documents at a particular site are designed to use the standard paper size (letter size in the United States, A4 in Europe.) The dvips program defaults to these paper sizes and can be customized for the defaults at each site or on each printer. But many documents are designed for other paper sizes. For instance, you may want to design a document that has the long edge of the paper horizontal. This can be useful when typesetting booklets, brochures, complex tables, or many other documents. This type of paper orientation is called landscape orientation (the `normal' orientation is portrait). Alternatively, a document might be designed for ledger or A3 paper. Since the intended paper size is a document design decision, and not a decision that is made at printing time, such information should be given in the TeX file and not on the dvips command line. For this reason, dvips supports a `papersize' special. It is hoped that this special will become standard over time for TeX previewers and other printer drivers. The format of the `papersize' special is \special{papersize=8.5in,11in} where the dimensions given above are for a standard letter sheet. The first dimension given is the horizontal size of the page, and the second is the vertical size. The dimensions supported are the same as for TeX; namely, in (inches), cm (centimeters), mm (millimeters), pt (points), sp (scaled points), bp (big points, the same as the default PostScript unit), pc (picas), dd (didot points), and cc (ciceros). For a landscape document, the `papersize' comment would be given as \special{papersize=11in,8.5in} An alternate specification of `landscape' is to have a special of the \special{landscape} This is supported for backward compatibility, but it is hoped that eventually the `papersize' comment will dominate. Of course, using such a command only informs dvips of the desired paper size; you must still adjust the `hsize' and `vsize' in your TeX document to actually use the full page. The `papersize' special must occur somewhere on the first page of the document. File: dvips.info, Node: Including PostScript, Next: PostScript fonts, Prev: Paper Size and Landscape, Up: Top Including PostScript Graphics ***************************** Scaling and including PostScript graphics is a breeze--if the PostScript file is correctly formed. Even if it is not, however, the file can usually be accommodated with just a little more work. The most important feature of a good PostScript file--from the standpoint of including it in another document--is an accurate bounding box comment. * Menu: * Bounding Box:: The Bounding Box Comment * EPSF Macros:: Using the EPSF Macros * Header Files:: Header Files * Literal PS:: Literal PostScript * Literal headers:: Literal Headers * Graphics Support:: Other Graphics Support * Dynamic Creation of Graphics:: File: dvips.info, Node: Bounding Box, Next: EPSF Macros, Up: Including PostScript The Bounding Box Comment ======================== Every well-formed PostScript file has a comment describing where on the page the graphic is located, and how big that graphic is. This information is given in terms of the lower left and upper right corners of a box just enclosing the graphic, and is thus referred to as a bounding box. These coordinates are given in PostScript units (there are precisely 72 PostScript units to the inch) with respect to the lower left corner of the sheet of paper. To see if a PostScript file has a bounding box comment, just look at the first few lines of the file. (PostScript is standard ASCII, so you can use any text editor to do this.) If within the first few dozen lines there is a line of the form %%BoundingBox: 0 1 2 3 (with any numbers), chances are very good that the file is Encapsulated PostScript and will work easily with dvips. If the file contains instead a line like %%BoundingBox: (atend) the file is still probably Encapsulated PostScript, but the bounding box (that dvips needs to position the graphic) is at the end of the file and should be moved to the position of the line above. This can be done with that same text editor, or with a simple Perl script. If the document lacks a bounding box altogether, one can easily be added. Simply print the file. Now, take a ruler, and make the following measurements. All measurements should be in PostScript units, so measure it in inches and multiply by 72. Alternatively, the `bbfig' program distributed with dvips in the `contrib' directory can be used to automate this process. From the left edge of the paper to the leftmost mark on the paper is LLX, the first number. From the bottom edge of the paper to the bottommost mark on the paper is LLY, the second number. From the left edge of the paper to the rightmost mark on the paper is URX, the third number. The fourth and final number, URY, is the distance from the bottom of the page to the uppermost mark on the paper. Now, add a comment of the following form as the second line of the document. (The first line should already be a line starting with the two characters `%!'; if it is not, the file probably isn't PostScript.) %%BoundingBox: LLX LLY URX URY Or, if you don't want to modify the file, you can simply write these numbers down in a convenient place and use them when you import the graphic. If the document does not have such a bounding box, or if the bounding box is given at the end of the document, please complain to the authors of the software package that generated the file; without such a line, including PostScript graphics can be tedious. File: dvips.info, Node: EPSF Macros, Next: Header Files, Prev: Bounding Box, Up: Including PostScript Using the EPSF Macros ===================== Now you are ready to include the graphic into a TeX file. Simply add to the top of your TeX file a line like \input epsf (or, if your document is in LaTeX or SliTeX, add the `epsf' style option, as was done to the following line). \documentstyle[12pt,epsf]{article} This only needs to be done once, no matter how many figures you plan to include. Now, at the point you want to include the file, enter a line such as \epsffile{foo.ps} If you are using LaTeX or SliTeX, you may need to add a `\leavevmode' command immediately before the `\epsffile' command to get certain environments to work correctly. If your file did not (or does not currently) have a bounding box comment, you should supply those numbers you wrote down as in the following example: \epsffile[100 100 500 500]{foo.ps} (in the same order they would have been in a normal bounding box comment). Now, save your changes and run TeX and dvips; the output should have your graphic positioned at precisely the point you indicated, with the proper amount of space reserved. The effect of the `epsffile' macro is to typeset the figure as a TeX `vbox' at the point of the page that the command is executed. By default, the graphic will have its `natural' width (namely, the width of its bounding box). The TeX box will have depth zero and a `natural' height. The graphic will be scaled by any `dvi' magnification in effect at the time. Any PostScript graphics included by any method in this document (except `bop-hook' and its ilk) are scaled by the current `dvi' magnification. For graphics included with `epsffile' where the size is given in TeX dimensions, this scaling will produce the correct, or expected, results. For compatibility with old PostScript drivers, it is possible to turn this scaling off with the following TeX command: \special{! /magscale false def} Use of this command is not recommended because it will make the `epsffile' graphics the wrong size if global magnification is used in a `dvi' document, and it will cause any PostScript graphics to appear improperly scaled and out of position if a `dvi' to `dvi' program is used to scale or otherwise modify the document. You can enlarge or reduce the figure by putting \epsfxsize=DIMEN right before the call to `epsffile'. Then the width of the TeX box will be DIMEN and its' height will be scaled proportionately. Alternatively you can force the vertical size to a particular size with \epsfysize=DIMEN in which case the height will be set and the width will be scaled proportionally. If you set both, the aspect ratio of the included graphic will be distorted but both size specifications will be honored. By default, clipping is disabled for included EPSF images. This is because clipping to the bounding box dimensions often cuts off a small portion of the figure, due to slightly inaccurate bounding box arguments. The problem might be subtle; lines around the boundary of the image might be half their intended width, or the tops or bottoms of some text annotations might be sliced off. If you want to turn clipping on, just use the command \epsfclipon and to turn clipping back off, use \epsfclipoff A more general facility for sizing is available by defining the `epsfsize' macro. You can redefine this macro to do almost anything. This TeX macro is passed two parameters by `epsffile'. The first parameter is the natural horizontal size of the PostScript graphic, and the second parameter is the natural vertical size. This macro is responsible for returning the desired horizontal size of the graph (the same as assigning `epsfxsize' above). In the definitions given below, only the body is given; it should be inserted in \def\epsfsize#1#2{BODY} Some common definitions are: `epsfxsize' This definition (the default) enables the default features listed above, by setting `epsfxsize' to the same value it had before the macro was called. `0pt' This definition forces natural sizes for all graphics by setting the width to zero, which turns on horizontal scaling. This forces natural sizes too, by returning the first parameter only (the natural width) and setting the width to it. `hsize' This forces all graphics to be scaled so they are as wide as the current horizontal size. (In LaTeX, use `textwidth' instead of `hsize'.) `0.5#1' This scales all figures to half of their natural size. `\ifnum#1>\hsize\hsize\else#1\fi' This keeps graphics at their natural size, unless the width would be wider than the current `hsize', in which case the graphic is scaled down to `hsize'. If you want TeX to report the size of the figure as a message on your terminal when it processes each figure, give the command \epsfverbosetrue File: dvips.info, Node: Header Files, Next: Literal PS, Prev: EPSF Macros, Up: Including PostScript Header Files ============ Often in order to get a particular graphic file to work, a certain header file might need to be sent first. Sometimes this is even desirable, since the size of the header macros can dominate the size of certain PostScript graphics files. The dvips program provides support for this with the `header=' special command. For instance, to ensure that `foo.ps' gets downloaded as part of the header material, the following command should be added to the TeX file: \special{header=foo.ps} The dictionary stack will be at the `userdict' level when these header files are included. For these and all other header files (including the headers required by dvips itself and any downloaded fonts), the printer VM budget is debited by some value. If the header file has, in its first 1024 bytes, a line of the form %%VMusage: MIN MAX then the maximum value is used. If it doesn't, then the total size of the header file in bytes is used as an approximation of the memory requirements. File: dvips.info, Node: Literal PS, Next: Literal headers, Prev: Header Files, Up: Including PostScript Literal PostScript ================== For simple graphics, or just for experimentation, literal PostScript graphics can be included. Simply use a `\special' beginning with a double quote (`"') (no closing `"'). For instance, the following (simple) graphic: was created by typing: \vbox to 100bp{\vss % a bp is the same as a PostScript unit \special{" newpath 0 0 moveto 100 100 lineto 394 0 lineto closepath gsave 0.8 setgray fill grestore stroke}} [ There is a picture of a triangle on hardcopy printouts and in the PostScript file generated by `dvips'. (You are responsible for leaving space for such literal graphics.) Literal graphics are discouraged because of their nonportability. File: dvips.info, Node: Literal headers, Next: Graphics Support, Prev: Literal PS, Up: Including PostScript Literal Headers =============== Similarly, you can define your own macros for use in such literal graphics through the use of literal macros. Literal macros are defined just like literal graphics, only you begin the special with an exclamation point instead of a double quote. These literal macros are included as part of the header material in a special dictionary called `SDict'. This dictionary is the first one on the PostScript dictionary stack when any PostScript graphic is included, whether by literal inclusion or through the `epsffile' macros. File: dvips.info, Node: Graphics Support, Next: Dynamic Creation of Graphics, Prev: Literal headers, Up: Including PostScript Other Graphics Support ====================== There are other ways to include graphics with dvips. One is to use an existing package, such as `emtex', `psfig', `tpic', or `METAPOST', all of which `dvips' supports. Other facilities are available for historical reasons, but their use is discouraged, in hope that some `sane' form of PostScript inclusion shall become standard. The main advantage of the `epsffile' macros is that they can be adapted for whatever form of special eventually becomes standard, and thus only minor modifications to that one file need to be made, rather than revising an entire library of TeX documents. Most of these specials use a flexible key and value scheme: \special{psfile=FILENAME.PS[KEY=VALUE]*} This will download the PostScript file called `filename.ps' such that the current point will be the origin of the PostScript coordinate system. The optional key/value assignments allow you to specify transformations on the PostScript. The possible keys are: `hoffset' The horizontal offset (default 0) `voffset' The vertical offset (default 0) `hsize' The horizontal clipping size (default 612) `vsize' The vertical clipping size (default 792) `hscale' The horizontal scaling factor (default 100) `vscale' The vertical scaling factor (default 100) `angle' The rotation (default 0) `clip' Enable clipping to the bounding box The dimension parameters are all given in PostScript units. The `hscale' and `vscale' are given in non-dimensioned percentage units, and the rotation value is specified in degrees. Thus \special{psfile=foo.ps hoffset=72 hscale=90 vscale=90} will shift the graphics produced by file `foo.ps' right by one inch and will draw it at 0.9 times normal size. Offsets are given relative to the point of the special command, and are unaffected by scaling or rotation. Rotation is counterclockwise about the origin. The order of operations is to rotate the figure, scale it, then offset it. For compatibility with older PostScript drivers, it is possible to change the units that `hscale' and `vscale' are given in. This can be done by redefining `@scaleunit' in `SDict' by a TeX command such as \special{! /@scaleunit 1 def} The `@scaleunit' variable, which is by default 100, is what `hscale' and `vscale' are divided by to yield an absolute scale factor. All of the methods for including graphics we have described so far enclose the graphic in a PostScript save/restore pair, guaranteeing that the figure will have no effect on the rest of the document. Another type of special command allows literal PostScript instructions to be inserted without enclosing them in this protective shield; users of this feature are supposed to understand what they are doing (and they shouldn't change the PostScript graphics state unless they are willing to take the consequences). This command can take many forms, because it has had a torturous history; any of the following will work: \special{ps:TEXT} \special{ps::TEXT} \special{ps::[begin]TEXT} \special{ps::[end]TEXT} (with longer forms taking precedence over shorter forms, when they are used). Note that `ps::' and `ps::[end]' do not do any positioning, so they can be used to continue PostScript literals started with `ps:' or `ps::[begin]'. There is also the command \special{ps: plotfile FILENAME} which will copy the commands from FILENAME verbatim into the output (but omitting lines that begin with %). An example of the proper use of literal specials can be found in the file `rotate.tex' which makes it easy to typeset text turned 90 degrees. To finish off this section, the following examples are presented without explanation: \def\rotninety{\special{ps:currentpoint currentpoint translate 90 rotate neg exch neg exch translate}}\font\huge=cmbx10 at 14.4truept \setbox0=\hbox to0pt{\huge A\hss}\vskip16truept\centerline{\copy0 \special{ps:gsave}\rotninety\copy0\rotninety\copy0\rotninety \box0\special{ps:grestore}}\vskip16truept [ There are 4 `A' characters, each rotated 90 degrees about a common center point ] \vbox to 2truein{\special{ps:gsave 0.3 setgray}\hrule height 2in width\hsize\vskip-2in\special{ps:grestore}\font\big=cminch\big \vss\special{ps:gsave 1 setgray}\vbox to 0pt{\vskip2pt \line{\hss\hskip4pt NEAT\hss}\vss}\special{ps:0 setgray}% \hbox{\raise2pt\line{\hss NEAT\hss}\special{ps:grestore}}\vss} [ There is a big gray box with the word `NEAT' inside in big letters ] Some caveats are in order when using the above forms. Make sure that each `gsave' on a page is matched with a `grestore' on the same page. Do not use `save' or `restore'. Use of these macros can interact with the PostScript generated by dvips if care is not taken; try to understand what the above macros are doing before writing your own. The `\rotninety' macro especially has a useful trick that appears again and again. File: dvips.info, Node: Dynamic Creation of Graphics, Prev: Graphics Support, Up: Including PostScript Dynamic Creation of PostScript Graphics Files ============================================= PostScript is an excellent page description language--but it does tend to be rather verbose. Compressing PostScript graphics files can often reduce them by more than a factor of five. For this reason, if the filename parameter to one of the graphics inclusion techniques starts with a backtick (``'), the filename is instead interpreted as a command to execute that will send the actual file to standard output. Thus, \special{psfile="`zcat foo.ps.Z"} will include the uncompressed version of `foo.ps'. Since such a command is not accessible to TeX, if you use this facility with the `EPSF' macros, you need to supply the bounding box parameter yourself, as in \epsffile[72 72 540 720]{"`zcat screendump.ps.Z"} to include `screendump.ps'. Of course, the commands to be executed can be anything, including using a file conversion utility such as `tek2ps' or whatever is appropriate. This extension is not portable to other DVI-to-PostScript translators. File: dvips.info, Node: PostScript fonts, Next: Invoking dvips, Prev: Including PostScript, Up: Top Using PostScript Fonts ********************** Thanks to Donald E. Knuth, the dvips driver now supports PostScript fonts through the virtual font capability. PostScript fonts are (or should be) accompanied by a font metric file such as `Times-Roman.afm', which describes characteristics of a font called Times-Roman. To use such fonts with TeX, we need `tfm' files that contain similar information. These can be generated from `afm' files by running the program `afm2tfm', supplied with dvips. This program also creates virtual fonts with which you can use normal plain TeX conventions. See Donald E. Knuth, `TUGboat' v. 11, no. 1, Apr. 1990, pp. 13-23, "Virtual Fonts: More Fun for Grand Wizards", for a general introduction to virtual fonts. Non-resident downloaded PostScript fonts tend to use a great deal of printer virtual memory. PostScript printers typically have between 130,000 and 400,000 bytes of available virtual memory; each downloaded font will require approximately 30,000 bytes of that. For many applications, bitmapped fonts work much better, even at typesetter resolutions (with the `-Z' option). Even resident PostScript fonts can take a fair amount of memory, but less with this release of dvips than previously. Also, bitmapped fonts tend to image faster than PostScript fonts. * Menu: * afm2tfm:: * Changing Encodings:: * Special Font Effects:: * Non-resident Fonts:: * Invoking Afm2tfm:: File: dvips.info, Node: afm2tfm, Next: Changing Encodings, Up: PostScript fonts The Afm2tfm Program =================== In its simplest use, `afm2tfm' converts an Adobe `afm' file (e.g., `Times-Roman.afm') into a `raw' TeX TFM file (say, `rptmr.tfm' with the command afm2tfm Times-Roman rptmr This file is raw because it does no character remapping; it simply converts the character information on a one-to-one basis to TeX characters *with the same code*. (It would be better to have eschewed the use of the `r' prefix in favor of using a variant letter to specify the encoding; but we didn't think of that at the time, and it's too late to change existing fonts. *Note Top: (fontname)Top.) In the following examples, we will use the font Times-Roman to illustrate the conversion process. For the standard 35 LaserWriter fonts, however, it is highly recommended that you use the supplied `tfm' and `vf' files that come with dvips, as these files contain some additional changes that make them work better with TeX than they otherwise would. Standard PostScript fonts have a different encoding scheme from that of plain TeX. Although both schemes are based on ASCII, special characters such as ligatures and accents are handled quite differently. Therefore we obtain best results by using a `virtual font' interface, which makes TeX see a standard TeX encoding for the PostScript font. Such a virtual font can be obtained, for example, by the command afm2tfm Times-Roman -v ptmr rptmr This produces two files as output, namely the `virtual property list' file `ptmr.vpl', and the raw font metric file `rptmr.tfm'. (The upper case `-V' also produces a `vpl' file, but maps a set of small caps into the lower case alphabet.) To use the font in TeX, you should first run vptovf ptmr.vpl ptmr.vf ptmr.tfm and then install the virtual font file `ptmr.vf' where Dvips will see it, and install `ptmr.tfm' and `rptmr.tfm' where TeX and Dvips will see them. You can also make more complex virtual fonts by editing `ptmr.vpl' before running `vptovf'; such editing might add the uppercase Greek characters in the standard TeX positions, for instance. (This has already been done for the font files that come with Dvips.) Once this has been done, you're all set. You can use code like this in TeX henceforth: \font\myfont = ptmr at 12pt \myfont Hello, I am being typeset in 12-point Times-Roman. Thus we have two fonts, one actual (`rptmr', which is analogous to the font in the printer) and one virtual (`ptmr', which has been remapped to the standard TeX encoding (almost), and has typesetting know-how added. You could also say \font\PTR = rptmr at 10pt and typeset directly with that, but then you would have no ligatures or kerning, and you would have to use Adobe character positions for special letters like the ligature 'AE'. The virtual font called `ptmr' not only has ligatures and kerning, and most of the standard accent conventions of TeX, it also has a few additional features not present in the Computer Modern fonts. For example, it includes all the Adobe characters (such as the Polish ogonek and the French guillemots). The only things you lose from ordinary TeX text fonts are the dotless `j' (which can be hacked into the VPL file with literal PostScript specials if you have the patience) and uppercase Greek letters (which just don't exist unless you buy them separately). The remapped `p*' fonts mostly follow plain TeX conventions for accents. The exceptions: the Hungarian umlaut (which is at position `0x7D' in `cmr10', but position `0xCD' in `ptmr'); the dot accent (at positions `0x5F' and `0xC7', respectively); and `\AA', which neds different tweaking. In order to use these accents with PostScript fonts or in math mode when `\textfont0' is a PostScript font, you will need to use the following definitions. These definitions will not work with the Computer Modern fonts for the relevant accents. They are already part of the distributed `psfonts.sty' for use with LaTeX. \def\H#1{{\accent"CD #1}} \def\.#1{{\accent"C7 #1}} \def\dot{\mathaccent"70C7 } \newdimen\aadimen \def\AA{\leavevmode\setbox0\hbox{h}\aadimen\ht0 \advance\aadimen-1ex\setbox0\hbox{A}\rlap{\raise.67\aadimen \hbox to \wd0{\hss\char'27\hss}}A} These PostScript fonts can be scaled to any size. Go wild! Using PostScript fonts, however, does use up a great deal of the printer's memory and it does take time. You may find downloading bitmapped fonts (possibly compressed) to be faster than using the built-in PostScript fonts! File: dvips.info, Node: Changing Encodings, Next: Special Font Effects, Prev: afm2tfm, Up: PostScript fonts Changing a Font's Encoding ========================== The `afm2tfm' program also allows you to specify a different encoding for a PostScript font. This can be done at two levels. You can specify a different output encoding with `-t'. This only applies when you are building a virtual font, and it tells `afm2tfm' to attempt to remap the font to match the output encoding as closely as possible. In such an output encoding, you can also specify ligature pairs and kerning information that will be used in addition to the information in the `afm' file. You can also specify a different PostScript encoding with `-p'. This changes both the raw `tfm' file created by Afm2tfm and the `vf' and `tfm' files created by VPtoVF. It also requires that the encoding file be downloaded as part of any document that uses this font. This is the only way to access characters in a PostScript font that are neither encoded in the `afm' file nor built from other characters (constructed characters). For instance, `Times-Roman' contains the extra characters `trademark' and `registered' (among others) that can only be accessed through such a PostScript reencoding. Any ligature or kern information specified in the PostScript encoding is ignored by `afm2tfm'. To combine the effects of `-p' and `-t', use `-T'. If you make regular use of a private non-standard reencoding `-T' is usually the better idea, since you can get unexpected inconsistencies in mapping otherwise. Afm2tfm's encoding files have precisely the same format as an encoding vector in any PostScript font. Specifically: % Comments are ignored, unless the first word after the percent sign % is LIGKERN -- see below. /MyEncoding [ /Alpha /Beta /Gamma /Delta ... /A /B ... /Z % exactly 256 entries, each with a / at the front /wfooaccent /xfooaccent /yfooaccent /zfooaccent ] def Comments, which start with a percent sign and continue until the end of the line, are ignored unless they start with `LIGKERN'. The first `word' of the file must start with a forward slash (a PostScript literal name) and defines the name of the encoding. The next word must be an left bracket `['. Following that must be precisely 256 character names; use `/.notdef' for any that you do not want defined. Finally, there must be a matching right bracket `]'. A final `def' token is optional. All names are case sensitive. Any ligature or kern information is given in the comments. If the first word after the percent sign is `LIGKERN', then the entire rest of the line is parsed for ligature and kern information. This ligature and kern information is given in groups of words, each group of which must be terminated by a semicolon (with a space before and after it, unless it occurs at the end of a line.) In these `LIGKERN' statements, three types of information may be specified. These three types are ligature pairs, kerns to remove or ignore, and the character value of this font's boundary character. Which of the types the particular set of words corresponds to is automatically determined by the allowable syntax. Throughout a `LIGKERN' statement, the boundary character is specified as `||'. To set the boundary character value, a command such as `|| = 39 ;' must be used. To indicate a kern to remove, give the names of the two characters (without the leading slash) separated by `{}', as in `one {} one ;'. This is similar to the way you might use `{}' in a TeX file to turn off ligatures or kerns at a particular location. Either or both of the character names can be given as `*', which is a wild card matching any character; thus, all kerns can be removed with `* {} * ;'. To specify a ligature, specify the names of the pair of characters, followed by the ligature `operation' (as in METAFONT), followed by the replacing character name. Either (but not both) of the first two characters can be `||' to indicate a word boundary. Normally the `operation' is `=:' meaning that both characters are removed and replaced by the third character, but by adding `|' characters on either side of the `=:', you can specify which of the two leading characters to retain. In addition, by suffixing the ligature operation with one or two `>' signs, you can indicate that the ligature scanning operation should skip that many characters before proceeding. This works just like in METAFONT. A typical ligature might be specified with `ff i =: ffi ;'. A more convoluted ligature is `one one |=:|>> exclam ;' which indicates that every pair of adjacent `1''s should be separated by an exclamation point, and then two of the resulting characters should be skipped over before continuing searching for ligatures and kerns. You cannot give more `>''s in an ligature operation as you did `|', so there are a total of eight possible ligature operations: =: |=: |=:> =:| =:|> |=:| |=:|> |=:|>> The default set of ligatures and kerns built in to `afm2tfm' can be specified with: % LIGKERN question quoteleft =: questiondown ; % LIGKERN exclam quoteleft =: exclamdown ; % LIGKERN hyphen hyphen =: endash ; endash hyphen =: emdash ; % LIGKERN quoteleft quoteleft =: quotedblleft ; % LIGKERN quoteright quoteright =: quotedblright ; % LIGKERN space {} * ; * {} space ; 0 {} * ; * {} 0 ; % LIGKERN 1 {} * ; * {} 1 ; 2 {} * ; * {} 2 ; 3 {} * ; * {} 3 ; % LIGKERN 4 {} * ; * {} 4 ; 5 {} * ; * {} 5 ; 6 {} * ; * {} 6 ; % LIGKERN 7 {} * ; * {} 7 ; 8 {} * ; * {} 8 ; 9 {} * ; * {} 9 ; File: dvips.info, Node: Special Font Effects, Next: Non-resident Fonts, Prev: Changing Encodings, Up: PostScript fonts Special Font Effects ==================== Afm2tfm can do other manipulations as well. For example, to make an obliqued variant of Times Roman: afm2tfm Times-Roman -s .167 -v ptmro rptmro which creates `ptmro.vpl' and `rptmro.tfm'. To use this, put the line rptmro Times-Roman ".167 SlantFont" into `psfonts.map'. Then `rptmro' (our name for the obliqued Times) will act as if it were a resident font, although it is actually constructed from Times-Roman via the PostScript routine `SlantFont' (which slants everything 1/6 to the right, in this case). Similarly, you can get an expanded font with afm2tfm Times-Roman -e 1.2 -v ptmrre rptmrre and by recording the pseudo-resident font rptmrre Times-Roman "1.2 ExtendFont" in `psfonts.map'. You can also create a small caps font with a command such as afm2tfm Times-Roman -V ptmrc rptmrc This will generate a set of small caps mapped into the usual lower case positions and scaled down to 0.8 of the normal cap dimensions. You can also specify the scaling as something other than the default 0.8: afm2tfm Times-Roman -c 0.7 -V ptmrc rptmrc It is unfortunately not possible to increase the width of the small caps independently of the rest of the font. If you want a really professional looking set of small caps you will have to make up a custom pair of ``tfm'' and ``vpl'' files using the `-e' option, change the name and checksum of the D 1 font in `ptmrc.vpl' to match the customized raw `tfm', and replace the small caps at the lower case mappings with the small caps in the customized file. You can then throw away the customized `vpl' file, but not the customized `tfm'. That must be identified with an appropriate line in `psfonts.map'. To change the `PaintType' in a font from filled (0) to outlined (2), you can add `"/PaintType 2 store"' to `psfonts.map', as in the following: rphvrl Helvetica "/PaintType 2 store" If you change the PostScript encoding of a font, you must specify the input file as a header file, as well as give a reencoding command. For instance, let us say we are using Times-Roman reencoded according to the encoding `MyEncoding' (stored in the file `myenc.enc') as `rptmrx'. In this case, our `psfonts.map' entry would look like rptmrx Times-Roman "MyEncoding ReEncodeFont"