TeX/LaTeX and Japanese

Start writing Japanese in LaTeX and you will almost certainly be told to run platex or uplatex. Yet there is no executable by either name. Both are the names of formats loaded by a single engine, euptex — type platex and the first line on screen reads “This is e-upTeX.” Swallow that one fact and about half the confusion around Japanese TeX evaporates. This page covers why Japanese needed special machinery at all, how the three live routes differ (pLaTeX/upLaTeX with dvipdfmx, LuaLaTeX with LuaTeX-ja, and XeLaTeX), and which one to start your first document in.

Why Japanese needed engines of its own

The first reason is blunt: the original TeX could address only 256 characters per font (128 in its earliest days). Fitting in a few thousand everyday kanji — let alone the tens of thousands in the JIS sets — required contrivances such as slicing a font into 256-glyph sub-fonts. The second reason runs deeper: the typesetting rules themselves are different. Western typesetting is built on the assumption that lines break between words and that inter-word space stretches and shrinks. Japanese has no word boundaries. A line may break almost anywhere, so instead the system must be told, as a rule, where a break is forbidden.

Those forbidden positions are the kinsoku rules: no punctuation, closing bracket, long-vowel mark, or small kana at the start of a line; no opening bracket at the end of one. On top of that come the quarter-em gap inserted where Japanese meets Western text (\xkanjiskip), the spacing between Japanese characters themselves (\kanjiskip), the tightening of punctuation, and vertical writing. The pTeX family solves all of this by assigning each candidate break a penalty — so many points if this character lands at the start of a line — and choosing the division of the whole paragraph that minimises the total. In other words, Japanese rules were poured as penalties into the mechanism TeX already had: look at the entire paragraph, then pick the best set of breaks.

The difference between platex and uplatex — and why they are one engine

The difference is the range of characters each can handle: platex stays inside JIS X 0208, uplatex covers all of Unicode. And they are not two programs but two formats loaded by the same euptex engine. Open texmf-dist/web2c/fmtutil.cnf in a TeX Live tree and the relationship is written out in two lines: the first column is the format name, the second is the engine that builds it. In both rows the second column reads euptex. The engine-versus-format distinction shows up more starkly in Japanese than anywhere else.

fmtutil.cnf
# texmf-dist/web2c/fmtutil.cnf -- format, engine, hyphenation, ini file
platex   euptex language.dat *platex.ini
uplatex  euptex language.dat *uplatex.ini

# and so the banner names the engine, not the command you typed:
$ platex  ... This is e-upTeX, Version 3.141592653-p4.1.1-u1.30-... (utf8.euc)   (preloaded format=platex)
$ uplatex ... This is e-upTeX, Version 3.141592653-p4.1.1-u1.30-... (utf8.uptex) (preloaded format=uplatex)

That banner repays a close reading. 3.141592653 is Knuth’s frozen TeX version itself; p4.1.1 is the pTeX extension level; u1.30 the upTeX one — three generations stacked into a single line. The parenthesis at the end matters too: platex reports (utf8.euc), uplatex reports (utf8.uptex). You write your source in UTF-8 either way, but the two formats hold kanji in different internal encodings. That is not an abstraction; it bites. Feed platex a character outside JIS X 0208 — 髙, 𠮷 or 鷗, say — and it stops with this error:

log
! LaTeX Error: Unicode character ^^e9^^ab^^99 (U+9AD9)
               not set up for use with LaTeX.

# same file, same class, run through uplatex instead: compiles silently.

The practical conclusion is simple. There is almost no reason to start a new document on pLaTeX; use uplatex. Variant forms in personal names, old-style kanji, supplementary characters, a quotation in Korean or Chinese — none of these is exotic, and every one of them stops platex dead. The remaining reasons to choose platex are narrow: the class file your venue requires was written for pLaTeX only, or you have inherited an existing source. The pTeX-family engines and macros are maintained today by the Japanese TeX Development Community.

The three routes that are alive today

In practice there are three. upLaTeX producing a DVI file that dvipdfmx turns into PDF — the traditional route; LuaLaTeX with luatexja, emitting PDF directly; and XeLaTeX with xeCJK. A fourth, pdfLaTeX with CJKutf8, exists but requires wrapping your text in \begin{CJK}{UTF8}{min} and offers no serious kinsoku, so it suits only dropping a few Japanese words into an English paper. What separates the three is how they get at fonts, and how long the road to PDF is.

