名前: ttk 日時: 2006-09-23 00:27:45 IPアドレス: 61.210.211.*
>>44981 栗山さん、安田さんコメントありがとうございます。 >（>>31724 角藤先生の解説） 簡潔で明快な解説が既にされていましたね。この通りです。 生の8bit欧文が偶然通る場合と偶然通らない場合と両方あるということで、 8言語／43言語という失敗の確率をどう言うかという点で表現の差があっただけだと思います。 > 現在の pTeX はなぜ和文16bitを一気に読まず、8bit + 8bit で処理しようとするのでしょうか。 そもそも、EUCやSJISは8bit 2byte和文＋7bit 1byte欧文の混在なわけで、 EUCやSJISを念頭に置くと不自然な仕様ではないでしょう。 また、単純に入力バッファを16bit化しても、ファイル毎にコード指定できる仕組みがないと、 今度は入力ファイル→入力バッファの段階で8bit欧文と和文の弁別はやはり困難です。 ( JIS(iso-2022-jp)なら8bit欧文と混在可能ですが ) 入力がUTF8になった場合も悩みは同じで、 もし現在の8bit欧文のハイフネーションパターンを^^ab化せずに生で読もうとすると、 今度はUTF8の8bit多バイトと干渉するのが頭の痛いところです。 >>44989 > pTeX の Unicode 対応についていえば、Unicode 文字のプロパティで > 和文かそれ以外かを判断して従来の和文／欧文規則が決定できるように > なればよいかなと思っています。 すみません。「Unicode 文字のプロパティ」というのが 何を指しているのか理解できませんでした。 このようなもののことでしょうか。言語を指定する情報はあるのかしら。 言語タグというのも聞いたことがありますが、 言語タグを編集できるテキストエディタが普及していないので 使いづらいかと思っています。 > つまり UTF-8 で原稿を書いても、言語パッケージが期待する各国個別 > コードに変換して当該パッケージに渡すなどの工夫が必要になってくる > わけで、これは相当の改造が必要なのではないでしょうか。 > 逆にこれができないと、omega, lambda と変わらないともいえます。 > 過去の遺産をきちんとカバーできることが重要だと思います。 なるほど、TeX+Babelで出来ることはカバーできるよう考えていたほうがよさそうですね。 ただ、多様なコード操作を可能にする仕組みを作るのは相当大変そうで、 遠い将来の話かな、と思います。 omegaのOTPは、随分色々なコード操作を出来るようなのですが、 omegaのOTP＋TeXのBabel部分みたいな方向の努力はなされなかったのでしょうか。 TeXの既存資産を生かして多言語化、といったことは和文を抜きにすれば可能に思えるのですが。 >>44993 > Unicode に限定した話だと、文字コードが欧文と和文ではそれぞれ > 異なったコード番号になるので選別が比較的容易になるのでは それがそうでもなくて、 JIS X 0208とLatin1(U+00FF以下)の範囲だけでも「¢£§¶¬°´¨±×÷」など、 和文と欧文の両方に需要がありそうな文字が同じコードポイントに重なっています。 「αβγ」などギリシャ文字、「абв」などキリル文字も 和文と欧文のどっちに割り当てたらいいか悩みます。 どっちにもカスタマイズできるような仕組みが要りそうだと思っています。 > 問題は現在の iso8859 系の8ビットコードと、SJIS や EUC の漢字 > コードが同じコード帯（0x80〜0xff）を使用していることから来る > トラブルなのかと理解していました。 「入力バッファ段階のトラブル」としては、この通りです。 「内部レジスタ」は和文16bitと欧文8bitが区別できるので、トラブルが起きません。 ところがUnicodeだと上記「¢£§¶¬°´¨±×÷」が内部レジスタ段階でも バッティングしてしまう、という悩みがあります。 > Unicode にある程度移行できたとしても、欧文8ビット（iso8859）と > 和文の「相性の悪さ」が残るとすると、これはこれで難しい問題 いやまさにその通りです。 MonTeXは未調査です。
この書き込みへの返事：