How do fonts work in LaTeX? When I write the command:


I'm specifying how the computer will read my keyboard inputs, right? Now, the command:


is the one supposed to be responsible for the glyphs printed for the reader, right? If this one is responsable for the fonts, what is its relation to font packages like tgpagella or mathpazo, which I can also call, but won't work without fontenc?

Also, where are the fonts specified in the command line


comming from? If I specify enconding as T1, I still can choose between several different families pbk (bookman), phv (helvetica) and so forth. I thought, T1 would fix the font to be used.

Can you shed some light over this? Thank you very much.

  • 1
    What makes you think they won't work without fontenc?
    – cfr
    Nov 8, 2016 at 0:16
  • 2
    This is a duplicate of tex.stackexchange.com/questions/44694/fontenc-vs-inputenc for the first part. The second part is covered in texdoc fntguide
    – egreg
    Nov 8, 2016 at 0:26
  • 1
    You didn't mention the prupose for which you intend to use LaTeX. Since you mention Goudy and Bookman fonts, my guess is that you intend to do writing rather than math. If that is so, then consider using LuaTeX with fontenc, and forget about T1 and OT1. LuaTeX with fontenc will give you access to modern Open Type fonts, with all their features, and they don't have to be part of TeX.
    – user103221
    Nov 8, 2016 at 1:15

2 Answers 2


The output encoding e.g. T1 does, as Bernard says, determine which characters go in which slots. But an encoding may also specify ligatures, as T1 does. For example, it tells TeX that if an f is followed by an i, it should replace the sequence of two characters with a character from a third slot which contains the fi ligatures.

In addition, when you load a particular encoding, LaTeX will use a particular set of definitions when you ask for various characters. For example, depending on the details of your configuration, it may set up mappings from particular sequences of characters to particular unicode characters. Because T1 includes many accented characters, for example, these can be mapped to single points in unicode. This makes it possible to search files created with T1 more easily, in many cases, than similar-looking files created using OT1. Depending on the font, the appearance will usually be superior, too. This is because TeX must create accented characters on-the-fly in OT1 rather than using the characters specially designed to represent them. For example â might be created from the unaccented a and the ^ accent, rather than using the â.

When you call a package such as tgpagella, it sets up fonts for you. You could do this directly yourself - the package is just a convenience.

A line such as


is a lower-level command which specifies a particular font. What most font packages do is set up default document fonts or create convenient macros to access a special-purpose font.

LaTeX defines \usefont{}{}{}{} as follows:


Now consider a special-purpose font, such as that supported by GoudyIn.sty. This defines two macros as follows


You could use these commands directly in your document or you use use


every time you wanted to use the font. But that would be tedious and you'd have to remember the encoding, series, shape and family name rather than just remembering to




which is somewhat more convenient.

A package such as tgpagella is a bit more complex, but the most interesting line for current purposes is.


This sets the default serif font to qpl. This means that LaTeX will try to use a font in the default text encoding (OT1 by default or something else). To do this, it looks for a font definition file <encoding><family>.fd. For example, t1qpl.fd or ot1qpl.fd or whatever. If it finds this, it will read the file which sets up the font.

For example, here's part of t1qpl.fd:


This creates a font family for qpl in the T1 encoding. Once the font family is defined, the code specifies which fonts LaTeX should use for which series and shapes when this font family is active.

The series establishes both the relative width and the relative weight e.g. bold extended or light condensed or medium standard.

\DeclareFontShape{T1}{qpl}{b}{sc}{<-> \qpl@scale ec-qplb-sc}{}

This tells LaTeX to use the font ec-qplb-sc when bold small-caps are requested.

\DeclareFontShape{T1}{qpl}{b}{n}{<-> \qpl@scale ec-qplb}{}

Upright bold.

\DeclareFontShape{T1}{qpl}{b}{scit}{<-> \qpl@scale ec-qplbi-sc}{}

Italic small-caps bold. This is not a standard shape, so some font packages use a different name for the same shape. For example, my font packages use si for italic small-caps rather than scit.

\DeclareFontShape{T1}{qpl}{b}{it}{<-> \qpl@scale ec-qplbi}{}

Bold italic.

And now the regular weight - \mdseries.

\DeclareFontShape{T1}{qpl}{m}{sc}{<-> \qpl@scale ec-qplr-sc}{}
\DeclareFontShape{T1}{qpl}{m}{n}{<-> \qpl@scale ec-qplr}{}
\DeclareFontShape{T1}{qpl}{m}{scit}{<-> \qpl@scale ec-qplri-sc}{}
\DeclareFontShape{T1}{qpl}{m}{it}{<-> \qpl@scale ec-qplri}{}

That's all the fonts provided. However, the default for \bfseries in LaTeX is not b but bx. This font doesn't provide bx, so LaTeX will have to substitute something. By default, it will substitute medium and issue a warning. That isn't great. We'd probably prefer it to substitute bold b rather than medium m and we probably don't want a warning every time we use bold either.

Fortunately, the font definitions specify suitable substitutions.

\DeclareFontShape{T1}{qpl}{bx}{sc}{<->ssub * qpl/b/sc}{}