RouteClass and packagesCharacter, and what it suits
uplatex + dvipdfmxjlreq, jsarticle (jsclasses)Fast; the deepest track record for vertical writing; often what journals mandate. Two steps to PDF
lualatex + luatexjajlreq, ltjsarticle (ltjsclasses)Uses system OpenType fonts as they are and writes PDF directly; strongest on Unicode. Slow to build
xelatex + xeCJKbxjsarticle (bxjscls) and similarEasy font selection; good for mixing Chinese and Korean. Weaker than luatexja on fine Japanese rules
pdflatex + CJKutf8article plus the CJK packageA few words inside English text. Needs \begin{CJK}{UTF8}{min} around the text; unsuitable for a whole document

Why the Japanese route still goes through DVI

Because the pTeX-family engines cannot write PDF directly. Where pdfTeX built PDF output in, pTeX finishes its job at TeX’s original output format, DVI. Converting that DVI into PDF is the work of dvipdfmx, which handles embedding the Japanese fonts and the coordinate transforms for vertical text. So the traditional Japanese route splits typesetting and PDF generation between two programs. Run uplatex and then dvipdfmx locally and a few-hundred-byte .dvi becomes a PDF of a few kilobytes; look inside with pdffonts and you can see HaranoAjiMincho embedded as a CID Type 0C font.

shell
$ uplatex doc.tex      # typeset -> doc.dvi
$ dvipdfmx doc.dvi     # convert  -> doc.pdf
$ pdffonts doc.pdf
# HaranoAjiMincho-Regular   CID Type 0C   Identity-H   emb yes

# dvipdfmx is a symlink to xdvipdfmx: one binary serves both
# the Japanese .dvi route and XeTeX's .xdv output.

Incidentally, dvipdfmx on disk is a symlink to xdvipdfmx. One binary serves both the Japanese .dvi route and the .xdv that XeTeX emits. A converter polished for Japanese ended up as XeTeX’s output stage worldwide — a case of a tool made in Japan becoming part of the TeX mainstream. The same goes for the embedded Harano Aji fonts, which ship with TeX Live, so your first Japanese PDF appears without buying a font.

Which one to write your first document in

Write \documentclass{jlreq} and run it through lualatex. The reason is not only quality. Noriyuki Abe’s jlreq is designed around the W3C’s “Requirements for Japanese Text Layout,” but the most useful thing about it in practice is that the same source runs unchanged on LuaLaTeX, upLaTeX, and pLaTeX alike. The engine is detected automatically, and you can name platex, uplatex, or lualatex as a class option if you need to. So your first choice is not an irreversible one. Run the same .tex through both uplatex and lualatex and each produces a PDF with Harano Aji Mincho embedded.

latex
% runs unchanged under lualatex, uplatex and platex
\documentclass{jlreq}
\begin{document}
こんにちは、\LaTeX。日本語の組版です。
\end{document}

When you want different fonts, load luatexja-fontspec under LuaLaTeX and set the serif face with \setmainjfont and the sans face with \setsansjfont. If you lean traditional, the standards are jsclasses (jsarticle, jsbook) for pLaTeX and upLaTeX, and ltjsclasses (ltjsarticle and friends) for LuaLaTeX. But if you pick ltjsarticle, make sure the compiler is LuaLaTeX too: a mismatch between class and engine is the single most common accident in Japanese setups.

Where the first attempt goes wrong

When Japanese does not appear, or appears as mojibake, the cause is nearly always one of two things: the encoding of your source, or a mismatch between class and engine. Save your source as UTF-8. EUC-JP, Shift_JIS, and ISO-2022-JP once coexisted and a converter such as nkf was essential kit; that is no longer the case. upTeX and LuaTeX are Unicode-native and current pLaTeX assumes UTF-8 input as well. Conversion is only needed when you inherit an old source. The other trap is line endings: LF and CRLF mixed in one file can produce breakage whose cause is hard to see.

  • Do not set Japanese body text with pdflatex. If you see errors or mojibake, suspect the compiler setting first; even with CJKutf8 you must wrap the text in \begin{CJK}{UTF8}{min}.
  • If you load ltjsarticle or luatexja, compile with lualatex; for jsarticle, use uplatex. The class decides the engine, so change your editor’s build setting to match.
  • If platex reports ! LaTeX Error: Unicode character ... not set up for use with LaTeX., that character is outside JIS X 0208. Switching to uplatex usually clears it.
  • For co-authored work, record three things in one line of the README: engine, encoding, class. Without all three, the build will not reproduce on someone else’s machine.
  • If your venue distributes a class file written for platex, just use it — but check before submission that no variant characters have crept into the text.