LaTeX の inputenc で UTF-8 が既定になった場合？

[aminophen]

たったいま LaTeX team の David さんから，「LaTeX の inputenc のデフォルトを UTF-8 にしたい」という連絡がありました。 latex3/latex2e#24

pLaTeX / upLaTeX 系列で問題が起きるのであれば，早めにフィードバックしたいと思います。

[zr-tex8r]

整理してみた。

---

欧文LaTeXの場合の議論：

• 旧仕様
  • 既定の入力文字コードはASCII（7ビット）だった。
  • なので、既定の状態で入力に高位バイトを含めるのは不正。
  • 8ビットの文字コード（Latin-1とかUTF-8とか）で入力したいなら、inputencの読込が必要。
• 新仕様
  • 既定の入力文字コードがUTF-8になる。
  • UTF-8はASCIIの完全な上位互換なので、従来通りASCIIも可能。
  • 8ビットの文字コードを使用するためにinputencが使える（はず）。UTF-8の指定も可能（だけどそれは何もしない）。
• 比較
  • inputencを読み込む場合は何も変わらない。
  • inputencを読み込まない場合、入力の文字コードがASCIIからUTF-8に変わるが、先述の通り、これは問題がない。
  • つまり、LaTeXの仕様に従っているなら、互換性は保たれる。

(u)pLaTeXの場合の議論：

• 問題なさそうな点：
  • 入力の文字の和文と欧文の区別は字句解析の段階で決まるので、inputencの状態は関係がない。
    • この際に関わるTeXエンジンのパラメタはkcatcodeだけで、inputencがこれを変えるわけがない。
  • 一旦和文扱いされた文字（和文文字トークン）はinputencの影響を受けない。
• (u)pLaTeXに特有の、問題があるかもしれない点：
  • 「inputencが読み込まない場合は入力文字コードはASCIIである」というのは(u)pLaTeXでは成立しない。日本語の文字コード（SJIS/EUC/UTF-8）が使われる。
  • UTF-8はSJISやEUCに対して上位互換ではない。

[okumuralab]

特に問題はなさそうに思います。

[aminophen]

結局，

Shift-JIS あるいは EUC-JP で書かれた pLaTeX ソースを \usepackage[utf8]{inputenc} で処理した時に問題が起きる例があるかどうか

を調べればいいのですかね？

[aminophen]

(u)pLaTeXに特有の、問題があるかもしれない点：

も，結局は「問題なさそうな点：」の下では (u)pLaTeX 特有の問題は無さそうに私は感じました。

さて，既に latex3/latex2e#24 に書きましたが，inputenc で UTF-8 が既定になると，欧文 LaTeX でも

\includegraphics{image-å.eps} や \input{text-å.tex}

みたいな「8-bit 欧文を含むファイル名の読込」で変なエラーが発生するようになります。デフォルトの変更を“巻き戻す”パッケージは存在しない（latexrelease とかの対象外）ため，e-TeX の \detokenize を使った回避が必要とのことです。

＃ \usepackage[ascii]{inputenc} とすれば一見巻き戻せそうに思いますが，実際には

