A LaTeX build ends in a PDF, but it gets there one of two ways — directly (pdfTeX/LuaTeX/XeTeX write the PDF) or via DVI (latex/(u)platex → dvipdfmx). Which route you take affects things like which graphics formats you can include. This page explains both and their differences (the commands themselves are in “Compile commands” and “DVI converters”).
Two routes to PDF
On the direct route, pdflatex (pdfTeX), lualatex (LuaTeX), and xelatex (XeTeX, via an internal .xdv) write the PDF in one step. On the DVI route, latex or the Japanese (u)platex first produce DVI, which dvipdfmx then converts to PDF (two steps). Japanese (u)platex normally takes this route.
| Route | Command | To PDF |
|---|---|---|
直接 / Direct | pdflatex, lualatex, xelatex | One step |
DVI 経由 / Via DVI | latex, (u)platex → dvipdfmx | Two steps |
Graphics formats differ by route
This is the difference you feel most day to day. The direct route (pdfTeX/LuaTeX) includes PDF, PNG, and JPEG, but not EPS directly — convert it with epstopdf (the package of the same name, or automatically with --shell-escape). The DVI route (dvipdfmx) handles PNG/JPEG/PDF and can also pull in EPS by calling Ghostscript behind the scenes. A legacy workflow with lots of EPS fits the DVI route naturally.
\usepackage{graphicx}
\includegraphics{figure.png} % 直接経路: PDF/PNG/JPEG / direct route: PDF/PNG/JPEGThe driver is auto-detected
Packages like graphicx, color, and hyperref need to know the output driver (pdftex, luatex, xetex, dvipdfmx, dvips, dvisvgm) to emit the right low-level instructions. Happily, they detect it automatically from how you compile — so do not pass a driver option by hand; doing so tends to cause conflicts. Just compile with the right command and it works.
Which route to use
- Mostly English, quick → direct (
pdflatex). - System fonts, Unicode, direct PDF →
lualatex/xelatex(direct). - Japanese ((u)platex) → via DVI (
dvipdfmx). - Legacy EPS-heavy work → via DVI (Ghostscript pulls it in), or convert with
epstopdfon the direct route.