How (La)TeX makes use of font related files, i.e., .fd, .map, .enc, .def,etc when selecting fonts?

Quick Overview

  • TeX font errors: Cheatsheet (A simple overview. Very useful for you now, I guess.)

enter image description here

Some related books:

  • LaTeX Companion 2ed, Chapter 7: Fonts and Encodings. Especially 7.9 -- 7.11. (.fd, .def, .enc, .map)
  • TeXbook, Appendix F: Font Tables. (.tfm)
  • METAFONTbook. (.tfm, .gf)

Documents:

  • The LaTeX Graphics Companion: Supplementary material. (A lot of things you want to know, mainly about Type1 fonts.)
  • fntguide LaTeX 2 font selection. (.fd, .def)
  • encguide LaTeX font encodings. (.def)
  • fontinstallationguide The Font Installation Guide. (Maybe everything you want to know, mainly for Type1 fonts. But some materials are outdated today.)

Tools:

  • dvips (.cfg, .map, .enc, .vf, etc.)
  • pdftex (.enc, .map, etc.)
  • dvipdfm (.enc, .map, etc.)
  • dvipdfmx: See dvipdfm and comments in cid-x.map.
  • updmap (updmap.cfg, .map)
  • ttf2tfm (.ttf --> .tfm, .enc; CMap files)
  • ttf2pk (.ttf --> .pk; ttfonts.map)
  • ttf2pt1 (.ttf --> .pfb)
  • gftopk (.gf --> .pk)

And More...

For XeTeX and LuaTeX, you can search and read the documents yourself. That's another story.


.def files

In files such as t1enc.def LaTeX finds definitions for tuning the choice of glyphs to the current encoding. There is always a current output encoding and some commands change their behavior depending on it; for instance \"{o} will translate to \accent"7F o if the current encoding is OT1 (or other encodings that don't have a “ö” glyph in their set), but the same \"{o} instruction will become \char"F6 if the current encoding is T1.

These files are read in as soon as the package fontenc is loaded with the encoding in its options. This package can be loaded multiple times; some packages, for instance textcomp load it implicitly. The current encoding at \begin{document} will be the one corresponding to the option passed last to fontenc.

There are other .def files, but those not named <encoding>enc.def are not related to fonts.

.fd files

When you specify \fontfamily{<family>}\selectfont (which might be implicit in a declaration such as \ttfamily or in a command such as \textsf), LaTeX looks in its internal tables in order to see if the combination

<encoding>+<family>

is known, where <encoding> is the current encoding. Such a knowledge comes from having already seen a declaration

\DeclareFontFamily{<encoding>}{<family>}{<tokens>}

Let's assume the current encoding is T1 and the requested family is ppl (Palatino). If the combination T1+ppl isn't known (which, by the way, is checked against the definedness of the control sequence \T1+ppl), LaTeX tries to load the file t1ppl.fd or T1ppl.fd. If neither exists, LaTeX will issue a warning and substitute the requested family with a default, but it will not change the encoding.

A .fd file should start with a \DeclareFontFamily declaration, followed by any number of \DeclareFontShape declarations that set up a table for the requested pair <encoding>+<family>. See fntguide.pdf for details.

Commands of the form \DeclareFontFamily or \DeclareFontShape can appear also in the document's preamble. The latter commands must follow a suitable font family declaration. Each of these declarations will establish a correspondence between a choice of attributes for a font and a “font metric file”. In our example, the combination

\usefont{T1}{ppl}{b}{it}

or any equivalent choice will point to pplb8t. A font metric file can be of two forms: a .vf or a .tfm file. If pplb8t.vf exists, TeX (we are deep down the processing, now) will load it, otherwise it will load pplb8t.tfm. One of these must exist.

The \DeclareFontShape commands can establish font substitutions and other rules; if LaTeX doesn't find its way out, it will choose a default font. However, badly written .fd files or improper \DeclareFontShape commands in the document can lead to errors (Corrupt NFSS tables).

So, let's assume that TeX has found pplb8t.vf or pplb8t.tfm.

.vf files

A font metric file can be virtual. This is indeed the case for pplb8t. The .vf metric file contains information about character bounding boxes, italic corrections, kerning pairs and ligatures. It also contains information for choosing actual glyphs from other fonts (virtual or not). In our example, the virtual font only uses a nonvirtual font which is pplb8r

(MAPFONT D 0
   (FONTNAME pplb8r)
   (FONTCHECKSUM O 25012244013)
   (FONTAT R 1.0)
   (FONTDSIZE R 10.0)
   )

and basically shuffles around the glyphs positions to conform with the T1 output encoding. For instance, the character in slot "F7 (octal `367) has this entry in the pplb8t.vf file

(CHARACTER O 367
   (CHARWD R 0.832996)
   (CHARHT R 0.485498)
   (CHARDP R 0.011493)
   (MAP
      (SETCHAR O 234)
      )
   )

This means that the glyph œ (which might come from the command \oe) will be actually taken from the font pplb8r at slot octal `234 (hexadecimal "9C), but the user is not concerned about this. The bounding box for the glyph will be computed has having width 8.32996pt, height 4.85498pt, depth 0.11493pt and no italic correction (assuming a ten point font size has been requested, otherwise the dimensions will be scaled).

.tfm files

A .tfm file (and in the previous case pplb8r.tfm must exist) contains the same information as a .vf file, except the possibility to point to other font metric files.

Interlude

As far as TeX is concerned, the road stops here: characters are typeset and a page is shipped out. The printer/previewer driver will take care of actually showing the glyphs. The situation is different with pdfTeX that needs to store also the glyphs.

.map files

Our boldface glyph œ has eventually been taken from pplb8r. Now pdfTeX consults the loaded .map file (default pdftex.map) and look for an entry starting with pplb8r. It finds it as

pplb8r URWPalladioL-Bold " TeXBase1Encoding ReEncodeFont " <8r.enc <uplb8a.pfb

so it proceeds to load the Type1 font file upl8a.pfb (if it hasn't yet loaded it), but it will apply a reencoding. This is necessary because .pfb files are stored according to the Adobe Standard Encoding and some glyphs are hidden. So the driver will shuffle around glyphs ending with a font encoded according to the 8r encoding (similar to T1 or the others, but not recommended for usage in documents). In this way the œ glyph will really be in slot "F7, rather than in the "FA slot reserved in the Adobe Standard Encoding. The glyph ö even isn't in the Adobe Standard Encoding, but still lives unencoded in the .pfb file; with the reencoding to 8r we're able to use it in slot "F6.

Why the change from pplb8a to uplb8a? Because the font actually used is the free one provided by URW. This doesn't really concern the user.

.pfb files

These files contain representations of the glyphs for printing (or previewing) in the form of outlines. Such files are never loaded directly by users, but only from the engine or the printer/previewer driver. They can also be in the .pfa form, the difference is that .pfa files only contain printable ASCII characters and so are larger than a corresponding .pfb file.

Tags:

Fonts

Recent Posts