My question feels like a duplicate of: fontenc vs inputenc, but in that question the OP uses German and non-ascii characters.

I speak and write in English exclusively. My keyboard is the standard en-GB layout making typing non-ascii characters difficult. I use latex and not xetex. My LateX files are 100% ascii. Every once in a while a citation I download into my .bib file contains a non-ascii character, but I have never had an issues "fixing" these. Do I need, or would I benefit from using, the fontenc and inputenc packages?

  • 6
    You don't need inputenc. But you should use \usepackage[T1]{fontenc}. The default OT1 encoding has only 128 positions and this leads to deficiencies. – Ulrike Fischer Sep 14 '12 at 11:28
  • @Ulrike Fischer: What kind of 'deficiencies'? This comment doesn't explain why fontenc is necessary, at least to a non-expert like myself. – Mohan Oct 18 '12 at 13:36
  • I didn't say fontenc is necessary but T1 encoding (or some other font encoding with at least 256 char positions). 128 positions are simply not enough. The answers below (and the answers they link to) gives some examples of chars missing in OT1. – Ulrike Fischer Oct 18 '12 at 14:12
up vote 20 down vote accepted

Font encoding

Because of deficiencies of the OT1 encoding I also recommend T1 font encoding:


For example OT1 contains inconsistencies in the encoding for different families, typewriter is different, … Also


is useful for getting other symbols (Euro, …). Instead of Computer Modern/EC I would use the new Latin Modern fonts that are a further development of the former:


Input encoding

Of course there are advantages using plain ASCII for the texts and using commands for the other characters. This way the text is quite independent from the encoding and can be more easily be used in different environments with different encodings.

But sometimes characters outside of ASCII might slip through. In case of OT1 the file compiles fine, but the characters are missing:

% Default font encoding: OT1
Umlauts via LICR: \"a\"o\"u\ss

Umlauts directly: äöüß

Missing non-ASCII characters in output

There is no warning or error, only the .log file says:

Missing character: There is no ä in font cmr10!
Missing character: There is no ö in font cmr10!
Missing character: There is no ü in font cmr10!
Missing character: There is no ß in font cmr10!

Switching to T1 encoding helps to make more characters available. However I do not know an editor that supports T1 encoding. Some positions match the slots in latin1, for example. But other characters are different or have other positions. The following example uses the ^^-notation to avoid problems with editing and copy&pasting, because the example uses two different encodings at the same time:



% Umlauts/Euro: äöüß/€

Umlauts/Euro via LICR: \"a\"o\"u\ss/\texteuro

Umlauts/Euro directly (latin9): ^^e4^^f6^^fc^^df/^^a4

Umlauts/Euro directly (UTF-8): ^^c3^^a4^^c3^^b6^^c3^^bc^^c3^^9f/^^e2^^82^^ac

Unexpected result with non-ASCII characters

This time, there is no hint even in the .log file.

Therefore I recommend using package inputenc with encoding ascii:


Then non-ASCII input characters generate errors:

! Package inputenc Error: Keyboard character used is undefined
(inputenc)                in inputencoding `ascii'.

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.

l.10 Umlauts/Euro directly (latin9): ä

After fixing the input lines this helps to ensure that the file is indeed ASCII.

inputenc you don't need if your input never has non-ascii characters. The only thing on a UK keyboard is usually £

fontenc you need if you want to access fonts that are in encodings other than the classic OT1 encoding of the original TeX fonts. There are advantages to using T1 even in English notably there are less surprises over symbols like < coming out as inverted question marks if used in text.

You should at least use the fontenc package, so that your symbols are set correctly. See also here. If you really only use ascii characters, inputenc shouldn't be needed.

I personally would use both in every case, as I don't see any downsides in using them.

  • 1
    The use of fontenc doesn't (directly at least) affect the choice of bitmap of vector formats. – David Carlisle Sep 14 '12 at 11:34
  • 1
    Oh... you're right of course. Why was I thinking that? I will edit the answer. – Juri Robl Sep 14 '12 at 11:39

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.