LaTeX ReferenceWhat is TeX64?

Accents

With any LaTeX from 2018 onwards you can type the é of café, the ñ of señor and the ß of Gauß straight into your source and they simply set. Yet open the resulting PDF, search for “café”, and you may get no hits at all. The cause is not the accent but a single line in the preamble — the fontenc setting. This page follows accented Western text as one pipeline, from what you type to what ends up inside the PDF: input encoding, declaring the language with babel, author names in .bib, and bookmarks under hyperref. The accidents always happen at the ends. The inventory of the accent commands themselves is left to the related page.

You no longer need \usepackage[utf8]{inputenc}

UTF-8 has been LaTeX's default input encoding since 2018. A document that writes Un café à Montréal, señor Gauß, Kovář, Łódź. without loading inputenc at all compiles under TeX Live 2024's pdfLaTeX without a single warning. LaTeX News 28 (2018) records the change of the default from a “pass through raw” scheme to UTF-8, and states that \usepackage[utf8]{inputenc} is therefore no longer required, though it does no harm if present. Most of the older advice you find by searching inputenc utf8 is thus describing a problem that no longer exists.

XeLaTeX and LuaLaTeX have always had UTF-8 as their only input encoding, so inputenc has nothing to do there from the start. It is not an error, though. Hand inputenc to either engine with the inputenc.sty shipped in TeX Live 2024 (2021/02/14 v1.3d) and what comes back is a warning — Package inputenc Warning: inputenc package ignored with utf8 based engines. — after which the run finishes normally. That is why an old preamble carried over to LuaLaTeX does not stop; which also means “no error” is not proof that the line is right. The tidy thing is to delete it the next time you clean the preamble.

One aside. The UTF-8 encoding scheme itself was devised in 1992 by Ken Thompson and Rob Pike, a history LaTeX News 28 also recounts. When TeX was born in the late 1970s there was only 7-bit ASCII, and the only way to get an é was to write a command for it. That you can now simply type é is the end of a forty-year detour.

Under pdfLaTeX, always load \usepackage[T1]{fontenc}

Where inputenc decides how the bytes of your source are read, fontenc decides which glyph sits at which slot in the font. The default OT1 has room for only 128 characters and has no accented letters as single glyphs. So an é is produced as a composition: an acute drawn on top of an e. It looks almost the same, but to TeX it is not one letter, it is a letter with a mark stacked on it, and the word containing it drops out of hyphenation altogether (which commands exist in which encoding is tabulated on the related page). T1 has 256 slots and holds é, ř and ł as single glyphs.

If you meet the advice that “T1 turns Computer Modern into bitmaps and ruins your PDF”, that is out of date. Run pdffonts over a TeX Live 2024 PDF built with nothing but \usepackage[T1]{fontenc} added and what is embedded is SFRM1000 from cm-super, of type Type 1 — not a Type 3 bitmap. Adding lmodern is still worth it: the embedded font becomes LMRoman10-Regular, and Latin Modern is Computer Modern's design redrawn for the Unicode era, so both its character coverage and the provenance of the font file are cleaner.

Under XeLaTeX and LuaLaTeX, fontenc has no role. They handle system fonts as Unicode throughout, so once you pick a face with fontspec, accented letters simply appear. The decision is therefore binary: T1 (and preferably lmodern) with pdfLaTeX, fontspec with Xe/LuaLaTeX. Note also that recent LaTeX kernels carry a fairly wide Unicode mapping table, so even pdfLaTeX with T1 sets €, →, – and “ ” typed directly, without a warning. Full-width symbols are a different story, and belong to the page on writing Western text.

latex
% pdfLaTeX: the two lines that matter
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{lmodern}       % optional, but cleaner glyph coverage
% (no inputenc: UTF-8 has been the default since 2018)
\begin{document}
Un café à Montréal, señor Gauß, Kovář, Łódź.
\end{document}

% XeLaTeX / LuaLaTeX: no fontenc at all
% \usepackage{fontspec}
% \setmainfont{Latin Modern Roman}

When “café” cannot be found in your PDF: the letter is stored as two characters

Compile the same source, Un café à Montréal, señor Gauß, Kovář, Łódź., twice — once with no fontenc (the default OT1) and once with [T1]{fontenc} — then pull the text out with pdftotext and look at the code points. The difference is decisive. In the OT1 version the é is stored as two characters: “e” followed by U+0301, a combining acute. Type “café” into a PDF viewer's search box, where the é is U+00E9, and nothing matches. Searching for café, Montréal and Łódź in that file returns zero hits for all three. In the T1 version the same positions hold precomposed single characters — U+00E9, U+00E1, U+0159, U+0141, U+017A — and all three words are found.

There is a cruder failure too. Polish Ł, the barred L, has no glyph in OT1, so LaTeX draws a stroke across an L instead. To the eye it is a Ł; but the string extracted from the PDF is not Łódź, it is Lódź — the bar has gone and a plain L is left. Publish an author name or a place name in that state and the printed page looks right while search, and any copy into a reference manager, silently disagrees about the spelling. For the same reason OT1 also prevents accented words from hyphenating (that measurement lives on the related accent-symbols page).

bash
# extract the text layer and inspect the code points
pdftotext paper.pdf - | head -1

# default OT1 -> e is followed by U+0301, a separate combining acute,
#                 and the bar of L is lost entirely:
#                 searching for "café" / "Montréal" / "Łódź" gives 0 hits
# with T1     -> precomposed U+00E9 U+00E1 U+0159 U+0141 U+017A:
#                 all three words are found

# and check what font actually got embedded
pdffonts paper.pdf

Declaring the language with babel or polyglossia changes the input too