If small-caps bold extended is requested, 'silently' substitute bold small-caps. That is, use bold not medium and don't issue a warning.

\DeclareFontShape{T1}{qpl}{bx}{n}{<->ssub * qpl/b/n}{}
\DeclareFontShape{T1}{qpl}{bx}{scit}{<->ssub * qpl/b/scit}{}
\DeclareFontShape{T1}{qpl}{bx}{it}{<->ssub * qpl/b/it}{}

This font has italics but not oblique. By default, LaTeX will substitute upright if oblique is requested. However, in this case

\DeclareFontShape{T1}{qpl}{b}{sl}{<->sub * qpl/b/it}{}

tells LaTeX to substitute italic bold for bold oblique. This substitution is not silent - the user is more likely to want to know about this, so LaTeX will issue a warning.

\DeclareFontShape{T1}{qpl}{m}{sl}{<->sub * qpl/m/it}{}
\DeclareFontShape{T1}{qpl}{b}{scsl}{<->sub * qpl/b/scit}{}
\DeclareFontShape{T1}{qpl}{m}{scsl}{<->sub * qpl/m/scit}{}

The following is somewhat simplified in order to provide an overall picture of the process which follows. Otherwise the number of possible complications and possibilities, along with every detail, would result in an explanation which was clear as the proverbial mud. (You may think it is pretty swamp-like already, but believe me when I say that it could get much worse.)

Caveat emptor ...

Once LaTeX knows the font it needs to find, it tries to find a TeX font of that name.

Let's say it needs ec-qplr-sc because you either loaded tgpagella and then said




or because you said




Then LaTeX will look for a TeX Font Metric file ec-qplr-sc.tfm. This file provides LaTeX with a variety of information. In particular, it tells TeX the size of the box needed for each character and how to shift boxes left or right depending on which box comes immediately before or immediately after. It may also tell TeX to replace a sequence of two boxes by a third box, for example. It also provides some general information about the font's natural size etc.

If you compile with LaTeX, that's it. The DVI just contains information about boxes. It is up to the viewer or the post-processor to figure out what to put in each box. If you are compiling with pdfLaTeX, that needs to be done as part and parcel of compilation.

To find out what to put in each box, pdfTeX or the DVI viewer or post-processor must figure out where the information to draw the glyphs for the characters is.

To do this, it looks for a line in a .map file. Which .map file depends on the current engine or post-processor. Let's suppose you are using pdfTeX, then it will consult pdftex.map and look for the relevant line.

ec-qplr-sc TeXGyrePagella-Regular " encqecsc ReEncodeFont " <q-ec-sc.enc <qplr.pfb

This tells pdfTeX to re-encode the font in qplr.pfb using the q-ec-sc.enc encoding. This means it knows that the information on how to draw the glyphs is in qplr.pfb but the information is not in the order required. q-ec-sc.enc tells pdfTeX how to find the information for a character in the PFB even though the characters in the PFB are not in the same order as the current output encoding.

This is the simple case. If virtual fonts are involved, then things get a bit more complicated. However, that's not the case for qpl, so the story so far is sufficient.

  • And then there are virtual fonts. :-) Nov 8, 2016 at 21:04
  • @MartinSchröder There's a reason I left them to the last sentence! Do you think I should cover them also? I thought it might make LaTeX's fonts sound a little complicated.
    – cfr
    Nov 8, 2016 at 21:35
  • Ah. I missed that. Sorry for the noise. :-) Nov 8, 2016 at 21:38

For LaTeX, more precisely for the NFSS (New Font Selection Scheme), a font is characterised by 4 parameters: its encoding, its name, its weight and its shape.

Font encoding only fixes the way LaTeX encodes fonts, i.e. describes which glyph is associated with each slot number:

OT1 (the default encoding) is for alphabets without diacritics (roughly ASCII) and uses 7 bits per character.

The other encodings use 8 bits:

T1 is for the Latin alphabet; it has most diacritics used in Western European languages.

T2A, T2B, T2C are cyrillic alphabets.

LGR is for Greek (monotonic and polytonic).

On the other hand, the font family is only a set of glyphs. For instance phv is the short name for LaTeX of the family Adobe Helvetica,and it is re-encoded for use by LaTeX (the encoding is different from Adobe encoding).

  • @cfr: Did I say the family name has whatever to do with the encoding?
    – Bernard
    Nov 7, 2016 at 23:35
  • But in practice, it's reencoded via virtual fonts either in OT1 or T1 encoded, isn't it? You can't use them without this re-encoding, as far as I know. Or do I miss something?
    – Bernard
    Nov 7, 2016 at 23:42
  • Do you mean I can use , say, Adobe Garamond, without virtual fonts?
    – Bernard
    Nov 7, 2016 at 23:54
  • Of course. Provided you have the font in type1 postscript format. You do need TFM files etc. But you do not need virtual fonts.
    – cfr
    Nov 7, 2016 at 23:55
  • 1
    Helvetica is not an Adobe font.
    – Mico
    Nov 7, 2016 at 23:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.