Choosing an engine/format

“Which LaTeX engine should I use?” — this is a decision guide for that question, answer first. The short version: pdflatex for Western text, xelatex or lualatex when you need system fonts or Unicode, and uplatex or lualatex for Japanese. But these four are not four equal options. All of them run the same LaTeX format; what differs is the engine underneath. What follows is the head-to-head between XeLaTeX and LuaLaTeX, the reason the answer changes for Japanese, and what actually breaks when you switch.

The shortest answer, by purpose

For most people these four lines are enough. The names below are combinations of an engine (the program that runs) and a format (LaTeX, the command system), given as the command you actually type. When in doubt, first obey whatever your submission target or template specifies; only when nothing is specified do you get to use the branches below.

• Western text (English and European languages), the surest path → pdfLaTeX (pdflatex). LaTeX’s de facto standard, with the most documentation and prior art — and the only engine where every micro-typographic feature works.
• You want to use the operating system’s fonts, mix languages, and keep configuration light → XeLaTeX (xelatex). With fontspec, \setmainfont{...} is all it takes.
• All of that, plus programmable control over typesetting and a bet on the future → LuaLaTeX (lualatex). You can reach into typesetting from Lua, and engine-specific kernel work tends to land here first — see the LuaTeX callback entries in ltnews34.
• Japanese → upLaTeX (uplatex) is the stable mainstream; LuaLaTeX with luatexja is the modern, Unicode-native route. XeLaTeX is not recommended here — the reason is below. The jlreq class works with either of the first two.

XeLaTeX vs LuaLaTeX: which one to choose

These two go together as far as “both handle Unicode and system fonts,” which is exactly why the choice between them causes the most hesitation. One line settles it: XeLaTeX if you want the document in front of you finished lightly and quickly; LuaLaTeX if this is a document you will keep growing for years. The difference is not a scoreboard of features but which kind of cost you pay: XeLaTeX is cheap in configuration and waiting; LuaLaTeX is cheap in future-proofing and extensibility. Read the table below with that in mind.

From that table a practical line can be drawn. Choose XeLaTeX when you want to name a font on your machine and typeset immediately; when mixing scripts is the point and you have no strong stake in Western micro-typography; when you are carrying existing PSTricks figures; and when you recompile often enough that waiting is felt. Choose LuaLaTeX when you want Western output tuned to the last (you need microtype’s font expansion); when Japanese has to be handled in Unicode; when you want to program the typesetting itself, say reading external data to build tables; and when the document will be maintained for years. For Japanese, note, XeLaTeX does not enter this choice at all.

Which engine for Japanese, and why the answer changes

For Japanese the choice is between uplatex and lualatex; XeLaTeX drops out. English-language articles usually stop at “XeLaTeX or LuaLaTeX if you need Unicode and system fonts,” but that equation does not hold for Japanese. The reason is that Japanese typesetting demands far more than the ability to emit Unicode characters: kinsoku line-breaking rules, the quarter-em space between Japanese and Western text, vertical writing, ruby, and Japanese-specific font metrics (JFM). A layer implementing all of that is required, and such a layer exists only for the pTeX family of engines and, for LuaTeX, in luatexja.

The class files bear this out. jlreq, the Japanese typesetting class that follows JIS X 4051, takes the engine as an option — and the engines jlreq.cls accepts are exactly three: platex, uplatex and lualatex. xelatex is not among them. It is not that Japanese under XeLaTeX is impossible; packages such as zxjatype exist. But the major Japanese classes and the accumulated body of documentation sit with those three, and the Japanese templates a journal or university hands you will almost always be within that range. The practical conclusion: if the document contains Japanese, do not make XeLaTeX your first candidate.

So, uplatex or lualatex? The natural line is uplatex when you have existing material, lualatex when starting fresh on something long-lived. uplatex is fast, its Japanese composition rules are thoroughly seasoned, and most classes distributed by learned societies and publishers assume it. Its output is always DVI, though, so you run a two-step pipeline through dvipdfmx, and fonts are configured the traditional way. lualatex with luatexja uses Unicode and system fonts as they are, and luatexja-fontspec lets you name Japanese fonts directly — but typesetting time grows noticeably. Note that plain fontspec is not what selects the Japanese fonts.

The axes that decide it

For when the quick answer does not fit — or when you want to know why — here are the axes one at a time. Most of them come back in the end to how the engine handles fonts and character encoding.

Fonts. pdfTeX uses TeX’s traditional font model: TFM (TeX Font Metric) plus Type1 or PK fonts. It cannot simply point at a font installed on your operating system. This is where XeTeX and LuaTeX diverge most sharply — both can use the TrueType and OpenType fonts already on the system directly, named through the fontspec package as in \setmainfont{Times New Roman}. Turned around, fontspec requires XeTeX or LuaTeX and does not work under pdfLaTeX.

Input encoding. XeTeX and LuaTeX are Unicode-native internally and take UTF-8 source as it comes. pdfTeX has also used UTF-8 as its default input encoding since the 2018 LaTeX release, so \usepackage[utf8]{inputenc} is no longer needed — but internally it still maps onto 8-bit font encodings such as T1, so which characters work depends on your fontenc and your font, and you cannot simply type arbitrary Unicode or CJK. For typing multilingual text and symbols without fuss, XeTeX and LuaTeX have the edge.