Hand babel a language and its input shorthands come alive. In a document with \usepackage[ngerman]{babel}, "a, "o, "u and "s become ä, ö, ü and ß, while the two forms of the double-quote shorthand produce the German low and high quotation marks „ and “. "- goes further: it adds a permitted hyphenation point, so Zucker"-dose still prints as Zuckerdose — the mark itself never reaches the page. This earns its keep when you are writing German without a German keyboard, or want to keep the manuscript in pure ASCII.

Under XeLaTeX and LuaLaTeX the same role falls to polyglossia, declared as \setmainlanguage{german} and so on. With either package the thing to watch is that the shorthands rewrite what " means, so typing a bare " outside verbatim — in a URL, a code fragment, a file name — can produce a character you did not intend. In a section full of quotations or external file names, switching them off for the duration with \shorthandoff{"} is the reliable move. babel also changes hyphenation and language-specific typographic conventions, but those belong to the page on writing Western text.

latex
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
% "a "o "u "s        -> a-umlaut, o-umlaut, u-umlaut, eszett
% "-                -> an extra hyphenation point, invisible in the output
%                      Zucker"-dose still prints as one word
\shorthandoff{"}     % turn the shorthands off around URLs and code

Author names in .bib: BibTeX sorts É after Z

Accent trouble shows up most visibly not in the body text but in the bibliography. Try it. Put four entries — Alpha, Ore, Zola, Zulu — in a .bib, with Émile Zola and Øystein Ore written as plain UTF-8. Run BibTeX with plain.bst and the order that comes back is Alpha, Zulu, Zola, Ore: the two names beginning with É and Ø fall past Z. BibTeX compares names as byte strings, and the lead byte of a UTF-8 É simply sorts above z. There is no warning and no error. Rewrite just those author fields in command notation, as {\'E}mile and {\O}ystein, and the order becomes the correct Alpha, Ore, Zola, Zulu.

There is a reason for the quirk. The BibTeX in TeX Live 2024 still announces itself as Version 0.99d — a program Oren Patashnik wrote in the 1980s, in active service for nearly forty years without ever reaching 1.0. It carries its 7-bit era design intact, and has no notion of Unicode collation. biblatex with biber, by contrast, understands Unicode and sorts the very same UTF-8 .bib correctly without changing a character of it (verified with biber 2.19). So the practical decision has two branches: if the venue lets you use biber, keep the file in UTF-8; if BibTeX is mandated, standardise the .bib alone on command notation. Either way, the point is not to mix. In a mixed .bib neither duplicate detection nor sorting can be trusted.

bibtex
% BibTeX 0.99d + plain.bst sorts these as Alpha, Zulu, Zola, Ore
@article{a1, author = {Émile Zola},   title = {Un titre}, journal = {J}, year = {2001}}
@article{a3, author = {Øystein Ore},  title = {Another},  journal = {J}, year = {2003}}

% ...and these as Alpha, Ore, Zola, Zulu -- correct
@article{a1, author = {{\'E}mile Zola},  title = {Un titre}, journal = {J}, year = {2001}}
@article{a3, author = {{\O}ystein Ore},  title = {Another},  journal = {J}, year = {2003}}

% biblatex + biber sorts the UTF-8 form correctly with no rewriting:
%   \usepackage[backend=biber]{biblatex}

Bookmarks and PDF strings: hyperref passes accents through

PDF bookmarks and document information are written as “PDF strings”, separately from the body text. Losing accents there used to be a routine accident; today the default is Unicode. Set \section{Le café de Montréal} with hyperref 7.01h from TeX Live 2024 and the generated .out file holds a UTF-16 byte-order mark followed by the é as U+00E9, which then appears correctly in the bookmark pane. You no longer need to add the unicode option by hand.

PDF strings, however, do not accept every command you can use in the body. Put a formula in a heading and the log fills with Package hyperref Warning: Token not allowed in a PDF string (Unicode): removing 'math shift', and the offending tokens are quietly stripped from the bookmark. That is how you end up with a correct heading and an unintelligible bookmark. The fix is \texorpdfstring{}{}: the first argument is what gets typeset, the second is plain text for the bookmark. Accented words can go straight into that second argument — since PDF strings are Unicode, café passes through as café.

latex
\usepackage{hyperref}

% the log fills with "Token not allowed in a PDF string"
\section{Le café de Montréal $x^2$}

% typeset form on the left, bookmark text on the right
\section{Le café de Montréal \texorpdfstring{$x^2$}{x2}}

What to settle before the team starts writing

How accented text is entered is the kind of decision that gets hard to reverse once the manuscript grows. A draft in which the same name appears both as Gödel and as G\"{o}del typesets correctly either way, yet every search, every global replace and every duplicate check has to be done twice. And you usually notice the inconsistency while looking over the bibliography just before submission. Settling three things in the first commit — the engine, the fontenc line, and the notation used in .bib — is by far the cheapest route.

  • Standardise on direct UTF-8 in the body. Do not write inputenc. One line: fontspec under Xe/LuaLaTeX, \usepackage[T1]{fontenc} under pdfLaTeX.
  • Run the acceptance test once. Search the built PDF for café and for an author name, and confirm they are found. If they are not, the fontenc line is missing.
  • Match the .bib to the venue's toolchain. UTF-8 as it stands if biber is allowed; if BibTeX is mandated, put every author name in the {\'E} form — and never mix the two.
  • Any formula in a heading gets a \texorpdfstring. The Token not allowed in a PDF string warning is the signal that a bookmark has been mangled.
  • If you use babel shorthands, wrap URLs and code in \shorthandoff{"}. It is easy to forget that the meaning of the quote character has been rewritten.

Related pages