I just don't seem to get it. So I come from the german speaking part of Switzerland and naturally I need ä ü ö a lot when I write german texts. So in LaTeX I have the option to go via

"a "u "o

which isn't really comfortable, or I can use an additional package. So now the confusion starts. I can use either

\usepackage[T1]{fontenc}

or

\usepackage[latin1]{inputenc}

So now if I create a new document and save it as a latin-1 encoded .tex file it seems it doesn't matter which option I chose they both work. Now why should I pick one over the other or use both? Which problems could occur (Do they occur if I use the same .tex file on another OS depending on which option I have chosen?)?

If I save the .tex encoded as lets say the mac os latin then the first option compiles but shows the wrong characters for the ä ü ö's. Is it then like latex maps the ä according to the latin1 to a character and since the document is encoded as something different than latin1 then gets encoded to something different again?

So if the last 2 paragraphs have been confusing (mainly because I'm confused) the main question is: What does fontenc what inputenc doesn't do and vice versa?

  • had problems with [utf8]{inputenc}, using lualatex.exe fixed it – aeroson Aug 28 '16 at 22:55
up vote 217 down vote accepted

The two packages address different problems.

  1. inputenc allows the user to input accented characters directly from the keyboard;

  2. fontenc is oriented to output, that is, what fonts to use for printing characters.

The two packages are not connected, though it is best to call fontenc first and then inputenc.

With \usepackage[T1]{fontenc} you choose an output font encoding that has support for the accented characters used by the most widespread European languages (German, French, Italian, Polish and others), which is important because otherwise TeX would not correctly hyphenate words containing accented letters.

With \usepackage[<encoding>]{inputenc} you can directly input accented and other characters. What's important is that <encoding> matches the encoding with which the file has been written and this depends on your operating system and the settings of your text editor.

If calling only

\usepackage[T1]{fontenc}

you seem to get correct output, then your files are probably encoded with Latin-1 (also called ISO 8859-1), but beware that the correspondence is not complete: for example, typing ß you'd get SS in output, which is obviously incorrect. Thus your editor might be set up for Latin-1 and so the correct call should be

\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

How do the packages work? Let's do the example for these two encodings and the character ä.

First of all one must remember that TeX knows nothing about file encodings: all it really sees is the character number.

  1. When you type ä in an editor set up for Latin-1, the machine stores character number 228.

  2. When TeX reads the file it finds the character number 228 and the macros of inputenc transform this into \"a.

  3. Now fontenc comes into action; the command \" has an associated table of the known accented characters the font has available, and ä is among these, so the sequence \"a is transformed into the command "print character 228" in the current (T1-encoded) font.

In this case the two coincide. This is not the case, for instance, of ß:

  1. The machine stores character number 223

  2. The macros of inputenc change this into \ss

  3. fontenc transforms this into "print character 255" (where T1 encoded fonts have a ß character).

UTF-8

The situation is a bit different when \usepackage[utf8]{inputenc} is used (and the file is UTF-8 encoded, of course). When the text editor shows ä or ß, the file actually contains two byte sequences, respectively <C3><A4> and <C3><9F>

The first byte is a prefix that contains some information, the main one is that it introduces a two byte character. Now inputenc makes all legal prefixes active, so <C3> behaves like a macro; its definition is to look at the next character and then interpret, according to Unicode rules, the whole pair and transforms it into the corresponding code point, respectively U+00E4 and U+00DF.

Other prefixes announce three or four byte combinations, but the behavior is essentially the same: instead of one character more, two or three others are absorbed and the translation into a code point is performed.

In ot1enc.dfu and t1enc.dfu we find

\DeclareUnicodeCharacter{00DF}{\ss}

\DeclareUnicodeCharacter{00E4}{\"a}

Oh, wait! There's something more! Yes, in this case inputenc interacts with fontenc (which it doesn't for other input encodings): for every loaded encoding, the corresponding .dfu file (Unicode definitions) is read before the document starts. This is the reason why I prefer to always load fontenc before inputenc (though not really necessary).

Those declarations provide the necessary setup: the combinations <C3><A4> and <C3><9F> get translated into \"a and \ss respectively and everything works from now on as described for latin1.

Caveat

Here's another issue that can pop up at times (see Available Characters with iso-8859-1). The Latin-1 encoding provides at slot 0xA5 (decimal 165) the yen character. According to the description above, the latin1 option to inputenc defines the \textyen translation for this, but the T1 output encoding reserves no slot for this, so inputting ¥ results in a runtime LaTeX error. One has to load a package providing a default output for \textyen, for instance textcomp. It would be the same with the utf8 input encoding.

Only characters covered by the output encoding or that are given a suitable rendering in terms of it can be safely input.

  • 11
    I really liked this explanation, I hope you don't mind me giving a German translation (uweziegenhagen.de/?p=1644) – Uwe Ziegenhagen Feb 18 '12 at 8:41
  • 2
    @UweZiegenhagen Not at all! The inputenc-fontenc problem has often bitten many users. – egreg Feb 18 '12 at 9:57
  • I read a while back that textcomp became obsolete/deprecated. Does this answer need an update? – thymaro Oct 7 '17 at 9:34
  • 1
    I wanted to look at the pkg documentation of textcomp and just remembered where I'd read that... I guess somebody with power to do so should review the page ctan.org/pkg/textcomp, if textcomp isn't obsolete. I'm getting mixed messages, right there ;) – thymaro Oct 7 '17 at 9:50
  • 1
    @DenisBitouzé It's an old habit of mine; some years ago, I discovered that the reverse order had some problems when Cyrillic was involved. The problem has long been solved, but still I think this is cleaner, because inputenc needs to know the loaded encodings (there's a list read at begin document anyhow). – egreg Jun 3 at 14:37

