Are true glyphs used for accented characters, when input as escaped codes?

Question

I know that in the early days of TeX, some characters outside the standard ascii where typeset by quite dirty hacks. For example, in my language (Polish), we have an "a with a downward hook" (ą) and some similiar characters. As it was not covered by early versions of TeX, people used to typeset comma over the a, to create a similiar character.

Now I started wondering, if I need to, say, put one word in French, it is easier for me to use an escape code, instead switching keyboard layout, or using symbols table. But I wonder if escape codes result in letters typeset with proper glyphs, or is there a similiar dirty hack used here?

Answer 1

LaTeX2e introduced the notion of output font encoding and of “LaTeX Internal Character Representation” (LICR).

Depending on the current font encoding, escape codes, such as \'{e} for “é” or \k{a} for “ą” will either use a composed glyph or a “real” one.

The T1 font encoding contains glyphs for most European languages. It defines several combinations that translate internally to the real glyph, transparently to the user. So \k{a} gets eventually translated into the instruction ”print the glyph in slot 0xA1 (which contains “ą”). Similarly, \'{n} will print a real “ń” from slot 0xAB. Conversely, \'m will compose an “m” with the acute accent, because such a glyph is not present in the font encoding.

In case you use the OT1 (traditional) font encoding, no accented character is available, so all will be composed from different parts.

Thus the answer is: say

\usepackage[T1]{fontenc}

in your document preamble and you'll be using real glyphs in the majority of cases, at least for European languages using the Latin alphabet. There are encodings for Cyrillic, Greek and also for African languages that use an extended set of Latin characters.

The limit is in the fact that TeX fonts have at most 256 glyphs. This limitation is lifted with XeLaTeX and LuaLaTeX that use huge font encodings (EU1 and EU2 respectively) where escape codes usually point to the precomposed character, rather than one composed “on the fly” from different parts.

In t1enc.def, one finds, for example,

\DeclareTextCommand{\k}{T1}[1]
   {\hmode@bgroup\ooalign{\null#1\crcr\hidewidth\char12}\egroup}
\DeclareTextCommand{\textogonekcentered}{T1}[1]
   {\hmode@bgroup\ooalign{\null#1\crcr\hidewidth\char12\hidewidth}\egroup}

that definea a couple of ways to render the \k command when the current encoding is T1. However one also finds

\DeclareTextComposite{\k}{T1}{A}{129}
\DeclareTextComposite{\k}{T1}{E}{134}
\DeclareTextComposite{\k}{T1}{a}{161}
\DeclareTextComposite{\k}{T1}{e}{166}
\DeclareTextCompositeCommand{\k}{T1}{o}{\textogonekcentered{o}}
\DeclareTextCompositeCommand{\k}{T1}{O}{\textogonekcentered{O}}

This exactly means that when the encoding is T1 and TeX finds \k{A}, \k{E}, \k{a} and \k{e} (the input can also be \k A and so on), a glyph from the current font in the corresponding slot (161=0xA1, for instance) is used. Instead, \k{O} and \k{o} will be translated into the shown commands. For undefined combinations, the default definition of \k will be used.

Note that this is completely independent from the input encoding. For instance, when the input encoding is UTF-8, if LaTeX sees ą (U+0105) it translates the character (actually a couple of bytes) into \k{a} for subsequent processing according to the current output encoding. The relevant instruction can be found in t1enc.dfu:

\DeclareUnicodeCharacter{0105}{\k a}

(the unbraced notation is used for economy).