Package compatibility. This is the pitfall most often missed in practice. Some packages are engine-specific. fontspec and unicode-math are XeTeX/LuaTeX only. Conversely pstricks works under the DVI-routed pdfLaTeX and XeLaTeX but, as a rule, not under LuaLaTeX. The incompatibility runs the other way too: source written to follow an old tutorial may not compile on a newer engine. The cardinal rule is to check which engine your template or journal class demands before anything else.

Speed. The difference is real and you can feel it. The ordering is pdfTeX fastest, XeTeX in the middle, LuaTeX slowest — but the gap opens in the part that scales with the amount of typesetting, not in start-up. On a near-empty one-page document the three are almost indistinguishable; at a few hundred pages LuaLaTeX takes several times pdfLaTeX’s wall time (measured figures are on the LuaTeX page). Over the hundreds of recompiles a real writing session involves, that adds up. Read the other way: on a paper of a dozen pages it is not worth worrying about.

Micro-typography (microtype). What reliably lifts the look of Western text is microtype’s character protrusion and font expansion. The engine differences here are large, and they are stated outright in microtype’s own README: protrusion works on all three of pdfTeX, LuaTeX and XeTeX, but font expansion works only with pdfTeX and LuaTeX, not XeTeX. Beyond that, adjustment of interword spacing and of kerning is pdfTeX-only, while disabling ligatures and letterspacing require pdfTeX or LuaTeX. If Western polish comes first, pdfLaTeX, with LuaLaTeX as runner-up, is the safe call.

Graphics and programmability. Importing PNG, JPEG and PDF is written essentially the same way on every engine, through graphicx and \includegraphics (pdfLaTeX converts EPS for you). Where they part is LuaTeX’s distinctive control from Lua: you can hook into the stages of typesetting, or read external data to build a table — things that are awkward to write as macros. It also sits well with the modern package stack including fontspec and unicode-math, which is the basis for calling it future-proof.

The four options side by side

Here are the four main options laid out along the deciding axes; the first column is the command you actually type, and microtype is split into protrusion and expansion. Treat the table as a guide, not a verdict — pdfLaTeX paired with \usepackage[T1]{fontenc} and a suitable Western font package sets many European languages beautifully, and protrusion still applies under XeLaTeX. Read it less as a binary of “can / cannot” and more as a balance of effort against polish.

Decide with a small trial file

Before you start writing, run your candidate engines on a one-page trial file. Changing engines partway through a thesis or a submission moves fonts, figures, bibliography and line breaks all at once, and hides the cause of any trouble. What you check is not only whether it compiles. Look at the warnings in the log, at font embedding in the PDF, at how the figures came out, and at whether a collaborator can reproduce the same steps — those four.

# Western candidates: same source, three engines.
$ pdflatex engine-test.tex
$ xelatex  engine-test.tex
$ lualatex engine-test.tex

# Japanese candidate: upLaTeX writes DVI, dvipdfmx makes the PDF.
$ uplatex   engine-test.tex
$ dvipdfmx  engine-test.dvi

# Then compare what actually came out.
$ pdffonts engine-test.pdf     # are all fonts embedded?
$ grep -i warning engine-test.log

• If a target template exists, test with that template. A blank file compiling proves nothing about the submission setup.
• Include one figure, one displayed equation and one bibliography entry. A trial that is not a miniature of the real manuscript tests nothing.
• Check the bibliography and index tools at the same time. BibTeX versus Biber, and mendex versus upmendex, change the latexmk configuration. Settling the engine alone is not enough: if these do not line up, the build still fails.
• Once chosen, write the engine into .latexmkrc or the README so nobody casually compiles the project with a different one later.
• Compare the PDFs. If line breaks or fonts differ, leave the reason for the choice inside the project.

What breaks when you switch engines

Identical source can produce a different result once the engine changes. These are the four mines people actually step on.

Font and encoding setup changes. The pdfLaTeX staples \usepackage[utf8]{inputenc} and \usepackage[T1]{fontenc} are unnecessary under XeLaTeX and LuaLaTeX and are normally omitted — those engines are Unicode internally. You reach for fontspec and \setmainfont instead. Carrying a pdfLaTeX preamble straight over can produce warnings or font-related errors.

% For pdfLaTeX (traditional; both lines are optional on current LaTeX)
%   \usepackage[utf8]{inputenc}
%   \usepackage[T1]{fontenc}

% For XeLaTeX / LuaLaTeX: name an OS or TeX font instead
\usepackage{fontspec}
\setmainfont{TeX Gyre Termes}

microtype behaves differently. The same \usepackage{microtype} yields different effects per engine — under XeLaTeX, font expansion is simply off. Layout tuned under pdfLaTeX therefore shifts slightly once moved: line lengths and break positions change. Over a document of some tens of pages, it is not unusual for the page count to move by one.

The set of usable packages changes. Some packages stop working on the target engine and others become available for the first time. Figures drawn with PSTricks will not run if you move them to LuaLaTeX, which does not support pstricks; conversely fontspec and unicode-math are unavailable under pdfLaTeX. Journal and publisher templates usually assume a specific engine, so following that first is the safe move.

For Japanese, the whole CJK font setup changes. upLaTeX (the pTeX family) and LuaLaTeX with luatexja differ both in how you name Japanese fonts and in how they are embedded. Budget more pain for a Japanese migration than for a Western one. The concrete command equivalents are gathered on the “Compile commands” page.