Yes, you are confused. You should use both packages with pdflatex or a different approach with xelatex or lualatex.

pdflatex

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{lmodern}

xelatex

\usepackage{fontspec}
\defaultfontfeatures{Ligatures=TeX}

lualatex

\usepackage{luatextra}
\defaultfontfeatures{Ligatures=TeX}

Or in a complete document:

\documentclass[a4paper]{scrartcl}
\usepackage[ngerman]{babel}
\usepackage{iftex}
\ifPDFTeX
   \usepackage[utf8]{inputenc}
   \usepackage[T1]{fontenc}
   \usepackage{lmodern}
\else
   \ifXeTeX
     \usepackage{fontspec}
   \else 
     \usepackage{luatextra}
   \fi
   \defaultfontfeatures{Ligatures=TeX}
\fi
\usepackage{blindtext}
\begin{document}
äöüßÄÖÜ

\blindtext
\end{document}

This assumes that your input is utf8, but you should do this anyway. It's 2012, after all.

See also:

  • 3
    @ppr: It is, but with Lua/XeLaTeX you don't use the lmodern package but fontspec. – Martin Schröder Dec 30 '13 at 21:52
  • 4
    The xltxtra package documentation page says it is deprecated, and to use only fontspec instead. – Alex Quinn Apr 21 '16 at 21:09
  • 1
    @AlexQuinn: Thanks. Fixed. – Martin Schröder Apr 21 '16 at 22:11
  • 3
    egreg's answer is great as an explanation (I upvoted it, of course), but I also like yours, because of its "directive" tone (sometimes I just want to be told what to do). – Matemáticos Chibchas Jul 3 '16 at 4:33
  • 1
    @skan I was wondering the same thing, I guess when the answer was written in 2012 fontspec did not work with LuaLaTex. – Erik Aug 28 '17 at 14:44

You need inputenc to specify the character encoding used in your input file if it is not ascii. So latin1 (or more general and modern, utf8).

fontenc specifies the encoding used in the fonts. this is (more or less) independent of the input encoding. Classical TeX uses Tex-specific font encodings such as "T1" for 8-bit fonts suitable for "latin1" languages.

Conceptually the input and font encodings would be totally independent but they are related in that you need a font encoding that includes the characters in the desired language and (regrettably) hyphenation patterns used to hyphenate words in the document are tied to the font encoding due to the way TeX works.

  • 3
    inputenc is only needed with pdftex, not with xetex or luatex. – Martin Schröder Feb 15 '12 at 23:42

To understand this, you need to realize that TeX is a "translator" that translates its input (the text you wrote) into output (PDF, or PS file). Accordingly the encodings of the input and the encoding of the output are two quite different things.

inputenc tells TeX the encoding of your .tex file. It can be latin1, or utf8, or koi8r, or whatever. This is the encoding you set in the editor you use to write the text.

fontenc tells TeX which encoding you want in the output file. Mostly it affects things like hyphenation. It depends on the fonts you select, since the name.

  • So inputenc is basically important for the portability of the .tex file whereas fontenc is important for the output of said .tex file? – Philipp Feb 15 '12 at 23:40
  • 1
    @Philipp: Basically, yes. Please read l2kurz/lshort. – Martin Schröder Feb 15 '12 at 23:49
  • 2
    This is only relevant if you are using latex or pdflatex. It's 2012: You should use xelatex or lualatex, which can handle unicode input without problems. – Martin Schröder Feb 15 '12 at 23:57

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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