Dvips supports the use of PostScript fonts in TeX documents. To use a PostScript font conveniently, you need to prepare a corresponding virtual font; the program Afm2tfm, supplied with Dvips, helps with that.
All the necessary support for the standard 35 PostScript fonts (`AvantGarde-Book' through `ZapfDingbats'), plus other freely or commonly available PostScript fonts is available along with Dvips. To use these fonts, you need do nothing beyond what is mentioned in the installation procedure (see section Installation). This chapter is therefore relevant only if you are installing new PostScript fonts not supplied with Dvips. (Or if you're curious.)
The information needed to typeset using a particular font is contained in two files: a metric file that contains shape-independent information and a glyph file that contains the actual shapes of the font's characters. A virtual font is an optional additional file that can specify special ways to construct the characters. TeX itself (or LaTeX) look only at the metric file, but DVI drivers such as Dvips look at all three of these files.
An encoding file defines the correspondence between the code numbers of the characters in a font and their descriptive names. Two encoding files used together can describe a reencoding that rearranges, i.e., renumbers, the characters of a font.
A metric file describes properties of the font that are independent of what the characters actually look like. Aside from general information about the font itself, a metric file has two kinds of information: information about individual characters, organized by character code, and information about sequences of characters.
The per-character information specifies the width, height, depth, and italic correction of each character in the font. Any might be zero.
In addition to information on individual characters, the metric file specifies kerning, i.e., adding or removing space between particular character pairs. It further specifies ligature information: when a sequence of input characters should be typeset as a single (presumably different) "ligature" character. For example, it's traditional for the input `fi' to be typeset as `fi', not as `fi' (with the dot of the `i' colliding with `f'). (In English, the only common ligatures are fi, fl, ff, ffi, and ffl.)
Different typesetting systems use different metric file formats:
tftopl program (see section `tftopl invocation' in Web2c) that comes with TeX to transform a TFM
file into a human-readable "property list" (`.pl') file. You can
also edit a PL file and transform it back to a TeX-readable TFM with
the companion program pltotf (see section `pltotf invocation' in Web2c). Editing metrics by hand is not something you're likely to want
to do often, but the capability is there.
The Afm2tfm program distributed with Dvips converts an AFM file to a TFM file and performs other useful transformations as well. See section Invoking Afm2tfm.
Although a metric file (see the previous section) contains information about the spatial and other properties of the character at position 75, say, it contains nothing about what the character at position 75 actually looks like. The glyphs--the actual shapes of the letterforms in a font--are defined by other files, which we call glyph files. TeX itself only reads the TFM file for a font; it does not need to know character shapes.
A glyph file is a file that defines the shapes of the characters in a font. The shapes can be defined either by outlines or by bitmaps.
PostScript fonts are defined as outline fonts: Each character in the font is defined by giving the mathematical curves (lines, arcs, and splines) that define its contours. Different sizes of a character are generated by linearly scaling a single shape. For example, a 10-point `A' is simply half the size of a 20-point `A'. Nowadays, outline fonts usually also contain hints---additional information to improve the appearance of the font at small sizes or low resolutions.
Although various kinds of PostScript outline fonts exist, by far the most common, and the only one we will consider, is called Type 1. The glyph files for Postscript Type 1 fonts typically have names ending in `.pfa' ("printer font ASCII") or `.pfb' ("printer font binary").
In contrast, glyph files for Computer Modern and the other standard TeX fonts are bitmap fonts, generated from Metafont (`.mf') descriptions. The Metafont program distributed with TeX generates bitmaps from these descriptions.
The glyph files for TeX bitmap fonts are usually stored in packed font (PK) files. The names of these files end in `.nnnpk', where nnn is the resolution of the font in dots per inch. For example, `cmr10.600pk' contains the bitmaps for the `cmr10' font at a resolution of 600dpi. (On DOS filesystems, it's more likely `dpi600\cmr10.pk'.)
Metafont actually outputs generic font (GF) files, e.g.,
`cmr10.600gf', but the GF files are usually converted immediately
to PK format (using the gftopk utility that comes with TeX)
since PK files are smaller and contain the same information. (The GF
format is a historical artifact.)
A virtual font is constructed by extracting characters from one or more existing fonts and rearranging them, or synthesizing new characters in various ways. The explanation in this manual is intended to suffice for understanding enough about virtual fonts to use them with Dvips. It isn't a reference manual on virtual fonts. For more information: The primary document on virtual fonts is Donald E. Knuth, TUGboat 11(1), Apr. 1990, pp. 13--23, "Virtual Fonts: More Fun for Grand Wizards" (`CTAN:/info/virtual-fonts.knuth'; for CTAN info, see section `unixtex.ftp' in Kpathsea). (Don't be intimidated by the subtitle.)
A virtual font (`.vf') file specifies, for each character in the
virtual font, a recipe for typesetting that character. A VF file, like
a TFM file, is in a compressed binary format. The vftovp and
vptovf programs convert a VF file to a human-readable VPL
(virtual property list) format and back again. See section `vftovp invocation' in Web2c, and section `vptovf invocation' in Web2c.
In the case of a PostScript font f being used in a straightforward way, the recipe says: character i in the VF font is character j in font f. The font f is called a base font. For example, the VF file could remap the characters of the PostScript font to the positions where TeX expects to find them. See section Encodings.
Since TeX reads only TFM files, not VF's, each VF must have a
corresponding TFM for use with TeX. This corresponding TFM is
created when you run vptovf.
You can expand virtual fonts into their base fonts with DVIcopy (see section `dvicopy invocation' in Web2c). This is useful if you are using a DVI translator that doesn't understand vf's itself.
Every font, whatever its type, has an encoding, that specifies the correspondence between "logical" characters and character codes. For example, the ASCII encoding specifies that the character numbered 65 (decimal) is an uppercase `A'. The encoding does not specify what the character at that position looks like; there are lots of ways to draw an `A', and a glyph file (see section Glyph files) tells how. Nor does it specify how much space that character occupies; that information is in a metric file (see section Metric files).
TeX implicitly assumes a particular encoding for the fonts you use
with it. For example, the plain TeX macro \', which typesets
an acute accent over the following letter, assumes the acute accent is
at position 19 (decimal). This happens to be true of standard TeX
fonts such as Computer Modern, as you might expect, but it is not true
of normal PostScript fonts.
It's possible but painful to change all the macros that assume particular character positions. A better solution is to create a new font with the information for the acute accent at position 19, where TeX expects it to be. See section Making a PostScript font available.
PostScript represents encodings as a sequence of 256 character names called an encoding vector. An encoding file (`.enc') gives such a vector, together with ligature and kerning information (with which we are not concerned at the moment). These encoding files are used by the Afm2tfm program. Encoding files are also downloaded to the PostScript interpreter in your printer if you use one of them in place of the default encoding vector for a particular PostScript font.
Examples of encodings: the `dvips.enc' encoding file that comes with Dvips in the `reencode' directory is a good (but not perfect) approximation to the TeX encoding for TeX's Computer Modern text fonts. This is the encoding of the fonts that originated with Dvips, such as `ptmr.tfm'. The distribution includes many other encoding files; for example, `8r.enc', which is the base font for the current PostScript font distribution, and three corresponding to the TeX mathematics fonts: `texmext.enc' for math extensions, `texmital.enc' for math italics, and `texmsym.enc' for math symbols.
The output of Dvips is a program in the PostScript language that instructs your (presumably PostScript-capable) printer how to typeset your document by transforming it into toner on paper. Your printer, in turn, contains a PostScript interpreter that carries out the instructions in this typesetting program.
The program must include the definition of any PostScript fonts that you use in your document. Fonts built into your printer (probably the standard 35: `Times-Roman', `ZapfDingbats', ...) are defined within the interpreter itself. Other fonts must be downloaded as pfa or pfb files (see section Glyph files) from your host (the computer on which you're running Dvips).
You may be wondering exactly how a PostScript interpreter figures out what character to typeset, with this mass of metrics, glyphs, encodings, and other information. (If you're not wondering, skip this section ...)
The basic PostScript operator for imaging characters is
show. Suppose you've asked TeX to typeset an `S'. This will
eventually wind up in the Dvips output as the equivalent of this
PostScript operation:
(S) show
Here is how PostScript typesets the `S':
/S.
/S as a key in a dictionary named
CharStrings, another mandatory entry in a font dictionary.
S in CharStrings is the equivalent of a
series of standard PostScript commands like `curveto',
`lineto', `fill', and so on. These commands are executed to
draw the character. There can also be hint information that helps
adapt the character to low-resolution rasters. (See section Glyph files.)
The commands are actually represented in a more compact way than
standard PostScript source; see the Type 1 book for details.
This method for typesetting characters is used in both Level 1 and Level 2 PostScript. See the PostScript reference manuals for more information.
To make a PostScript font available in a TeX document, you need to install the font on your system and then define it within the document. Once you have installed the font, of course, it is available for any document thereafter and you don't need to reinstall it. You must have an AFM file for any font you install. Unless the font is built into your printer, you must also have a PFA or PFB file.
In the following examples, we use the font `Times-Roman' to illustrate the process. But you should use the prebuilt fonts for Times and the other standard fonts, rather than rebuilding them. The prebuilt fonts are made using a more complicated process than that described here, to make them work as well as possible with TeX. So following the steps in this manual will not generate files identical to the distributed ones. See section PostScript font installation, for pointers to the prebuilt fonts.
Installation of a PostScript font proceeds in three steps. See section Font concepts, for descriptions of the various files involved.
afm2tfm to create a TFM file for the original font,
and the VPL form of the virtual font:
afm2tfm Times-Roman -v ptmr rptmr
vptovf to generate a VF and TFM file for the virtual font
from the VPL file:
vptovf ptmr.vpl ptmr.vf ptmr.tfm
rptmr Times-Roman <ptmr8a.pfa
cp ptmr.vf fontdir/vf/... cp *ptmr.tfm fontdir/tfm/... cp ptmr.afm fontdir/afm/... cp ptmr.pf? fontdir/type1/...
The simplest invocation of Afm2tfm to make virtual fonts goes something like this:
afm2tfm Times-Roman -v ptmr rptmr
This reads the file `Times-Roman.afm', and produces two files as output, namely the virtual property list'file `ptmr.vpl', and the "raw" font metric file `rptmr.tfm'. To use the font in TeX, you first run
vptovf ptmr.vpl ptmr.vf ptmr.tfm
You should 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.
Using these raw fonts is not recommended; there are no raw fonts in the prebuilt PostScript fonts distributed along with Dvips. But nevertheless, that's how Afm2tfm presently operates, so that's what we document here. The `r' prefix convention is likewise historical accident.
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 prebuilt fonts.)
Once the files have been installed, you're all set. You can now do things like this in TeX:
\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\raw = 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 virtual font `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). See section Reencoding with Afm2tfm.
As a final step you need to record information about both the virtual font and the original font (if you ever might want to use it) in the `psfonts.map' file (see section `psfonts.map': PostScript font catalog). For our example, you'd insert the following into `psfonts.map':
rptmr Times-Roman <ptmr8a.pfa
Of course, Times-Roman is already built in to most every
printer, so there's no need to download any Type 1 file for it. But if
you are actually following these instructions for new fonts, most likely
they are not built in to the printer.
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 bitmap fonts (possibly compressed, with the `Z' option) to be faster than using the built-in PostScript fonts.
The Afm2tfm program converts an AFM file for a PostScript font to a TFM file and a VPL file for a corresponding virtual font (or, in its simplest form, to a TFM file for the PostScript font itself). The results of the conversion are affected by the command-line options and especially by the reencodings you can specify with those options. You can also obtain special effects such as an oblique font.
An alternative to Afm2tfm for creating virtual fonts is Alan Jeffrey's
fontinst program, available from
`CTAN:fonts/utilities/fontinst' (for CTAN info,
see section `unixtex.ftp' in Kpathsea).
Afm2tfm allows you to specify a different encoding for a PostScript font (for a general introduction to encodings, see section Encodings). The `-t' options changes the TeX encoding, `-p' changes the PostScript encoding, and `-T' changes both simultaneously, as detailed in the sections below.
To build a virtual font with Afm2tfm, you specify the `-v' or `-V' option. You can then specify an encoding for that virtual font with `-t tex-enc'. (`-t' is ignored if neither `-v' nor `-V' is present.) Any ligature and kerning information you specify in tex-enc will be used in the VPL, in addition to the ligature and kerning information from the AFM file.
If the AFM file has no entry for a character specified in tex-enc, that character will be omitted from the output VPL.
The `-t' option is likely to be needed when you have a PostScript font corresponding to a TeX font other than a normal text font such as Computer Modern. For instance, if you have a PostScript font that contains math symbols, you'd probably want to use the encoding in the `texmsym.enc' file supplied with Dvips. (For a start; to actually get usable math fonts, you have to define much more than just an encoding.)
By default, Afm2tfm uses the encoding it finds in the AFM file. You can specify a different PostScript encoding with `-p ps-enc'. This makes the raw TFM file (the one output by Afm2tfm) have the encoding specified in the encoding file ps-enc. Any ligature or kern information specified in ps-enc is ignored by Afm2tfm, since ligkern info is always omitted from the raw TFM.
If you use this option, you must also arrange to download ps-enc as part of any document that uses this font. You do this by adding a line like the following one to `psfonts.map' (see section `psfonts.map': PostScript font catalog):
zpopr Optima "MyEncoding ReEncodeFont" <myenc.enc
Using `-p' is the only way to access characters in a PostScript font that are neither encoded in the AFM file nor constructed from other characters. For instance, Adobe's `Times-Roman' font contains the extra characters `trademark' and `registered' (among others); these can only be accessed through such a PostScript reencoding.
In fact, the `8r' base encoding used for the current PostScript font distribution (available at @url{ftp://ftp.tug.org/tex/psfonts.tar.gz}) does do this reencoding, for precisely this reason.
The option `-T enc-file' is equivalent to `-p enc-file -t enc-file'. If you make regular use of a private non-standard reencoding `-T' is usually a better idea than the individual options, to avoid unexpected inconsistencies in mapping otherwise. An example of when you might use this option is a dingbats font: when you have a TeX encoding that is designed to be used with a particular PostScript font.
The Afm2tfm program creates the TFM and VF files for the virtual font corresponding to a PostScript font by reencoding the PostScript font. Afm2tfm generates these files from two encodings: one for TeX and one for PostScript. The TeX encoding is used to map character numbers to character names while the PostScript encoding is used to map each character name to a possibly different number. In combination, you can get access to any character of a PostScript font at any position for TeX typesetting.
In the default case, when you specify none of the -t, -p,
or -T options, Afm2tfm uses a default TeX encoding (which
mostly corresponds to the Computer Modern text fonts) and the PostScript
encoding found in the AFM file being read. The reencoding is also
sometimes called a remapping.
For example, the default encodings reencode the acute accent in two steps: first the default TeX encoding maps the number 19 to the character name `acute'; then the default PostScript encoding, as found in the AFM file for an ordinary PostScript font, maps the character name `acute' to the number 194. (The PostScript encoding works in reverse, by looking in the encoding vector for the name and then yielding the corresponding number.) The combined mapping of 19 to 194 shows up explicitly in the VF file and also implicitly in the fact that the properties of PostScript character 194 appear in position 19 of the TFM file for the virtual font.
The default encoding of the distributed fonts (e.g., `ptmr.tfm')
mostly follows 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 the Scandinavian A ring
\AA, whose definition needs 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}
As a kind of summary, here are the `CODINGSCHEME's that result from the various possible choices for reencoding.
(CODINGSCHEME TeX text + AdobeStandardEncoding)
(CODINGSCHEME TeX text + DCEncoding)
(CODINGSCHEME DCEncoding + AdobeStandardEncoding)
(CODINGSCHEME DCEncoding + DCEncoding)
The `CODINGSCHEME' line appears in the VPL file but is ignored by Dvips.
Afm2tfm's encoding files have the same format as an encoding vector in a PostScript font. Here is a skeletal example:
% Comments are ignored, unless the first word after the percent sign % is `LIGKERN'; see below. /MyEncoding [ % exactly 256 entries follow, each with a leading `/' /Alpha /Beta /Gamma /Delta ... /A /B ... /Z ... /.notdef /xfooaccent /yfooaccent /zfooaccent ] def
These encoding files are downloaded as part of changing the encoding at the PostScript level (see the previous section).
Comments, which start with a percent sign and continue until the end of the line, are ignored unless they start with `LIGKERN' (see below).
The first non-comment word of the file must start with a forward slash
`/' (i.e., 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 want to leave undefined. Then 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 as a comment. If the first word after the `%' 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 is terminated by a space and a semicolon and (unless the semicolon is at the end of a line) another space.
In these LIGKERN statements, three types of information may be
specified. These three types are ligature pairs, kerns to ignore, and
the character value of this font's boundary character.
Throughout a LIGKERN statement, the boundary character is
specified as `||'. To set the font's boundary character value for
TeX:
% LIGKERN || = 39 ;
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 intended to be reminiscent of 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.
The most common operation is `=:' meaning that both characters are
removed and replaced by the third character, but by adding the `|'
character on either side of the `=:', you can retain either or both
of the two leading characters. In addition, by suffixing the ligature
operation with one or two `>' signs, you can make the ligature
scanning operation skip that many resulting characters before
proceeding. This works just like in Metafont. For example, the `fi'
ligature is specified with `f i =: fi ;'. A more convoluted
ligature is `one one |=:|>> exclam ;' which separates a pair of
adjacent 1's with an exclamation point, and then skips over two
of the resulting characters before continuing searching for ligatures
and kerns. You cannot give more >'s than |'s in an ligature
operation, so there are a total of eight possibilities:
=: |=: |=:> =:| =:|> |=:| |=:|> |=:|>>
The default set of ligatures and kerns built in to Afm2tfm is:
% 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 ;
Besides the reencodings described in the previous section, Afm2tfm can do other manipulations. (Again, it's best to use the prebuilt fonts rather than attempting to remake them.)
`-s slant' makes an obliqued variant, as in:
afm2tfm Times-Roman -s .167 -v ptmro rptmro
This creates `ptmro.vpl' and `rptmro.tfm'. To use this font, 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 will slant 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 pseudo-small caps mapped into the usual lowercase 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 need to acquire a small caps font.
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"
Afm2tfm writes to standard output the line you need to add to `psfonts.map' to use that font, assuming the font is resident in the printer; if the font is not resident, you must add the `<filename' command to download the font. Each identical line only needs to be specified once in the `psfonts.map' file, even though many different fonts (small caps variants, or ones with different output encodings) may be based on it.
Synopsis:
afm2tfm [option]... afmfile[.afm] [tfmfile[.tfm]]
Afm2tfm reads afmfile and writes a corresponding (but raw) TFM file. If tfmfile is not supplied, the base name of the AFM file is extended with `.tfm' to get the output filename.
The simplest example:
afm2tfm Times-Roman rptmr
The TFM file thus created is raw because it omits ligature and kern information, and does no character remapping; it simply contains the character information in the AFM file in TFM form, which is the form that TeX understands. The characters have the same code in the TFM file as in the AFM file. For text fonts, this means printable ASCII characters will work ok, but little else, because standard PostScript fonts have a different encoding scheme than the one that plain TeX expects (see section Encodings). Although both schemes agree for the printable ASCII characters, other characters such as ligatures and accents vary. Thus, in practice, it's almost always desirable to create a virtual font as well with the `-v' or `-V' option. See section Making a PostScript font available.
The command line options to Afm2tfm:
The `psfonts.map' file associates a PostScript font with related files and constructs. Each line has the format:
filename PostScript-name options
rpstrn StoneInformal <StoneInformal.pfb
causes Dvips to download `StoneInformal.pfb' if your document (just as if it were a header file, see section PostScript header files) uses the font `StoneInformal'.
If the `j' config file or command-line option is enabled, `StoneInformal.pfb' will be partially downloaded---only those characters your document actually uses will be extracted and downloaded, and the remainder discarded. See section Option details.
Filenames of fonts that are partially downloaded are surrounded by curly braces (`{...}') in the progress report Dvips writes to standard output. Wholly-downloaded fonts appear inside angle brackets (`<...>'), like other downloaded files.
Adobe Multiple Master fonts, such as Minion, cannot be partially downloaded. To partially download in general, but avoid partial downloading for individual fonts, use `<<' instead `<':
pmnr8r Minion <<Minion.pfb
You can generate transformed fonts with a line like this:
rpstrc StoneInformal <StoneInformal.pfb ".8 ExtendFont"
See section Special font effects, for a complete list of font effects.
You can change the encoding of the Type 1 font at the PostScript level with a `ReEncodeFont' instruction, plus the name of the encoding file. This allows you access to characters that may be present in the Type 1 font file, but not encoded by default--most of the preaccented characters, for example. An example:
pstrn8r StoneInformal "TeXBase1Encoding ReEncodeFont" <8r.enc <pstrn8a.pfb
The `8r' encoding mentioned here has been designed to serve as a base for all downloadable fonts; it allows access to all the characters commonly present in a Type 1 font. For more details, see the `8r.enc' source file that comes with (and is installed with) Dvips.
You may notice that the same syntax is used for downloading encoding vectors and Type 1 font files. To make your intentions clear, you can also use `<[' to explicitly indicate you are downloading an encoding vector, as in:
pstrn8r StoneInformal "TeXBase1Encoding ReEncodeFont" <[8r.enc <pstrn8a.pfb
If the filename of your encoding vector does not end in `.enc', and you are using partial font downloading, you must use the `<[' syntax, or Dvips will not download the font properly.
Similarly, the name of the Type 1 font file itself must have extension `.pfa' or `.pfb' for partial downloading to work properly.
When using PFB files, Dvips is smart enough to unpack the binary PFB format into printable ASCII so there is no need to perform this conversion yourself. In addition, Dvips scans the font to determine its memory usage, just as it does for other header files (see section PostScript header files).
Here is a brief summary of how `psfonts.map' is read: