"command_line_encoding=utf8" in texmf.cnf on windows?

ttk at t-lab.opal.ne.jp ttk at t-lab.opal.ne.jp
Tue Apr 2 17:42:46 CEST 2019

I explain about supporting Unicode characters on Windows console (incl file names).

In resent TeX Live/W32TeX,
Akira-san and I have implemented a function which treat UTF-8 on the console of Windows.
If you set a option "command_line_encoding=utf-8" in your texmf.cnf,
the current version will accept utf-8 strings.
As Akira-san wrote,
it affects on engines pdftex, xetex, (e)uptex and drivers dvipdfmx, dvips.

I expect following examples will work:

     pdflatex DieÜbung.tex


     pdflatex -file-line-error -interaction=nonstopmode "\input{\detokenize{DieÜbung.tex}}"

In my environment (W32TeX, LaTeX2e <2018-04-01> patch level 5),
the following test case runs correctly.

% -*- coding: utf-8 -*-

Happy \TeX-ing!!


%%% locale: UTF-8
%%% ö : U+00F6, UTF-8 0xC3 0xB6
%\include{\detokenize{schön}}%  Files schön.tex, schön.aux must be read. However, it fails to read *.aux.
\includegraphics[width=30mm,bb=0 0 550 568]{\detokenize{schön.jpg}}
\includegraphics[width=30mm,bb=0 0 550 568]{\detokenize{schön.png}}
\includegraphics[width=30mm,bb=0 0 550 568]{\detokenize{schön.pdf}}


## Side effect
If someone prefers legacy 8bit encodings such as latin1, Shift_JIS
and writes source files of pdf(la)tex, p(la)tex in the legacy encoding,
"command_line_encoding=utf-8" might cause errors.
The setting "command_line_encoding=none" turns the function off.
I do not expect any side effect on XeTeX and upTeX engines (which assume UTF-8)
and combination of pdfTeX and UTF-8.

I do not know which ("none" or "utf-8") is better for default setting.
But, IMHO,
it is just only a kind of user preference.

Takuji Tanaka

More information about the tex-live mailing list