名前: ZR 日時: 2007-07-15 00:00:50 IPアドレス: 59.140.98.*
>>48709 (>>48715 の続き) >> kcatcode の既定値で、もう 1 つ頭の痛い問題 >これは、頭が痛いです。 >\usepackage[T1]{fontenc}の場合に、\ss など7bit記法が化けてしまうというのは >直感的でなく、好ましくないように思えます。 >0x80〜0xFF の文字の \char のdefaultを和文にしてしまった副作用でした。 >(現状のuptex) 0x80〜0xFFのkcatcodeをdefaultから変更しないと、 >(対策案1) マクロの側でがんばってもらう。 >(対策案2) 0xFF以下の \char が和文になるのを一律禁止する。 >あえて\char を使いたいなら、 >Unicodeのコードポイントに 0x110000 を足した値等を利用してもらう。 >(対策案3) 0xFF以下の \char で和文／欧文の切り替えを >現在のuptexのkcatcode指定ではなく、別のスイッチを追加する。 >(対策案4) 0xFF以下の文字コードを和文化するプリミティヴ >(例えば\kchar, \kchardef)を新設する。 >(対策案5) 和文トークンの内部コードを全部移動してしまう。 (>>48356) の投稿の後に私自身が考えた結果の「最善策」は (4) だったと記憶 しています。(1) も考えましたが、恐らく \DeclareTextSymbol 以外にも問題 になるケースが出現して後で面倒なことになると考え捨てました。 (4) を適当とする理由は: - pTeX/upTeX では文字トークンは「和文」と「欧文」の 2 種類あるという 仕様なので、文字に変換するプリミティブが 2 つあっても不自然なこと ではない。偶々、pTeX では両者の符号値が重なっていなかったので 1 つ の \char で両者を兼ねることができたとも考えられる。 - そもそも、現状の仕様は 0xFF 以下の値だけ特別扱いしていて、少し 不自然なところがある。 - 以上の理由で、プリミティブを追加するなら (3) より (4) がよい。 - (2) (remap 併用)や (5) は「内部処理にのみ意味をもつ値」が外に出て いるが、これはできるならば避けたい。 ただ、(4) に従って、和文用の \char (\kchar とする)を新設するとしても、 符号値が 0xFF を超える場合の \char は \kchar と同様に扱うことが、後方 互換性(「\char\jis"3021」を通す)のために必要です。 # 何だ、結局 0xFF 以下は特別扱いじゃないか ;-) 以上、私見を述べさせて頂きました。
この書き込みへの返事：