! Package inputenc Error: Keyboard character used is undefined
(inputenc)                in inputencoding `ascii'.

でエラーになり，サポートされません。

[zr-tex8r]

(u)pLaTeX 特有の問題は無さそうに私は感じました。

たぶんそうでしょうね。

• 和文扱いの部分は影響しない。
• 欧文扱いの部分は「欧文LaTeXと同じ」なんだからその仕様が適用されると考えるべきで、inputenc非読込なら“欧文部分はASCII”であり欧文の高位バイトは出現してはいけない。

ということなんだと思います。

[zr-tex8r]

「8-bit 欧文を含むファイル名の読込」で変なエラーが発生するようになります

高位バイトがアクティブになった（"80～"FFのカテゴリコードが12→13に変更）ことの影響ですね。自分はこれをパッケージ実装者の観点から考えていて次のようなことを考えていました。

• 何れにしてもinputencが読み込まれたらその状態になるのだから、それに対応していない実装は不十分である。
• しかし、「その状態であるか」を「inputencに対する \@ifpackageloaded」で判断している場合は問題が出る。

[zr-tex8r]

「inputenc しない場合はASCIIしか使えない」はこれはLaTeXの“事実上の仕様”のようなもので、実際には高位バイト（"80～"FF）を入力してもエラーにはなりません。ではどういう挙動になるのかというと、高位バイトのカテゴリコードが12なので、そのまま現在のフォントの「そのバイト値のグリフ」が出力されることになります。

なので、「LaTeX文書ファイルの文字コードをフォントのものと一致させる(※)」と確かに正しい出力が得られるのですが、そもそも(La)TeXのフォントは独自の文字コード（OT1、T1、T2A、…）に従っているので、(※)の前提は“ほぼありえない”ことです。また、そういう使い方を公式に認めてしまうと、「フォントエンコーディングを変更しても、サポートされる文字の範囲では、出力の文字列は変わらない」というLaTeXの仕様が崩れてしまいます。従って、(※)の使い方は不正であると判断すべきだと思います。

と言っておいて、敢えて(※)を利用した文書ソースを挙げておきます。

% encoded in Latin-1
\documentclass[a4paper]{article}
\usepackage{lmodern}
% because LY1 is compatible with Latin-1...
\usepackage[LY1]{fontenc}
% inputenc not loaded
\begin{document}

``¿But aren't Kafka's Schloß and Æsop's {\OE}uvres often naïve
vis-à-vis the dæmonic ph{\oe}nix's official rôle in fluffy soufflés?''

\end{document}

※ちなみに、ファイル文字コードをWindows-1252（winansi）にすると、全部の特殊文字が直接入力できて、しかもLY1と互換であるため所望の出力が得られます。

こういう類の使い方は、TeX UK FAQ のトピックにもなっているほどなので、実際に行われている（いた）のでしょう。

• Why bother with inputenc and fontenc?

そして、これはUTF-8 inputencが既定になると破綻します。LaTeX teamがこのことを知らないはずはないと思うので、恐らく「LaTeXの仕様に反して不正」と扱われているのだと思います。

※\usepackage[latin1]{inputenc}を追加すると何の問題もないソースになります。

[aminophen]

フォーラムで角藤さんが書かれていますが

現在，Windows だけ ptex, eptex の default input encoding が sjis になっていますが，TeX Live 2018 から，他のシステムに 合わせて，UTF-8 に変更する予定です。

ということのようです。

併せて，r47127 で，「Windows だけで文字コード自動判定がデフォルトで有効」という状態だったのを無効にしたようですね。そもそも TeX Live 版の ptexenc ソースコードには，当該の自動判定機能自体がマージされていないので，自然な流れだと思います。 → r47130 で元に戻されたそうです。

[aminophen]

上のコメントと

• https://www.texdev.net/2018/03/25/latex2e-utf-8-as-standard/
• http://d.hatena.ne.jp/zrbabbler/20180326/1522013178
• https://gist.github.com/zr-tex8r/6ff1e8528f8d11e6fa7d71b1570d46ee

も読みました。もともと LaTeX がサポートしていなかった使い方が封じられる，というだけなので，先方には「pLaTeX 系でも問題なし」と回答しておこうと思います。

[aminophen]

latex3/latex2e@4090b0b 以降のコミットをよく見ると，

• ltfinal.dtx の「LuaTeX / XeTeX でなく，encTeX 拡張も MLTeX 拡張も無効な場合」は LaTeX レベルの互換性用コードが latexrelease パッケージに吐き出される
• パッケージは (u)pLaTeX フォーマット定義後に読まれるので，結果的に「(p)latexrelease パッケージを読み込むと (u)pLaTeX の \DeclareFontEncoding が吹っ飛ぶ」

ということに気づきました。

\ifnum0%
  \ifx\Umathchar\@undefined\else 1\fi
  \ifx\mubyte\@undefined\else 1\fi
  \ifx\charsubdef\@undefined\else 1\fi
  =\z@
\IncludeInRelease{2018/04/01}%
                 {\UTFviii@invalid}{UTF-8 default}%
…
\fi

吹っ飛ばないように platexrelease パッケージ側で対処します。

[aminophen]

吹っ飛ばないように platexrelease パッケージ側で対処します。

この件は複雑なので #68 へ移行します。

[aminophen]

新しい LaTeX では，以下のようなソースが通らなくなるようですね。（このソースは uptex-base リポジトリの samples/greek-uplatex.tex をベースに作成）

「使うべきでない」という意見が各所で見られる utf8x.def を含め，いろいろなパッケージを使用している点が気になりますが，これも「サポート外になる」という認識で良いのでしょうか？

\documentclass[a4paper]{article}
\usepackage{ucs}
\usepackage[utf8x]{inputenc}
\usepackage[10pt]{type1ec}
\usepackage[T1]{fontenc}
\usepackage[polutonikogreek]{babel}
\begin{document}

\selectlanguage{polutonikogreek}

\begin{verse}
Ἄνδρα μοι ἔννεπε, Μοῦσα, πολύτροπον, ὃς μάλα πολλὰ\\
πλάγχθη, ἐπεὶ Τροίης ἱερόν πτολίεθρον ἔπερσε.\\
πολλῶν δ’ ἀνθρώπων ἴδεν ἄστεα καὶ νόον ἔγνω,\\
πολλὰ δ’ ὅ γ’ ἐν πόντῳ πάθεν ἄλγεα ὃν κατὰ θῡμόν,\\
ἀρνύμενος ἥν τε ψῡχὴν καὶ νόστον ἑταίρων.\\
ἀλλ’ οὐδ’ ὧς ἑτάρους ἐρρύσατο, ἱέμενός περ·\\
αὐτῶν γὰρ σφετέρῃσιν ἀτασθαλίῃσιν ὄλοντο,\\
νήπιοι, οἳ κατὰ βοῦς Ὑπερίονος Ἠελίοιο\\
ἤσθιον· αὐτὰρ ὁ τοῖσιν ἀφείλετο νόστιμον ἦμαρ.\\
τῶν ἁμόθεν γε, θεά, θύγατερ Διός, εἰπὲ καὶ ἡμῖν.
\end{verse}

\end{document}

lgrenc.dfu:89: LaTeX Error: Missing \begin{document}.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

l.89 ...UnicodeCharacter{00A8}{\textasciidieresis}
                                                     % ¨

→ 追記：以下のように短くなりますね。つまり「utf8x.def はサポート外になる」ということ？

%\RequirePackage{latexbug}
\documentclass{article}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
\DeclareUnicodeCharacter{00A8}{\textasciidieresis}
\begin{document}
a
\end{document}

[zr-tex8r]

utf8x.def（というかucsパッケージ）とutf8.defがともに\DeclareUnicodeCharacterという命令を提供していて、両者に互換性がありません。（ucsの方は符号値を十進数で指定。）だから元々「ucsとutf8.defは共存できない」わけですが、デフォルトでその影響が出てしまうわけですね。

ただし

  \DeclareUnicodeCharacter{00A8}{\textasciidieresis}

これは「utf8.defの方の\DeclareUnicodeCharacterをユーザが書いている」ので、元々正しくないソースです。次のようなのが最小例になります。

\documentclass{article}
\usepackage[utf8x]{inputenc}
\usepackage[LY1]{fontenc}
\begin{document}
La lingvo {\TeX} estas danĝera, ne alproksimiĝu!
\end{document}

utf8xのinputencによりucsが読み込まれたにも関わらず、\DeclareFontEncodingが残存しているため、ly1enc.dfuが読み込まれ、その中にある「utf8用の\DeclareUnicodeCharacter」がエラーを起こします。

[zr-tex8r]

「ucsと明示的なutf8.defの併用は不正」という前提で考えると、とりあえず、「ucsが読込済なら追加処理をスキップする」という処置で回避できます。

--- utf8-old.def    2018-04-05 20:18:18.888888888 +0900
+++ utf8-new.def    2018-04-05 20:20:18.888888888 +0900
@@ -283,6 +283,7 @@
                     {\default@family}{\default@series}%
                     {\default@shape}}%
     \expandafter\let\csname#1-cmd\endcsname\@changed@cmd
+\@ifpackageloaded{ucs}{}{%
     \begingroup
       \wlog{Now handling font encoding #1 ...}%
       \lowercase{%
@@ -291,6 +292,7 @@
                       encoding #1}}%
            {\wlog{... no UTF-8 mapping file for font encoding #1}}%
     \endgroup
+}%
   \else
      \@font@info{Redeclaring font encoding #1}%
   \fi

[aminophen]

utf8x.def（というかucsパッケージ）とutf8.defがともに\DeclareUnicodeCharacterという命令を提供していて、両者に互換性がありません。

本件，LaTeX team も見落としていたようで，Frank が latex3/latex2e@e078593 及び latex3/latex2e@7e5a425 で対処しています。ucs の著者にもコンタクトしてくださると思います。

pLaTeX も同様の対処を加えてみました。多分 ef12e1c1 時点で上手く動くようになるはずです。

[aminophen]

latex3/latex2e#32 で，コマンドラインで pdflatex tèst.tex と起動した場合もエラーになることが報告されています（TeX のコマンド引数は全て TeX 言語の一部として解釈されることに注意）。この対処のために「UTF-8 化の処理の一部を \everyjob まで遅らせる」という試行錯誤がされていますが，いずれにせよ \everyjob は pLaTeX のバナー表示のためにいろいろ弄っている部分でもあるので，注視します。

少なくとも，platex.ltx / uplatex.ltx にある \the\everyjob の行は削除した方が，将来のために安全だと思い始めています。（現状，fmtutil 実行時にコンソールにバナーを表示する以上の意味を持たないはず。）

[aminophen]

メモ： latex3/latex2e@735ce69 で入る \everyjob を pLaTeX でも与えないと，UTF-8 化が崩壊する。

→ 8b6c518 で LaTeX2e 2018-04-01 Patch level 2 の上でも pLaTeX が正常動作するようになりました。本家コミット latex3/latex2e@724013b まで確認済みです。

[aminophen]

「docstrip でストリップするコードの中に 128--255 の文字があると不可解なエラーが出る」という問題が起きていましたが， https://github.com/latex3/latex2e/commit/fc534242c1d1f20769e1978e0cad7365da15de2b で docstrip が改修されて ok になりました。