How processing works (DVI/PDF)

LaTeX does not show you the result while you type. You write a plain-text .tex file and compile it to get a PDF — a “write, then process the whole thing at once” model. There are two routes: one goes through an intermediate DVI file, the other produces PDF directly.

Why it is not WYSIWYG

TeX optimizes line breaking by looking at the whole paragraph at once. Adding a single character at the end of a paragraph can therefore change where its very first line breaks. Redoing that on every keystroke would be far too expensive.

So instead of a WYSIWYG word processor that repaints as you type, TeX uses batch processing — it typesets the whole document in one run. You give up live preview, but you gain globally optimal typesetting, consistent formatting across the document, and the automation that plain text makes possible.

From source to output: two routes

An engine processes the .tex you wrote. There are two families of output. On the modern route, pdfTeX, XeTeX, and LuaTeX produce PDF directly. XeTeX and LuaTeX in particular read Unicode input and can use the OpenType fonts already installed on your system.

On the legacy route, the engine first emits a DVI file. DVI stands for *device independent* — a pure description of the page that is not tied to any particular output device. A dvi driver then converts it: dvipdfmx to PDF, dvips to PostScript, dvisvgm to SVG. A driver that renders to the screen is called a dvi viewer. The Japanese formats pLaTeX and upLaTeX use this DVI route.

# Direct PDF (modern engines)
lualatex document.tex        # → document.pdf

# Via DVI (legacy route, e.g. Japanese upLaTeX)
uplatex  document.tex        # → document.dvi
dvipdfmx document.dvi        # → document.pdf

As an exception, pdfLaTeX keeps the old (largely non-Unicode) input style yet outputs PDF directly, without DVI. It helps to treat “DVI vs direct PDF” and “Unicode / system fonts or not” as two separate axes.

Helper files and the “compile twice” rule

Compiling produces, besides the PDF, helper files such as .aux (labels and reference data), .toc (the table of contents), and .log (a record). Cross-references and the table of contents need two passes: the first pass writes numbers and positions (“which page is Chapter 3 on?”) to .aux, and the second pass reads them back to fill in \ref and the contents list.

So when you see ?? in the output, or a warning like *Rerun to get cross-references right*, the fix is simply to compile again. Bibliographies (BibTeX/biber) and indexes (makeindex) add still more passes.

Stop counting passes — latexmk and editors

Counting passes by hand is tedious. **latexmk** watches files like .aux and reruns the engine exactly as many times as needed, invoking BibTeX/biber and makeindex when required, and stopping once the output is stable.

latexmk -lualatex document.tex   # LuaLaTeX, as many passes as needed
latexmk -pdf     document.tex     # pdfLaTeX
latexmk -c                        # clean .aux/.log and friends

Editors and services such as VS Code (LaTeX Workshop), TeXShop, and Overleaf usually call latexmk under the hood, so you just press “compile.” And when SyncTeX is enabled, you can click to jump between a line in the source and the matching spot in the PDF.