「LaTeX のエンジンはどれを使えばいいのか」——pdfLaTeX、XeLaTeX、LuaLaTeX、upLaTeX の四択で迷ったときのための、結論から書く判断ガイドです。先に答えを言うと、欧文なら pdflatex、システムフォントや多言語が要るなら xelatex か lualatex、日本語なら uplatex か lualatex。ただしこの四つは同格の選択肢ではありません。どれも同じ LaTeX フォーマットを走らせていて、違うのはその下のエンジンだけです。以下では XeLaTeX と LuaLaTeX の直接対決、日本語で答えが変わる理由、そして乗り換えたときに実際に壊れるものを順に見ていきます。
目的別のいちばん短い答え
大多数の人にとっては、この四行で足ります。ここでいう名前は エンジン(実行されるプログラム)× フォーマット(LaTeX という命令体系) の組み合わせで、実際に打つコマンド名で示しています。迷ったら、まず投稿先やテンプレートが指定するものに従ってください。それが無いときだけ、下の分岐を使います。
- 欧文(英語・ヨーロッパ諸語)を、いちばん確実に → pdfLaTeX(
pdflatex)。LaTeX の事実上の標準で、資料も前例も最多。微細組版も全機能が使えます。 - OS のフォントをそのまま使いたい、多言語を混ぜたい、設定は軽く → XeLaTeX(
xelatex)。fontspecで\setmainfont{...}と書けば済みます。 - 同じことに加えて、プログラムで組版を制御したい/長期的に安全な側に立ちたい → LuaLaTeX(
lualatex)。Lua で組版に介入でき、カーネル側のエンジン固有の新機能もここに先に入る傾向があります(ltnews34の LuaTeX コールバック関連の項目など)。 - 日本語 → upLaTeX(
uplatex)が安定した主流、LuaLaTeX +luatexjaが Unicode ネイティブな現代的経路。XeLaTeX はここでは推奨しません(理由は後述)。jlreqクラスは前二者のどちらでも動きます。
XeLaTeX と LuaLaTeX はどちらを選ぶか
この二つは「どちらも Unicode とシステムフォントが使える」ところまでは同じなので、いちばん迷われます。判断は一行で決まります——いま動いている文書を軽く速く仕上げたいなら XeLaTeX、これから長く育てる文書なら LuaLaTeX。 両者の差は機能表の勝ち負けではなく、払うコストの種類 の違いです。XeLaTeX は設定と待ち時間が安く、LuaLaTeX は将来と拡張性が安い。以下の表を、この観点で読んでください。
| 論点 | XeLaTeX | LuaLaTeX |
|---|---|---|
fontspec | 使える。OS のフォント名をそのまま渡せるので、名前を試しながら詰めるのが速い | 使える。フォントの解決は luaotfload が担当し、指定の書き方はより厳密 |
microtype | 字送りの突き出しのみ。 フォント伸縮も文字間調整も letterspacing も効かない | 突き出しとフォント伸縮の両方。 letterspacing も効き、欧文の仕上がりは pdfLaTeX に近い |
speed | 中くらい。起動も組版も LuaLaTeX より軽い | いちばん遅い。大きな文書では pdfLaTeX の数倍かかることがある |
programmability | TeX のマクロのみ。エンジンに手を入れる口は無い | Lua が中に入っている。\directlua とコールバックで組版処理そのものに介入できる |
output-route | いったん .xdv を経由し、内蔵の xdvipdfmx が PDF にする | PDF を直接書き出す。中間ファイルは無い |
japanese | 実用的な選択肢ではない。jlreq はそもそも XeLaTeX を受け付けない | luatexja で本格的に組める。jlreq も lualatex オプションで対応 |
pstricks | DVI 系の経路を通るので動く。既存の PSTricks 資産があるならこちら | 基本的に動かない。PSTricks の図は移植が要る |
development | 安定して保守されているが、新機能の中心ではない | エンジン固有の新機能はここに先に入る傾向がある |
この表から実務的な線引きが引けます。XeLaTeX を選ぶのは——手元のフォントを名前で指定してすぐ組みたいとき、多言語の混植が主目的で欧文の微細組版に強いこだわりが無いとき、既存の PSTricks の図を抱えているとき、そしてコンパイルの待ち時間が体感で効くほど頻繁に回すとき。LuaLaTeX を選ぶのは——欧文の仕上がりを詰めたい(microtype のフォント伸縮が要る)とき、日本語を Unicode で扱いたいとき、外部データを読んで表を組むなど組版そのものをプログラムしたいとき、そして数年単位で保守する文書のとき。なお日本語では、この二択に XeLaTeX は入ってきません。
日本語ではどのエンジンを選ぶか — 答えが変わる理由
日本語では uplatex か lualatex の二択で、XeLaTeX は外れます。 英語圏の記事だと「Unicode とシステムフォントなら XeLaTeX か LuaLaTeX」で話が終わりますが、日本語ではその等式が成り立ちません。理由は、日本語の組版が「Unicode の文字が出せること」よりずっと多くを要求するからです——禁則処理、和欧文間の四分アキ、縦組み、ルビ、そして和文専用のフォントメトリック(JFM)。これらを実装した層が要り、その層は pTeX 系エンジン と LuaTeX 用の luatexja にしか存在しません。
この事実は、クラスファイルの側からも確かめられます。JIS X 4051 に沿った日本語組版クラス jlreq は、エンジンをオプションで受け取りますが、jlreq.cls が認めるのは platex・uplatex・lualatex の三つだけで、xelatex は選択肢に入っていません。XeLaTeX で日本語を扱う道が皆無というわけではなく、zxjatype のようなパッケージは存在します。しかし主要な日本語クラスと文献の蓄積は上の三つに集中しており、投稿先が用意する日本語テンプレートもまずこの範囲です。「日本語を含むなら XeLaTeX は最初の候補にしない」 が実務上の結論です。
では uplatex と lualatex のどちらか。既存の資産があるなら uplatex、新規で長く使うなら lualatex が素直な線引きです。uplatex は速く、日本語の組版規則がよく枯れており、学会や出版社が配るクラスの多くがこれを前提にしています。ただし出力は必ず DVI なので、dvipdfmx を通す二段構えになり、フォントも従来方式で指定します。lualatex + luatexja は Unicode とシステムフォントをそのまま使え、luatexja-fontspec で和文フォントを名前で指定できますが、組版時間は目に見えて長くなります。なお和文フォントの指定に素の fontspec は使いません。
判断を分ける軸
手っ取り早い答えが当てはまらないとき、あるいは理由を知りたいときのために、軸を一つずつ見ていきます。ほとんどの軸は結局、そのエンジンがフォントと文字コードをどう扱うか に帰着します。
フォント。 pdfTeX は TeX 伝統のフォントモデル、すなわち TFM(TeX Font Metric)と Type1/PK フォント を使います。OS にインストールされたフォントをそのまま指すことはできません。XeTeX と LuaTeX がもっとも鋭く分かれるのがここで、両者は システムに入っている TrueType / OpenType フォントを直接使え、fontspec パッケージで \setmainfont{Times New Roman} のように名前で指定します。逆に言うと fontspec は XeTeX か LuaTeX を必要とし、pdfLaTeX では動きません。
入力の文字コード。 XeTeX と LuaTeX は内部が Unicode ネイティブ で、UTF-8 のソースをそのまま受け取ります。pdfTeX も 2018 年の LaTeX リリース以降 UTF-8 が既定の入力エンコーディングになり、\usepackage[utf8]{inputenc} を書く必要はなくなりました。しかし内部では 8 ビットのフォントエンコーディング(T1 など)へ写像 しているので、どの文字が出るかは fontenc とフォント次第で、任意の Unicode 文字や CJK をそのまま打ち込むことはできません。多言語の文字や記号を気楽に打ちたいなら XeTeX / LuaTeX に分があります。
パッケージの互換性。 ここが実務でいちばん見落とされる落とし穴です。エンジン専用のパッケージがあります。fontspec と unicode-math は XeTeX / LuaTeX 専用。逆に pstricks は DVI 経路を通る pdfLaTeX と XeLaTeX では動きますが、LuaLaTeX では原則として動きません。逆向きの非互換もあって、古いチュートリアルに従って書いたソースが新しいエンジンで通らないこともあります。まず何より、テンプレートや投稿先のクラスがどのエンジンを要求しているかを確かめる のが鉄則です。
速度。 差は実在し、体感できます。順序は pdfTeX がもっとも速く、XeTeX が中間、LuaTeX がもっとも遅い。ただし差が出るのは起動ではなく、組版量に比例する部分です。空に近い 1 ページの文書ではほとんど差がありませんが、数百ページ規模になると LuaLaTeX は pdfLaTeX の数倍の時間を要します(実測値は LuaTeX のページに載せてあります)。原稿を書いている間の再コンパイルは何百回にもなるので、この差は積み上がります。逆に言えば、十数ページの論文では気にする必要がありません。
微細組版(microtype)。 欧文の見た目を確実に押し上げるのが microtype の 文字の突き出し(protrusion) と フォントの伸縮(expansion) です。ここでのエンジン差は大きく、しかも microtype 自身の README に明記されています——突き出しは pdfTeX・LuaTeX・XeTeX の三つで効きますが、フォントの伸縮は pdfTeX と LuaTeX のみで、XeTeX では効きません。さらに 単語間隔と追加カーニングの調整は pdfTeX 専用、リガチャの無効化と字送り(letterspacing)は pdfTeX と LuaTeX です。欧文の仕上がりを最優先するなら pdfLaTeX、次点で LuaLaTeX が安全な選択です。
図版とプログラマビリティ。 PNG・JPEG・PDF の取り込みは、どのエンジンでも graphicx の \includegraphics でほぼ同じように書けます(pdfLaTeX は EPS を自動変換します)。差が出るのは LuaTeX 固有の Lua による制御 で、組版の各段階にフックを掛けたり、外部データを読み込んで表を組んだりといった、マクロでは書きにくい処理が書けます。fontspec や unicode-math を含む現代的なパッケージ群とも相性がよく、これが「将来に強い」と言われる根拠です。
四つの選択肢を並べた比較表
判断の軸に沿って四つの主要な選択肢を並べます。第 1 列は実際に打つコマンド名です。microtype は突き出しと伸縮を分けて示しました。表は目安であって判決ではありません——pdfLaTeX も \usepackage[T1]{fontenc} と適切な欧文フォントパッケージを組み合わせれば多くのヨーロッパ言語を美しく組めますし、XeLaTeX でも突き出しは効きます。「できる/できない」の二値ではなく、手間と仕上がりの釣り合い として読んでください。
| コマンド | Unicode / システムフォント | microtype | 速度 | 主な用途 |
|---|---|---|---|---|
pdflatex | 不可(TFM/Type1。UTF-8 入力は可だが 8 ビットに写像) | 突き出し 可 / 伸縮 可 | もっとも速い | 欧文の既定。互換性がもっとも広い |
xelatex | 可(fontspec で OpenType を直接) | 突き出し 可 / 伸縮 不可 | 中間 | 多言語と OpenType を手軽に |
lualatex | 可(fontspec に加え Lua による制御) | 突き出し 可 / 伸縮 可 | もっとも遅い | 現代的・長期向け。日本語は luatexja で |
uplatex | 和文は JFM(DVI 経路)。UTF-8 入力は可 | 欧文部分に限られる | 速い | 日本語の論文。安定した既定 |
小さな試験ファイルで決める
書き始める前に、候補のエンジンを 1 ページの試験ファイルで走らせてください。 学位論文や投稿原稿の途中でエンジンを変えると、フォント・図版・参考文献・改行位置が一度に動き、何が原因で崩れたのか分からなくなります。見るべきは「通るかどうか」だけではありません。ログの警告、PDF のフォント埋め込み、図版の扱い、そして共同作業者が同じ手順を再現できるか——この四点です。
# 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- 投稿先のテンプレートがあるなら、そのテンプレートで試す。 空のファイルが通っても、提出用の設定が通る証拠にはなりません。
- 図を 1 枚、別行立ての数式を 1 本、参考文献を 1 件入れる。 本原稿の縮図になっていないと試験の意味がありません。
- 文献と索引のツールも同時に確かめる。 BibTeX か Biber か、
mendexかupmendexかでlatexmkの設定が変わります。エンジンだけ決めても、ここが噛み合わなければビルドは通りません。 - 決めたら
.latexmkrcか README にエンジンを書き留め、以後うっかり別のエンジンでコンパイルしないようにします。 - PDF を見比べる。 改行位置やフォントが違ったら、なぜそのエンジンを選んだのかをプロジェクトの中に残しておきます。
エンジンを乗り換えるときに壊れるもの
同じソースでも、エンジンを変えれば結果は変わります。実際によく踏む地雷は次の四つです。
フォントとエンコーディングの設定が変わります。 pdfLaTeX の定番だった \usepackage[utf8]{inputenc} と \usepackage[T1]{fontenc} は、XeLaTeX / LuaLaTeX では 不要で、ふつうは書きません(内部が Unicode だからです)。代わりに fontspec と \setmainfont を使います。pdfLaTeX のプリアンブルをそのまま持ち込むと、警告やフォント関連のエラーになることがあります。
% 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 の効き方が変わります。 同じ \usepackage{microtype} でも、エンジンによって実際に働く機能が違います。XeLaTeX ではフォントの伸縮が単に無効になるので、pdfLaTeX で追い込んだ組版を移すと、行長や改行位置がわずかにずれます。数十ページの文書では、ページ数が 1 ページ増減することも珍しくありません。
使えるパッケージが入れ替わります。 移行先で動かなくなるもの、逆に初めて使えるようになるものがあります。PSTricks で描いた図は LuaLaTeX に持っていくと動きません(pstricks が非対応です)。逆に fontspec と unicode-math は pdfLaTeX では使えません。学会や出版社のテンプレートはたいてい 特定のエンジンを前提にしている ので、まずそれに従うのが安全です。
日本語では、和文フォントの設定がまるごと変わります。 upLaTeX(pTeX 系)と LuaLaTeX + luatexja では、和文フォントの指定の書き方も PDF への埋め込み方も別物です。欧文文書よりも移行の痛みは大きいと見積もってください。具体的なコマンドの対応は「コンパイルのコマンド」のページにまとめてあります。