19

According to the luatex docs, you shouldn't use fontenc with luatex. People swear up and down that fontenc is incompatible, but I haven't been able to find an example where loading the package causes problems. (I'm curious about this because it can be easier to load the same base set of packages for pdftex/luatex/xetex, and add fontspec only when handling the latter two.)

I know fontenc is not the right way to deal with fonts in luatex or xelatex, but I'm specifically looking for cases where it's detrimental to load the fontenc package. Do you know of any?

Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
karldw
  • 325

4 Answers4

18

fontenc is loaded by fontspec (you can check this in the log). So in itself the package is not a problem.

But fontenc is a special package: You can load it more than once with different options without getting option clash errors. It will then load font encoding definitions for all the options. E.g.

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[LGR]{fontenc}
\usepackage[T2A]{fontenc}
\begin{document}
\encodingdefault, \makeatletter \f@encoding\makeatother

\end{document}

will load t1enc.def, lgrenc.def and t2enc.def.

This also is not problematic with lualatex and xelatex.

But fontenc will also set the last encoding option as the encoding default. And quite a number of encodings are not suitable for lualatex and xelatex. These engines need the TU encoding (fontspec sets this encoding). Other encodings can lead to quite wrong outputs: 

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[LGR]{fontenc}
\usepackage[T2A]{fontenc}
\usepackage{fontspec}
\setmainfont{DejaVuSans}
\begin{document}
\encodingdefault, \makeatletter \f@encoding\makeatother

Grüße, αβγ, Ҍҋ

{\fontencoding{T1}\selectfont
 Grüße, αβγ, Ҍҋ}

{\fontencoding{LGR}\selectfont
 Grüße, αβγ, Ҍҋ}

{\fontencoding{T2A}\selectfont
 Grüße, αβγ, Ҍҋ}

\end{document}

enter image description here

So you can use fontenc in your document (I need it to use chessfonts), but you should be careful to load it so that TU remains the default encoding. This here e.g. is wrong:

\documentclass{article}
\usepackage{fontspec}
\setmainfont{DejaVuSans}
\usepackage[T1]{fontenc}
\usepackage[LGR]{fontenc}
\usepackage[T2A]{fontenc}
%
\begin{document}% wrong, encoding is T2A

Moving the \setmainfont resolves the problem:

\documentclass{article}
\usepackage{fontspec}
\usepackage[T1]{fontenc}
\usepackage[LGR]{fontenc}
\usepackage[T2A]{fontenc}
\setmainfont{DejaVuSans}
\begin{document} %encoding is TU now
Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
Ulrike Fischer
  • 327,261
  • The solution edited in at the bottom does not work correctly. The last three lines display as: Grüße, , ΓρῤΫε, , GrьЯe, ,. This is because non-ASCII characters are rendered inactive. – Davislor Jan 20 '19 at 12:14
  • I took the liberty of replacing the fix at the end with one that really does work. Mostly. – Davislor Jan 20 '19 at 13:38
  • @Davislor sorry no, your edit is wrong. I neither recommend luainputenc nor utf8x nor all your additions. I reject this edit. – Ulrike Fischer Jan 20 '19 at 13:41
  • Okay, it’s your answer. The solution at the end is bugged. It makes all the 8-bit encodings display mojibake. So that section still needs to be rewritten or removed. – Davislor Jan 20 '19 at 13:52
  • @Davislor you should not use 8bit-encoded text fonts with luatex and if you look at the question you will see that the OP doesn't want to do it, he is quite willing to load fontspec and use TU-encoded fonts, he only wants to know if loading fontenc too can do harm. – Ulrike Fischer Jan 20 '19 at 13:54
  • Okay, if your objection to my solution is that people shouldn’t try to use 8-bit encodings in LuaTeX at all, you might want to change the part that says loading those encodings in a different order “resolves the problem.” – Davislor Jan 20 '19 at 13:57
  • @Davislor it does resolves the problem, as it ensures that at \begin{document} the correct encoding (TU) is active. – Ulrike Fischer Jan 20 '19 at 13:59
  • 1
    As written, it appeared to me to be saying that making that change to your first example would allow it to compile correctly. Since that was not your intent, you might want to clarify which problem it resolves. – Davislor Jan 20 '19 at 14:01
  • In particular, if the message you want to send is “you should not use 8bit-encoded text fonts with luatex,” and someone’s loading them (my answer gives an example of how that could inadvertently happen), you might want to state clearly that your advice is to remove all such legacy packages from the document, not to change the order in which they are loaded. – Davislor Jan 20 '19 at 14:07
  • 3
    @Davislor the question is about loading of fontenc, not about loading of arbitrary font packages. Please let the OP decide which answer he likes and understands. – Ulrike Fischer Jan 20 '19 at 14:10
  • I took your advice and edited my own answer to show how to convert my example to use a modern font. – Davislor Jan 20 '19 at 14:44
15

An Example that Might Bite You

It can cause problems if you load both fontspec and fontenc together. More precisely, as David Carlisle points out, if you combine Unicode with other encodings in the same document—which could happen without your being aware that you loaded both, or even on a document that worked before. Here is an example that loads the legacy Utopia font, which is T1-encoded, but then also tries to load a modern Unicode font through Babel.

\documentclass[varwidth, preview]{standalone}
\usepackage[spanish]{babel}

% Due to a bug in Babel 3.22, we must override the OpenType
% language and script features for Japanese, and several other
% languages.
\babelprovide[language=Japanese, script=Kana]{japanese}

% Implicitly causes babel to load fontspec:
\babelfont[japanese]{rm}{Noto Sans CJK JP}

% Implicitly loads fontenc with [T1]:
\usepackage[poorman]{fourier}

\begin{document}
¿Es \foreignlanguage{japanese}{日本} Utopía?
\end{document}

¿Es 日本 Utopía?

Permuting the order in which you load packages can give you many different bugs. One of several problems in this example is that fontspec renders all non-ASCII characters inactive, which prevents them from being correctly translated into other encodings. If you re-ordered commands so that you loaded \setbabelfont after fourier, you would instead set the main font to Latin Modern Roman.

The rest of my post is about how to get that broken example to work, so if you only cared about the example of something fontenc breaks, you can stop reading.

How to Combine Unicode and Legacy Fonts

I’m not judging. Sometimes I don’t get to set the requirements.

To fix this example, load luainputenc, which, despite the misleading name, also allows switching between Unicode and legacy encodings on output:

\documentclass[varwidth, preview]{standalone}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage[utf8]{luainputenc} % Needed to mix NFSS and Unicode
\usepackage[spanish]{babel}
\usepackage[no-math]{fontspec}

\defaultfontfeatures{ Scale = MatchUppercase }
\newfontfamily\japanesefont{Noto Serif CJK JP}[
  Language = Japanese,
  Script = Kana ]

\newcommand\textjapanese[1]{{\japanesefont #1}}

\usepackage[poorman]{fourier}

\begin{document}
¿Es \textjapanese{日本} Utopía?
\end{document}

¿Es 日本 Utopía?

A Better Solution

A quick Web search revealed that there are several free OTF versions of Utopia, which is legal because Adobe released a free and modifiable version years ago. Here, I load Lingua Franca:

\documentclass[varwidth, preview]{standalone}
\usepackage{polyglossia}

\setdefaultlanguage{spanish}

\defaultfontfeatures{ Scale = MatchUppercase, Ligatures = TeX }
\setmainfont{Lingua Franca}[
  Scale = 1.0 ,
  Ligatures = Common ,
  Numbers = OldStyle ]
\newfontfamily\japanesefont{Noto Serif CJK JP}[
  Language = Japanese,
  Script = Kana ]

\newcommand\textjapanese[1]{{\japanesefont #1}}

\begin{document}
¿Es \textjapanese{日本} Utopía?
\end{document}

¿Es 日本 Utopía?

This is much less of a hack and supports several features and scripts that the legacy package does not. You should use Unicode when you can, and legacy encodings when you have to.

Davislor
  • 44,045
  • I am not sure what you mean by "One of several problems in this example is that fontspec renders all non-ASCII characters inactive, " (active/inactive characters are a matter of input, and fontspec does not affect the input encoding at all) – David Carlisle Jan 20 '19 at 22:59
  • @DavidCarlisle Okay, here’s my understanding. The way LaTeX handles legacy encodings is: some characters are supposed to be the same as ASCII in every text encoding, and are just passed through. LGR breaks this assumption, but is intentionally laid out so that ASCII/LGR mojibake gives you a close enough transliteration that a human can figure it out, similar to Γρεεκ. As you know, the first 127 characters of Unicode are also the same as ASCII, and the first 256 the same as ISO Latin-1, so this still works for any characters that are the same in the font encoding. – Davislor Jan 21 '19 at 00:01
  • @DavidCarlisle Other characters, such as the ¿ in my example, do not have the same encoding as in Unicode, so they need to be set active in order to work. When the current encoding is OT1 or T1, IIRC, ¿ would be set active and either mapped to the command\textquestiondown, or the slot in a specific encoding. Loading fontspec and enabling the TU encoding turns this off, so selecting any 8-bit encoding gives you mojibake. Loading luainputenc turns it back on. – Davislor Jan 21 '19 at 00:12
  • 1
    No that's misleading, fontenc never makes any characters active or inactive, that is the job of inputenc (in classic tex) and although the character numbers 127-256 are the same in utf-8 they take two bytes not one, so in pdftex (or in luatex if you load luainputenc and disable the native unicode support) the characters above 127 have to be active, specified as \usepackage[latin1]{inputenc} or \usepackage[utf8]{inputenc} or whatever encoding is in use. So ¿ is not non-active because you loaded fontenc, it is because you haven't loaded inputenc (and inputenc doesn't work in luatex) – David Carlisle Jan 21 '19 at 00:46
  • @DavidCarlisle I’m open to suggestions for how to re-word that passage. What I’m trying to convey in my answer is that. if you load fontenc but not fontspec, LaTeX3 will make some non-ASCII Unicode characters active within the body of the document, even if you don’t explicitly load inputenc or selinput. If you load both fontenc and fontspec, these characters will not be activated and some of them will break. – Davislor Jan 21 '19 at 01:09
13

Note that it is not loading fontenc that is incompatible (fontspec loads fontenc) it is using font encodings other than TU (Unicode). So \fontencoding{T1}\selectfont is the real problem, although that is most commonly activated by

\usepackage[T1][fontenc}

so it is simplest to tell people not to use fontenc.

In addition to the incorrect characters shown in the other answers, even when you get the correct characters, with the xetex and xelatex formats as distributed, hyphenation will be incorrect as only the TU hyphenation patterns are loaded. You can not load hyphenation patterns into a normal document, only when making the format. So setting things up to get correct hyphenation with T1 (or T2 or LGR...) encoded fonts is tricky, not well supported by language packages and will produce documents that will silently produce the wrong results if processed at another site which does not have the custom formats set up.

The situation is different with luatex which can load new hyphenation patterns as a result of declarations in the document, but it is still tricky to get right and in almost all cases it is simpler to use a Unicode encoded font.

user202729
  • 7,143
David Carlisle
  • 757,742
  • Do you know an example where the hyphenation goes wrong due to fontenc and T1? I tried to come up with an example myself, but surprisingly XeLaTeX and LuaLaTeX performed better(!) than pdfLaTeX in the following example https://gist.github.com/moewew/cfe4f8e18c659665eaaca12e7fe44730 – moewe Jan 20 '19 at 12:51
  • @moewe well for english of course it's largely the same but for any accented letter the hyphenation tables will be nonsense for T1 encoded fonts – David Carlisle Jan 20 '19 at 13:25
  • I suspected that accented letters would be the interesting ones, so I tried German words with umlauts. But apart from the "SS"/"ß" issue I could not see a difference in most words I tried. The ones in the example above are the only differences I could find, but they make pdfLaTeX look bad... I thought that maybe your infamous foreign language skills would have something in store ;-) – moewe Jan 20 '19 at 13:36
  • @moewe I'll try to find something later, need to arrange a tabu update first... https://tex.stackexchange.com/questions/471000/tabu-error-since-update – David Carlisle Jan 20 '19 at 13:38
  • Oh, no need to hurry for me. It just intrigued me if there is a common example of this issue since it is often cited and I was surprised to see that in my naive examples I could not find a difference. – moewe Jan 20 '19 at 13:43
  • @moewe I had forgotten your question but as it just came up again: https://chat.stackexchange.com/transcript/message/48876237#48876237 – Ulrike Fischer Feb 05 '19 at 13:59
  • @UlrikeFischer Thank you very much for the example. Surprisingly (at least for me) the hyphenation gets much better with grüßen instead of grü\ss en: only the "SS"/"ß" thing is off. So it's still not the smoking gun I was hoping for. – moewe Feb 05 '19 at 14:15
  • 1
    @moewe with grüßen it will be looked up as intended in the unicode hyphenation tables, but as the font isn't in that encoding you get essentially random characters. For English it's fine, for French it's OK, for German you can get by with SS but for any languages in the latin2 range where T1 and Unicode are very different you will get unreadable nonsense. – David Carlisle Feb 05 '19 at 14:20
  • 1
    @moewe well naturally it gets better with grüßen - in this case you are using the char which is at the position the patterns expect the ß. But this means that you have to choose if you want good hyphenation with bad output (grüßen) or bad hyphenation with good output (grü\ss en). – Ulrike Fischer Feb 05 '19 at 14:30
2

I post this only to show a very simple example that fontenc causes a tangible problem with lualatex:

\documentclass{article}
\usepackage[T1]{fontenc} % <- comment out
\begin{document}
30° % <- unicode degree symbol
\end{document}

With fontenc of T1, lualatex outputs 30ř whereas pdflatex correctly produces 30°.

Ryo
  • 871
  • While this is correct, fundamentally this is not a limitation of the font encoding itself (\newunicodechar{°}{\textdegree} would fix it), more like the LaTeX team doesn't care to make this case correct. (rightfully because you're not supposed to do this anyway) The real problem is that e.g. if you use characters not in T1 encoding (e.g. ỳ, but must be typesetted as \`y for it to come up in the PDF correctly) then copy-paste will separate the accent (not to mention hyphenation). – user202729 Aug 08 '22 at 13:50