バイト列と和文文字トークンの区別

[h-kitagawa]

#80 について調べていた中で考えた話題ですが，話が拡散しそうなので別 issue を立てます．私が調べた限りだと，次の①〜③のような挙動になっています：

①\def\A{^^c5^^bf ſ 顛}\A とすると，dvi中 では Å£ Å£ 顛 のようにしっかり「2つの欧文文字トークン^^c5^^bf」「和文文字トークン 顛」が区別されています．

②しかし， \edef\B{\meaning\A} とすると，まず \meaning により

 (m)(a)(c)(r)(o)(:)(-)(>)("C5)["BF]( )("C5)["BF]("C5)["BF]

と文字列化（selector=new_string の状態で print_... が呼ばれる）され，それが str_toks() により

(m)(a)(c)(r)(o)(:)(-)(>)(顛)( )(顛)( )(顛)

とトークン化されます．従って \B の実行結果は macro:->顛 顛 顛 となります．

③\message{\A} を考えると，同様に展開結果のトークン列が

("C5)["BF]( )("C5)["BF]("C5)["BF]

と文字列化され，それが slow_print によりバイト列として端末・ログに出力されます．この過程で ptexenc によるコード変換が起こり，

顛 顛 顛

という端末・ログへの出力結果になります．

---

さて，platex/#84 を考えると，\message{\A} の結果は ſ ſ 顛 となるのが望ましいと私は思っています．
ただ，③を見ると文字列化の過程で "C5"BF というバイト列に「欧文文字トークン由来」「和文文字トークン由来」というマーキングが必要と思っており，どうしようか……と悩んでいる状況です．

[h-kitagawa]

書き忘れました．kitagawa_printkanji ブランチでは str_toks() などにわざと余計な print() を入れ，どのように文字列化されるかがわかるようにしています（かなり見にくいですが……）．`

[t-tk]

質問です。
("C5)["BF] のように ()と[] の書き方を区別しているのは何の違いですか?

分かっていないのですが、欧文TeX で \meaning とした場合、catcode はどうなるのですか?
多分欧文TeX ではそれが catcode の無い素の8bitのバイト列なのかと思います。
そうすると、あくまで例えばですが「和文文字トークン由来」を「素のバイト列」で表現するときに("100C5)["100BF]みたいにするとか?
そうすると、改造量が多くなって、「本当に pTeX でそこをピカピカに磨く必要があるの??」という疑問も出てきます。

[aminophen]

("C5)["BF] のように ()と[] の書き方を区別しているのは何の違いですか?

こちらは @h-kitagawa さんにお任せします。

「本当に pTeX でそこをピカピカに磨く必要があるの??」

本件は結局 upTeX にも波及していて，

%#!uptex
\font\x=ec-lmr10\x
\jfont\y=upjisr-h\y

[^^e3^^81^^82]\par
\message{^^e3^^81^^82}
\def\A{^^e3^^81^^82}\meaning\A

\bye

の結果が一行目は "[ãĄĆ]" なのに，二行目の \message は "あ" で三行目は "macro:->あ" になってしまっています。私もこれは整合性がないと思っています。

[t-tk]

本件は結局 upTeX にも波及していて，

なるほど、そうですか。
そうすると、 @h-kitagawa さんコメントの ①〜③ のうち ③ で何かするのは無理で、pTeX, upTeX共通で ②に達する前に「欧文文字トークン由来」「和文文字トークン由来」の区別を導入する必要があるということですね。

[h-kitagawa]

("C5)["BF] のように ()と[] の書き方を区別しているのは何の違いですか?

[] は和文文字トークンが str_toks によって文字列化されたときの 2 文字目を表したつもりです．(C5)(BF), (C5)[BF] は str_pool[] 内のバイト列としては同じですが，こちらで作業しているときにデバッグ用の出力から「2 つの欧文文字トークン ^^c5^^bf`` の文字列化」「和文文字トークン顛`文字列化」を判断できるようにするためです．

[t-tk]

コメント有難うございます。ということはやはり↓で②に達する時点で「欧文文字トークン」「和文文字トークン」が区別出来なくなっている、ということですね。

