名前: ttk 日時: 2007-07-14 20:34:16 IPアドレス: 61.210.211.*
>>48356 いつもコメントありがとうございます。 すっかり日が空いてしまって済みませんでした。活動再開しました。 > \string<和文文字トークン> の仕様は 2 つ考えられます。 > (a) 現在の仕様。 > (b) 応分の場合に catcode を一律に 12 にしてしまうのと同様に、 > ある定まった kcatcode (例えば 18) の同じ文字のトークン > に変換する。 (b) kcatcode=18 に統一、という方がベターならば、 それでもいいかと思います。 この処理をしている function str_toks があちこちにも使われています。 例えば make_src_special 関連の記述もあって、 どんな影響があるか分かりません。 > 5. は現状維持で確定ですね(私もそれがいいと思います)。4. も現状で > 確定ですか? 5は確定(other_kchar)のつもりです。 半角かなが上手く出来たら、そこだけ「かな」に割り当てようか、 とも少し考えたのですが、 今はどちらかというと4も確定(other_kchar)で良いようにも思っています。 # もしかしたら、プログラム中の # kana や kanji は文字通り仮名と漢字で、それ以外は全部(3 区も含め) # other_kchar なのかもしれない? 同感です。 > kcatcode の既定値で、もう 1 つ頭の痛い問題 これは、頭が痛いです。 \usepackage[T1]{fontenc}の場合に、\ss など7bit記法が化けてしまうというのは 直感的でなく、好ましくないように思えます。 0x80〜0xFF の文字の \char のdefaultを和文にしてしまった副作用でした。 (現状のuptex) 0x80〜0xFFのkcatcodeをdefaultから変更しないと、 \usepackage[T1]{fontenc}の7bit記法の一部が化けてしまう。 (対策案1) マクロの側でがんばってもらう。 例えば、\DeclareTextSymbol を再定義して、和文化を避ける処理を加えてもらう。 短所:欧文LaTeXの\usepackage[T1]{fontenc}がそのままでは使えない。 (対策案2) 0xFF以下の \char が和文になるのを一律禁止する。 あえて\char を使いたいなら、 Unicodeのコードポイントに 0x110000 を足した値等を利用してもらう。 短所:\char で和文にしたいとき出来なく／ややこしくなる。 (対策案3) 0xFF以下の \char で和文／欧文の切り替えを 現在のuptexのkcatcode指定ではなく、別のスイッチを追加する。 短所:複雑化するし実装が面倒。プリミティヴの乱立もいかがなものか。 (対策案4) 0xFF以下の文字コードを和文化するプリミティヴ (例えば\kchar, \kchardef)を新設する。 短所:複雑化するし実装が面倒。プリミティヴの乱立もいかがなものか。 (対策案5) 和文トークンの内部コードを全部移動してしまう。 (以前のuptexでギリシャ文字などに使っていた手段を 全部の和文トークンに適用する) 例えば、Unicodeのコードポイント + 0x800000 にする。 短所:`<文字> で得られる値がUnicodeのコードポイントで無くなる (対策案その他) あまり妙案は思いつきません… pTeXのUnicode化で一番難しいのは、 「和文／欧文の取り合いになっている文字を どう切り替えできるようにするのか」 だと感じます。 (文字集合の規模の拡大、可変長8bitコードも別の難しさですが。) upTeXの最大の難関です(汗)。 どうしましょう。 何かご意見があれば伺いたいと思います。
この書き込みへの返事：