名前: ZR 日時: 2007-06-18 09:50:56 IPアドレス: 59.140.98.*
>>48327 >皆様、いろいろありがとうございます。 >uptex-0.09をこちらで公開しました。 もう実用的に使えそうなレベルにまで近づいていると感じています。 一般的な日本語 TeX 配布において採用される日を待ち望んでおります。 >>>48205 >オプションでcbfonts と unicodeパッケージの自動インストールを付けてみました。 >ギリシャ語のサンプルも用意しました。 ギリシャのサンプル greek-uplatex.tex で気になったこと。 サンプル中の古典ギリシャ語の文章の 4 行目 polla d'o g'en pontw ... (字上符省略) の中の 2 つの <'> は(UTF-8 ソース中で) apostrophe (U+2019) である べきですが、coronis (U+1FBD) になっています。 # coronis は母音の融合が起こった時に使われる特殊な無気記号であり、 # それゆえ、無気記号と同じグリフの non-spacing な記号として現れます。 # Unicode では、coronis と無気記号を同一の符号位置(U+0313)で表します。 # これとは別に、spacing の coronis が U+1FBD に、spacing の無気記号 # が U+1FBF にあり、これらは共に <0020,0313> への分解をもちます。 ## "Greek Extended" のブロックは互換目的で存在することに注意。 # 一方、母音が脱落した時に用いられるのは apostrophe (U+2019) で、 # これは勿論 spacing 記号です。 ## ちなみに、LGR での transliteration では、apostrophe は <''> と ## 表記します。 >>>48210 >\string の件、対応してみたつもりです。 >このケースでいうと、 >cjkトークンも一度UTF-8文字列になってから処理されますので、 >\kcatcode`あ=15 >の方が優先されます。 >これでいかがでしょうか？まだまずいでしょうか？ これで「変な挙動」は起こらなくなったと判断します。 \string<和文文字トークン> の仕様は 2 つ考えられます。 (a) 現在の仕様。 (b) 応分の場合に catcode を一律に 12 にしてしまうのと同様に、 ある定まった kcatcode (例えば 18) の同じ文字のトークン に変換する。 \string<文字トークン> というのは、大抵は、文字トークンの特殊性 (つまり 12 以外の catcode) を消すために用いられることが多いのだと 思っています。その感覚では「\string をかけると違う文字になる」と いうのは不自然がもしれません。 ただ、この \string<文字トークン> が用いられる場面はほとんどが \csname の中のような気もします。#1 が「現在 kcatcode が 15 の和文 文字」のトークンの場合の \csname hoge@\string #1\endcsnamea の結果は (a) でも (b) でも同じ(結局 UTF-8 符号化列に分解されたの と同じ)なんですね。 この仕様について、他のマクロ作成者の皆様の考えはどうでしょうか。 # \char や \chardef は「文字トークンに展開される」訳ではないので # この類の問題とは無縁。 >>>48229 >>>48242 >kcatcodeの既定値を変更しました。 >私が血迷っていなければ、ほぼ仰ったとおりの変更になっていると思います。 確認しました。 (>>48229) >1. "Yijing Hexagram Symbols" は 16(kanji) → 18(other_kchar)。 >2. "CJK Compatibility Ideographs" は 18(other_kchar) → 16(kanji)。 >3. "CJK Symbols and Punctuation" は 16(kanji) → 18(other_kchar)？ (その他 CJK 関係) >4. "Halfwidth and Fullwidth Forms" は 17(kana) → 18(other_kchar)？ >5. "Greek and Coptic" は 18(other_kchar) → 17(kana)？？？？ 5. は現状維持で確定ですね(私もそれがいいと思います)。4. も現状で 確定ですか? # オリジナルの pTeX で、もし仮に sjis の「2 区の縛り」がなかった # としたら、3 区(英数字), 6 区(ギリシャ文字), 7 区(ロシア文字)の # kcatcode はどうなったのだろう? もしかしたら、プログラム中の # kana や kanji は文字通り仮名と漢字で、それ以外は全部(3 区も含め) # other_kchar なのかもしれない? ---- そして、kcatcode の既定値で、もう 1 つ頭の痛い問題が見つかった のですが。 <test.tex> \documentclass{ujarticle} \usepackage[T1]{fontenc} %\kcatcode"80=15 % Latin-1 Supplement を欧文扱いに \begin{document} {\TeX} を使うと、 \begin{quote} ``?`But aren't Kafka's Schlo{\ss} and {\AE}sop's {\OE}uvres often na{\"\i}ve vis-\`a-vis the d{\ae}monic ph{\oe}nix's official r\^ole in fluffy souffl\'es?'' \end{quote} のような複雑な欧文も簡単に出力できます。 \end{document} Latin-1 ブロックの kcatcode を変更しないと、 - \ss や \OE が文字化けする(和文フォントのグリフになる) - \ae や \AE は文字は正しい(T1 と Unicode で符号位置が一致)が、 やはり和文フォントのグリフになる。 という現象が起こります。 \^o のような合成済文字(\DeclareTextComposite)と \oe のような特殊文字 (\DeclareTextSymbol)では扱いが微妙に異なっていて、前者は catcode が 12 の ^^f4 (文字トークン)に変換される(だから欧文扱い)のに対し、後者 は \char"F7 (\chardef によるトークン) に変換される(だから和文扱い) ようです。 これはあまり嬉しくないと思うのですが、さてどう対処したらいいか…。
この書き込みへの返事：