②しかし， \edef\B{\meaning\A} とすると，まず \meaning により

 (m)(a)(c)(r)(o)(:)(-)(>)("C5)["BF]( )("C5)["BF]("C5)["BF]

と文字列化（selector=new_string の状態で print_... が呼ばれる）され

(u)pTeX で素の8bitバイト列で「欧文文字トークン」「和文文字トークン」の混乱が起こる場所って、今回の事例以外にはありますか?

[t-tk]

あくまで案ですが、

1. 「和文文字トークン由来」を「素のバイト列」で表現するときに("100C5)["100BF]みたいにする
2. 「和文文字トークン由来」を「素のバイト列」で表現するときに("FFFF)("C5)["BF]みたいにする。"FFFF は後続(EUCなら2バイト, UTF-8なら可変バイト)が「和文文字トークン」を示すマーカー。

「欧文文字トークン」「和文文字トークン」の混乱が起こる場所が限定的なのならば 2 の方が楽かもしれません。

[h-kitagawa]

こちらこそありがとうございます．

(u)pTeX で素の8bitバイト列で「欧文文字トークン」「和文文字トークン」の混乱が起こる場所って、今回の事例以外にはありますか?

今思いつく限りでは今回の件だけです（全部調べたわけではありませんが）．

「和文文字トークン由来」を「素のバイト列」で表現するときに("FFFF)("C5)["BF]みたいにする。"FFFF は後続(EUCなら2バイト, UTF-8なら可変バイト)が「和文文字トークン」を示すマーカー。

今，次の方針を試しています（まだうまく動きませんが）：

3. 「欧文文字トークン由来」の 0x80 以降のバイトには ("FF)("C5)("FF)("BF) のように ("FF) を前置する

[t-tk]

確かに 0xFF は Shift-JIS にも EUC にも UTF-8 にも現れないので、その案3が一番明快ですね。賛成です。
欧文文字トークン由来の("FF)は("FF)("FF)で表せますね。

[h-kitagawa]

ファイル名の扱いについてよく分かっていない（個人的には ASCII の範囲しか使わないのもあって）ので素朴な疑問です．unix-like OS で ptex -jobname=あſ hoge.tex としたとき，

1. \jobname で展開されるトークンは，バイト列の ^^e3^^81^^82^^c5^^bf ，「あ」を EUC 化した ^^a1^^a2^^c5^^bf ，あるいは あ^^c5^^bf なのか，どれが「望ましい」でしょうか？
2. \message{\jobname} の出力は あſ が期待される？
3. 生成される dvi は（あ^^c5^^bf.dvi でなく） あſ .dvi が期待される？

[h-kitagawa]

#80 のエラーについてですが，utf8.def 中に

\PackageError{inputenc}{Unicode character \expandafter
                        \UTFviii@splitcsname\string#1\relax

というコードを見つけました．
例えば pTeX だと

 \顛  \csname ^^c5^^bf\endcsname  \csname 顛\endcsname

を \stringするとみな \顛 になるので，これが直接的な原因だと思います．

この件は upTeX でも \csname ^^e3^^81^^82\endcsname と \あ を同一視するか，という点で関わってきますが，さてどうしましょうか．

[t-tk]

ファイル名の取り扱いについて、pTeX + unix-like OS では pTeX/upTeX の日本語ファイル名(#45) の頃に触った記憶があります。方針としては、「pTeX エンジン内部ではプラットフォームにかかわらず pTeX の内部コード(unix-like OSならばEUC)で扱う。ロケールがUTF-8の場合に限り、コマンドライン読み込みの際にUTF-8→EUC変換を行い、ファイルオープンの際 web2c/lib/openclose.c の open_input() の中でptexencの関数を呼び出し EUC→UTF8 変換を行う。」だったと思います。関連するコミットは、r47967 だと記憶しています。
その他のケースは基本的に何もしていません。
pTeX + unix-like OS + ロケールがUTF-8以外の場合、何もしていない結果、内部コード(通常EUC)とロケール(ja_JP.eucJP等)が一致している場合のみ動くはずです。
upTeX + unix-like OS の場合、何もしていない結果、内部コードUTF-8でロケールがUTF-8という現在一般的な環境では動いているはずです。

pTeXかつunix-like OS かつロケールがUTF-8の場合、 ptex -jobname=あſ hoge.tex としたときは、
コマンドライン読み込みで、内部コードでは「あ」のEUCコード ("a4)("a2) と ^^c5^^bf になると思います。再度実際にオープンするファイル名については EUC→UTF-8 に戻すのが r47967 の方針でしたが、 ^^c5^^bf を"ſ" に戻すかどうかは考えていませんでした。
pTeX かつ Windows の場合、 ptex -jobname=あſ hoge.tex と入力すると、現状ではコマンドライン読み込みで何もしていない(日本語WindowsではコマンドラインをUTF-8ではなくCP932の文字列と仮定して処理する)ので"ſ" を "^^c5^^bf " に変換する機能が働かないと思います。なので、 ptex -jobname=あſ hoge.tex の例で "ſ" は想定外であり、「pTeXでは基本的にJIS X 0208の第1,2水準以外はサポートしない」を貫けばよいと思います。

[t-tk]

もう一つ漠然と思うことです。
「pTeX でJIS X 0208の第1,2水準以外のUTF-8の文字を ^^ab 形式にして pTeX 内に流し込む」という機能は pTeX の入出力で UTF-8 をサポートする際に入力の利便性のために入れたオマケ的な機能だと思っています(強力な機能でもありますが)。pTeX のファイル名問題は、どんなに頑張っても簡明な策は無くどうしても弥縫策になってしまうので、どこかで線を引くべきと思います。

[t-tk]

追伸。
pTeXかつunix-like OS かつロケールがUTF-8以外のレガシーエンコーディング(例えばja_JP.eucJP等)の場合、ptex -jobname=あſ hoge.tex と入力すること自体が困難です。
やはり、 ptex -jobname=あſ hoge.tex の例で "ſ" は想定外であり、「pTeXでは基本的にJIS X 0208の第1,2水準以外はサポートしない」が私の結論です。

[h-kitagawa]

ファイル名の取り扱いについて
「pTeXでは基本的にJIS X 0208の第1,2水準以外はサポートしない」

コメントありがとうございます．あ^^c5^^bf.dvi という出力ファイル名を見たときはびっくりしましたが，この原則に則って，何もいじらないことにします．

[t-tk]

upTeX でも \csname ^^e3^^81^^82\endcsname と \あ を同一視するか

正直考えていませんでした。
欧文TeXとの互換性を重視した場合、\csname ^^e3^^81^^82\endcsname が \あ と同一視されてしまうと困る場合がある、ということですね。
欧文 TeX では \ に8bit 3byte の "E3 "81 "82 が後続した文字列になるべきで、それが \あ では無い。
現状のupTeXは \あ と同一視している。

仕様案1は、UTF-8の入力文字列をCJKトークンと欧文トークンに振り分ける場合にならって「\csname ^^e3^^81^^82\endcsname, \csname あ\endcsname ともに、UTF-8 で 0xE3 0x81 0x82 (U+3042) の kcatcode が15ならば 欧文 TeX と同じ、kcatcode が15以外ならば \あ と同一視する。」
あるいは、仕様案2「\csname ^^e3^^81^^82\endcsname は、常に欧文 TeX と同じ。UTF-8で書かれた\csname あ\endcsname は \あ と同一。 」
どちらが自然、あるいは便利でしょうか。あるいは、別の案？

[hideak-t]

欧文でどうなっているか気になったので、試してみました。

{^^00^^fc}
\message{^^00^^fc}
\def\U{^^00^^fc}
\message{\U}
\meaning\U
\expandafter\edef\csname ^^00^^fc\endcsname{testA}
\csname ^^00^^fc\endcsname
\expandafter\edef\csname ü\endcsname{testB}
\csname ^^00^^fc\endcsname
\csname ü\endcsname
%\ü <- error

このコード、etex, ptex, uptex では ¥message では ü (u umlaut) が出力されますが、 tex では ¥message で ^^fc が出力される。etex 拡張で ¥message では ü (u umlaut) が出力されるようになったということでしょうか。でも、etex 拡張後でも csname で使われる場合は同一視されていないんですね。面白いです。

[hideak-t]

おっと、失礼いたしました。uptex では ¥message で出力されるのは ^^fc の方ですね。

[hideak-t]

不勉強なので、もう少し試してみました。etex, ptex で \message{^^fc} で u umlaut が出るのは、etex 拡張で非ASCII も ¥message でそのまま出力するようになった結果ということでしょうか。と考えると、etex, ptex で \message{^^e3^^81^^82} で「あ」が出力されるのは仕様の範囲？

[hideak-t]

以下は、いずれの処理系でも

\expandafter\edef\csname ü\endcsname{testA}
\expandafter\edef\csname ^^00^^fc\endcsname{testB}
\expandafter\edef\csname ^^fc\endcsname{testC}
\csname ü\endcsname
\csname ^^00^^fc\endcsname
\csname ^^fc\endcsname

testA testC testC と typeset されるので、いずれの処理系でも ^^00 は単純に無視されているんですね。

[h-kitagawa]

etex 拡張で ¥message では ü (u umlaut) が出力されるようになった

私も完全に理解しているわけではありませんが，TCX ファイルというもののおかげのようです（Web2C のドキュメント (texdoc web2c) や マクロツイーターの記事 参照）．

TeX Live では，fmtutil.cnf に

etex pdftex language.def -translate-file=cp227.tcx *etex.ini
latex pdftex language.dat -translate-file=cp227.tcx *latex.ini

とあるように，cp227.tcx という TCX ファイルが標準で使われます．この cp227.tcx をみると

This file makes all characters with code >= 128 printable for TeX.
TeX itself makes all codes in the range of 32 to 127 printable.

とあり，確かに etex '\message{^^e3^^81^^82}\bye' からは「^^e3^^81^^82」でなく「あ」が出力されます．

一方，pdftex -ini -etex -jobname=etex-notcx etex.ini と TCX ファイルを使わないようにフォーマットを作り直した場合は，pdftex -fmt=etex-notcx '\message{^^e3^^81^^82}\bye' から「^^e3^^81^^82」が出力されました．

[h-kitagawa]

仕様案1は、UTF-8の入力文字列をCJKトークンと欧文トークンに振り分ける場合にならって「\csname ^^e3^^81^^82\endcsname, \csname あ\endcsname ともに、UTF-8 で 0xE3 0x81 0x82 (U+3042) の kcatcode が15ならば 欧文 TeX と同じ、kcatcode が15以外ならば \あ と同一視する。」
あるいは、仕様案2「\csname ^^e3^^81^^82\endcsname は、常に欧文 TeX と同じ。UTF-8で書かれた\csname あ\endcsname は \あ と同一。 」
どちらが自然、あるいは便利でしょうか。あるいは、別の案？

仕様案 2 だと，\string するときにどうするか，という論点もあります．整理するとこんな感じでしょうか？

• 内部的に \csname ^^e3^^81^^82\endcsname と \csname あ\endcsname を同一の制御綴とするか？
  • 仕様案 2：現行 (u)pTeX と同じ．どちらも制御綴名は ^^e3^^81^^82 という 3 バイトとして string pool に格納されるため，区別不可能．
  • 仕様案 1：内部的に区別する．例えば kitagawa_printkanji ブランチで他の箇所で行った変更と同じようにするならば，次のようになる：

\csname ^^e3^^81^^82\endcsname % →内部的には ^^ff^^e3^^ff^^81^^ff^^82 という 6 バイトを格納．
\csname あ\endcsname % → \kcatcode"3042=15 ならば上と同じ．
                     % \kcatcode"3042>15 ならば内部的には ^^e3^^81^^82 という 3 バイトを格納．

• 上記で仕様案 2 をとった場合，\string した結果はどうするか？
  • [2-1]：現行と同じように，できる限り和文文字扱いとする．
  • [2-2]：出力時は単なるバイト列，トークン化する際は欧文文字トークンの列とする．
  • [2-3]：どちらにするかを切り替えるフラグ（内部整数？）を用意する．

仕様案 1 はまだ試していません．もし仕様案 2 をとるのならば，欧文 TeX との互換性と \西暦 などの和文の制御綴も使われていることから [2-3] になるのかなあ，という気がしています．

[h-kitagawa]

仕様案 1 をさらに別の kitagawa_printkanji_1 ブランチで入れてみました．このブランチの upTeX では \^^e1^^81^^82 と \あ が内部で別の制御綴に扱われますが，UTF-8 環境下ではそれが端末や log からわからなくなり，よくないように思えてきました．

%#! euptex
\catcode"E3=11 \catcode"81=11 \catcode"82=11 %"
\def\^^e3^^81^^82{hoge}\def\あ{piyo}
\message{\^^e3^^81^^82 \あ}               % ==> hogepiyo
\message{\string\^^e3^^81^^82 \string\あ} % ==> \あ\あ
\bye

[t-tk]

考えがまとまっていませんが
取り敢えずおしまいの問題についてだけ、欧文 TeX で考えてみます。以下の例で

%#! etex
\catcode"C2=11 \catcode"AA=11 %"
\def\^^c2^^aa{hoge}
\message{\^^c2^^aa}        % ==> hoge
\message{\string\^^c2^^aa} % ==> \ª
\bye

^^c2^^aa の 8ビット2バイトの列のエンコーディングは UTF-8 であると保証されているはずはなく T1等かもしれないのに端末出力に UTF-8 前提で U+00AA (ª, UTF-8で0xc2 0xaa) が表示されるのは「正しい」動作なのでしょうか?
おそらくそこは TCX ファイルの動作であって、(e)TeX 自体の責任では無いと理解しています。

(e)upTeX で\^^e1^^81^^82 と \あ を区別した仕様でかつ TCX を介さない場合に

\message{\string\^^e3^^81^^82 \string\あ} % ==> \^^e3^^81^^82\あ

とすることがもし出来るのならば UTF-8 環境下でも(TCX無しとすることで)区別できそうに思います。

[t-tk]

疑問です。
Omega/Aleph, XeTeX, LuaTeX では \csname ^^c2^^aa\endcsname と \csname ^^^^00aa\endcsname は区別される?
\string\^^c2^^aa と \string\^^^^00aa は区別される?

[h-kitagawa]

\message{\string^^e3^^81^^82 \string\あ} % ==> ^^e3^^81^^82\あ

なるほど，こういう方法は思いつきませんでした，しばらく考えてみます．

Omega/Aleph, XeTeX, LuaTeX では \csname ^^c2^^aa\endcsname と \csname ^^^^00aa\endcsname は区別される?
\string^^c2^^aa と \string^^^^00aa は区別される?

区別されるようです．

\catcode"C2=11
\catcode"AA=11
\expandafter\def\csname ^^^^00aa\endcsname{piyo}
\expandafter\def\csname ^^c2^^aa\endcsname{hoge}
\message{%
  \string\^^^^00aa, \string\^^c2^^aa,
  \csname ^^^^00aa\endcsname, \csname ^^c2^^aa\endcsname}
\bye
% pdftex: \^^^^00aa, \ª, piyo, hoge （番外）
% aleph: \^^aa, \^^c2^^aa, piyo, hoge
% xetex: \ª, \ª, piyo, hoge
% luatex: \ª, \ª, piyo, hoge

[t-tk]

言い換えると

• pdfTeX では \ª は \^^c2^^aa と同じで \^^aa, \^^^^00aa とは異なる
• Aleph, XeTeX, LuaTeX では \ª は \^^aa, \^^^^00aa と同じで \^^c2^^aa とは異なる

(e)upTeX では、「欧文の部分は8bit欧文TeXと同じ」という建前なのでpdfTeXに近い仕様がよいことになりますが、仕様が破綻しそうですね…

[h-kitagawa]

runsystem() の引数を見ると，「日本語」の部分が EUC のままで渡されているので，変換することになるのでしょう．

とりあえず bec98d8 で変換させてみました．

[aminophen]

とりあえず bec98d8 で変換させてみました．

ここまでの内容に ChangeLog を付けて r61692 で TeX Live svn にコミットしました。しばらく様子見です。

[aminophen]

r61692

• pTeX のバージョンを p3.10.90 ではなく p4.0.0 に上げています。（大改修だという意味）
• @h20y6m さんの非 ASCII の欧文バイトを ? あるいは ^^ 形式に変換するコードはまだです。

[aminophen]

@h20y6m 遅くなりましたが，動かしてみました。意図通りに動いていると思います。どちらかといえば，個人的には ^^ 形式に変換が好みです。（ちなみに，私の macOS の pdftex では #89 の冒頭のソースが ^^80 → %80 になり，これだと "E3 3回 → %E3%E3%E3 になるのですが，環境依存でしょうか？ →もし共通なら "%" 付のほうが統一感があります）

[h20y6m]

個人的には ^^ 形式に変換が好みです。

私も ^^ 形式のほうがログメッセージ等と統一感があっていいかなと思っています。

（メモ：^ はコマンドプロンプトのエスケープ文字なので win32 で問題が起きないか確認しておく。）

ちなみに，私の macOS の pdftex では #89 の冒頭のソースが ^^80 → %80 になり，これだと "E3 3回 → %E3%E3%E3 になるのですが，環境依存でしょうか？

win32 ではいずれも � U+FFFD になりました。（win32 ではファイル名の文字コード変換をしていてその際に変換できなかった文字が U+FFFD になるのだとおもう。）

linux ではそのまま 0x80 や 0xE3 のバイトになるようです。（ls コマンドだと 'xout.tex'$'\200' とか ''$'\343\343\343''.tex' のような表示になる。）

macOS 独自の機能でしょうか？

[h-kitagawa]

個人的には ^^ 形式に変換が好みです。

わたしもこちらに賛成です（すみませんが，まだ動かせてないので，後で試します）．

[h20y6m]

print_kanij16bit (r61692) について

\write18 の処理で append_to_name を使っていますが、append_to_name は " を取り除いてしまうのでまずそうな気がします。（引数にスペース等を含むファイル名を指定したいときとか）

---

^^ 形式に変換のほう

h20y6m@0af852a の is_terminalUTF8 の実装ちょっとまずいですね。terminal_enc を 直接参照せず get_terminal_enc() を呼んだほうがいいよさそうです。（terminal_enc は get_terminal_enc() の最初の呼び出しでセットされるので。）

win32 では変換しないほうが良い気がしています。（h20y6m@0af852a では上記の terminal_enc がセットされていないので変換されませんが…）
現状ではファイル名に CP932 の半角カタカナやいわゆる機種依存文字が含まれていても動いていたものが変換すると動かなくなってしまうので。

[h-kitagawa]

\write18 の処理で append_to_name を使っていますが、append_to_name は " を取り除いてしまうのでまずそうな気がします。（引数にスペース等を含むファイル名を指定したいときとか）

30dfb8e で直しました（が，\write18 については「実際に system() に渡される文字列では ^^ 表記だが，log に runsystem(...) と表示される内容では違う」のような不一致状況はまずいので，時間が出来たときにまた考えます）．

is_terminalUTF8 の実装ちょっとまずいですね。terminal_enc を 直接参照せず get_terminal_enc() を呼んだほうがいいよさそうです。（terminal_enc は get_terminal_enc() の最初の呼び出しでセットされるので。）

win32 では変換しないほうが良い気がしています。（h20y6m@0af852a では上記の terminal_enc がセットされていないので変換されませんが…） 現状ではファイル名に CP932 の半角カタカナやいわゆる機種依存文字が含まれていても動いていたものが変換すると動かなくなってしまうので。

こちらも同コミットで．Windows についてはわかりませんが，いつでも false を返せばいいというのは安直すぎでしょうかね？

[aminophen]

ptex のビルド中に出る警告を見ると

ptex0.c:6640:19: warning: comparison of constant 256 with expression of type 'ASCIIcode' (aka 'unsigned char') is always false [-Wtautological-constant-out-of-range-compare]
        if ( buffer2 [k ]>= 256 ) 
             ~~~~~~~~~~~~^  ~~~
ptex0.c:10204:58: warning: comparison of constant 256 with expression of type 'ASCIIcode' (aka 'unsigned char') is always false [-Wtautological-constant-out-of-range-compare]
      if ( ( xord [ucharcast ( TEXformatdefault [j ]) ]) >= 256 ) 
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~
ptex0.c:10217:27: warning: comparison of constant 256 with expression of type 'ASCIIcode' (aka 'unsigned char') is always false [-Wtautological-constant-out-of-range-compare]
      if ( ( buffer [j ]) >= 256 ) 
           ~~~~~~~~~~~~~~ ^  ~~~
ptex0.c:10231:58: warning: comparison of constant 256 with expression of type 'ASCIIcode' (aka 'unsigned char') is always false [-Wtautological-constant-out-of-range-compare]
      if ( ( xord [ucharcast ( TEXformatdefault [j ]) ]) >= 256 ) 
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~

どうやら以下の箇所

@d append_to_name(#)==begin if (#)>=@"100 then c:=(#)-@"100 else c:=#;
  { Since the type of |c| is |ASCII_code|, above if-statement might not be needed }

および firm_up_the_line への変更部（下記抜粋）のようです。

    if buffer2[k]>=@"100 then print_char(buffer[k]) else print(buffer[k]);

buffer2 は 0 または 1 しかないので他の箇所同様 if buffer2[k]>0 then が正しいような？

[h-kitagawa]

77a83ff で直しました．

[aminophen]

77a83ff で直しました．

確認ありがとうございます。とりあえずこの修正だけ r61759 でコミットしました。

[aminophen]

fb1d536#commitcomment-65200594 のコメントを受けて，コンパイラ警告を抑えるのは 586ef5f でやってみました。まだ残っている懸念点はありますでしょうか？

\write18 については「実際に system() に渡される文字列では ^^ 表記だが，log に runsystem(...) と表示される内容では違う」のような不一致状況はまずい

でしょうか。

[aminophen]

• \write18 の処理で " を取り除かない
• 非 Windows で日本語でも ASCII でもないバイト列を ^^ 形式に変換
• コンパイラ警告を抑える (586ef5f)

ここまでを r61906 でコミットしました。

[h20y6m]

https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=3334
platex で日本語ファイル名の画像を \includegraphics すると extractbb でエラーが発生する。

\openin でパイプ入力のときにファイル名が化けているようです。

texmfmp.c の open_in_or_pipe, open_out_or_pipe でも文字コード変換が必要そうです。

（どのみち dvipdfmx でエラーになってしまいますが…… special も文字コード変換する？？）

[aminophen]

よくわかっていませんが

• もし『printkanji_16bit 改修の結果として，パイプ入力で例えば "kpsewhich 日本語ファイル名.tex" のようなことが通らなくなってしまった』ということであれば，それは改善の余地ありかなと思います。
• DVI ファイル出力時の special の中身は (u)pTeX の内部コードでエンコードされるという仕様は一貫していましたので，その挙動を変えるのは反対です。どのみち dviware には「その DVI ファイルがどうエンコードされたか」を知る手段がなく，dviware で文字コード変換を行わせるのは不可能→正しく対処することはできないと思います。

[h20y6m]

• もし『printkanji_16bit 改修の結果として，パイプ入力で例えば "kpsewhich 日本語ファイル名.tex" のようなことが通らなくなってしまった』ということであれば，それは改善の余地ありかなと思います。

printkanji_16bit とは関係ないものです。
ただ今回 \write18 で文字コードを変換するようなったのにパイプ入力では変換しないのは一貫性がないのではないかと思います。

• DVI ファイル出力時の special の中身は (u)pTeX の内部コードでエンコードされるという仕様は一貫していましたので，その挙動を変えるのは反対です。どのみち dviware には「その DVI ファイルがどうエンコードされたか」を知る手段がなく，dviware で文字コード変換を行わせるのは不可能→正しく対処することはできないと思います。

わかりました。

[aminophen]

printkanji_16bit とは関係ないものです。

了解です。

ただ今回 \write18 で文字コードを変換するようなったのにパイプ入力では変換しないのは一貫性がないのではないかと思います。

確かにそれは一貫性がないように思いました。

\openin0=日本語.tex
\read0 to\foo [read: \foo] % これは読める
\closein0
\input "|kpsewhich 日本語.tex"\relax % ここの問題！
\immediate\write18{kpsewhich 日本語.tex} % これは見つかる
\end

[h-kitagawa]

ただ今回 \write18 で文字コードを変換するようなったのにパイプ入力では変換しないのは一貫性がないのではないかと思います。

901a073 で直しました．

[aminophen]

901a073 で直しました．

ありがとうございます。r62365 でコミットしました。