[ppltotf, ptftopl] 9 区から 15 区，および 85 区以上の和文文字

[h-kitagawa]

ppltotf と ptftopl には以下の valid_jis_code という関数があり，これによって（JIS X 0213 で追加された）9 区から 15 区，および 85 区以上の文字が指定できないようになっています．

function valid_jis_code(cx:integer):boolean;
var @!first_byte,@!second_byte:integer; { jis code bytes }
begin valid_jis_code:=true;
first_byte:=cx div @'400; second_byte:=cx mod @'400;
if (first_byte<@"21)
   or((first_byte>@"28)and(first_byte<@"30))
   or(first_byte>@"74) then valid_jis_code:=false;
if (second_byte<@"21)or(second_byte>@"7E) then valid_jis_code:=false;
end;

もちろん，次のようにコード番号で指定してもだめです．

(CHARSINTYPE O 1
   J 2922 J 2A22 J 2F22 J 3022
   )

これは 9 区から 15 区，および 85 区以上の文字を文字タイプ 0 以外にはできないことを意味しています．pTeX は JIS X 0213 には正式対応はしていませんが，pTeX でも CMap 2004-H (2004-V) を利用して一応は出力できることを考えると，valid_jis_code をなくすのもありではないか，と思うようになってきました．

[aminophen]

実は最近 (u)ppltotf/(u)ptftopl のマニュアル (ppltotf.man, ptftopl.man) を書くための調査中に，同じようなことを思いました。その時はあまり気にしていませんでした。というのも，以下の理由からです。

• uppltotf は，既定は -kanji=uptex で Unicode の符合位置を扱うが，オプション -kanji={euc,sjis,jis,utf8} を付けると JIS の符合位置を扱う。つまり，pTeX 用の JFM も uppltotf で作れる。
• uppltotf では valid_jis_code が（内部コードによらず）緩んでいる。つまり，uppltotf を使えば pTeX 用の JFM 生成に JIS X 0213 の「9 区から 15 区，および 85 区以上の文字」も含められる。

例えば，齋藤さんのサイトに置かれている「JIS X 0213 パッケージ」(jisx0213.zip) の JFM 群は pTeX 用ですが，JIS X 0208 にはない文字が入っているので，なんとなく「uppltotf で作ったのかな」と思っていました。 ptftopl ではデコードできませんが，uptftopl -kanji=sjis では ｟ 〘 〖 〝 のような括弧類もデコードできるので。

でも，言われてみて再考すると「pTeX で和文扱いされる範囲」と「JFM で TYPE 0 以外に分類できる文字」は整合性が取れている方がいい気もしますね。

[t-tk]

私見ですが、
pTeX環境で区の制限を設けた理由の一つとして「JIS X 0208, 第一、第二水準しかサポートしません」というのを強く打ち出していた時代背景があるような気がします。
その頃は機種依存文字の問題が深刻で、「知らぬ間に機種依存文字を使っているユーザーがトラブルを自己解決出来ない」「機種依存文字のサポートをやりたくないのに期待されてしまう」「機種依存文字の普及に繋がる実装はコミュニティ全体にとってマイナス」という考え方があったと思います。
今は、「Shift_JISの機種依存文字を使いたければ "UTF-8 + uplatex" にしましょう」と誘導出来るので上記のような”負の効果”は考えなくても良いと思います。

JIS X 0213パッケージ(2004年〜)は、upTeXのプロジェクトの開始(2007年〜)より前です。むしろ私がupTeXを始めるきっかけになった先輩のプロジェクトに当たります。
ptftopl のどの版かは分かりませんが uppltotf の登場より前に生成可能だったはずです。

私見ですが、
uptftopl -kanji=sjis は ptftopl -kanji=sjis と互換、uppltotf -kanji=sjis は ppltotf -kanji=sjis と互換の動作をするだし実装も分かりやすいはずなので、提供するバイナリーを uptftopl, uppltotf に統一してしまっても良いと思います。

[t-tk]

私見ですが
CMap 2004-H (2004-V) のような試みは2004年頃には意味があったと思いますが、
2019年の今となっては UTF-8 の普及が充分に行き渡っている以上
「サポートを進めるべき項目」では無いと思います。
「制限は緩めておくので事情をよく知った人がこっそり使う機能として提供」程度の位置づけならまあ良いか、が私の感覚です。

[h-kitagawa]

みなさん，コメントありがとうございます．

uppltotf では valid_jis_code が（内部コードによらず）緩んでいる。

それは知りませんでした．そうすると，ptex-manual にしっかり明記しておけば，ppltotf/ptftopl は valid_jis_code がある現行のままで良いかな，と思います．

提供するバイナリーを uptftopl, uppltotf に統一

良いと思いますが，その場合，シンボリックリンクとして ppltotf, ptftopl は残しますか？
残すとしたら，互換性のために「u なしプログラム名で呼ばれた場合は（既定では）uptex モードにしない」処理がほしいです．

[t-tk]

「u なしプログラム名で呼ばれた場合は（既定では）uptex モードにしない」処理

dvipdfm-x のコードを参考に試しに書いてみました。(d68a24a)
コマンド名が"p" または "ep" で始まる場合には内部コードをEUC(Windows以外またはpbibtex)またはSJIS(pbibtex以外かつWindows)に設定されます。
pTeX族のプログラムと互換性があるはず/あるつもりですが、どこまで検証するかが課題になりそうです。
当面実験用機能ということにしようかと思います。

[t-tk]

prefix判定をここの master にマージしTeX Live svn にコミットしました。(r51021)
検証はぼちぼちやろうと思います。

[t-tk]

pbibtex, pdvitype, ppltotf, ptftopl のバイナリーを upbibtex, updvitype, uppltotf, uptftopl のバイナリーのpTeXコンパチモードに置き換える構想のためのテストを開始しました。
素の pTeX/upTeX バイナリ、バイナリ共通化検討 #32 で続きを議論したいと思います。

valid_jis_code は、上記の議論にあったように、コンパチモードの方は緩んでいます。
JIS X 0208の範囲外の区 (9区～15区と85区以上) に対しても動くようになる点がオリジナルの ppltotf/ptftopl との違いになります。
こちらは閉じようと思います。