名前: ZR 日時: 2008-06-11 20:51:22 IPアドレス: 221.191.94.*
現状の dviout (3.18.1) で upTeX の DVI を表示できるかどうかを 再検討してみました。先に結論をいうと「現状では致命的な問題が ある」ということです。 # 前に書いた >>51135 は少し解り難い所がありました。 # 触れられている dviout の不具合が「upTeX の場合に特有」の # ものでは決してないことを喚起する為に故意に pTeX のフォント # の例を示したわけですが、メインの話題が upTeX である中では # 混乱の元でした。すみません。 元来、dviout はメトリックの調整を自前で(VF に頼らず)行いますが、 # 前回書いたときはこれに関する理解が不十分でした。 既定の設定では、その調整において必要な文字種の判別に文字コードを 利用しているので、unicode を用いる upTeX の DVI では失敗します。 %<サンプル1>-------- \documentclass{ujarticle} \begin{document} \fbox{「只今 up{\TeX} 文書のテスト中。」『大丈夫？』} \end{document} %<dviout マップファイル設定>-------- % 和文TFMを直接指定 upjisr-h "ＭＳ 明朝" unicode %<END>-------- しかし、これはオプション Jgt を有効にすることで対処できます。 (プロパティシートの [JFont2] の右下にある。) これを有効にすると dviout は文字種の判定方法を和文 TFM のメトリックグルーの設定値を 利用したヒューリスティックに変更します。これで上記のサンプルは 正しく表示されるはずです。しかし、次の例ではおかしな表示になって しまいます。 %<サンプル2>-------- \documentclass{ujarticle} \begin{document} \fbox{（只今 up{\TeX} 文書のテスト中。）［大丈夫？］} \end{document} %<END>-------- 原因を調べてみたところ、どうも和文 TFM の読込の仕様にあるようです。 通常 dviout は文字コードを int (Windows コンパイラでは signed 32bit) として扱っています。そして、和文 TFM では文字コードは 16bit で記され ていますが、dviout はこれを signed として読み込んでいます。従って、 文字コードが 0x8000 以上になると、TFM から読み込んだ結果は負の値に なる一方で DVI から読み込んだ値は正になり、結果的に TYPE の判定に 失敗してしまうようです。(<（> の Unicode 値は 0xFF08) # これが「バグ」なのかどうかは、upTeX の和文 TFM が dviout の想定 # する仕様に合っているかという微妙な問題に依存します。多分、多く # 人は「dviout は OTF パッケージの \UTF 命令をサポートする」と # 考えているはずです。ところが \UTF で使われる実の(VF が参照する # 方の) TFM は「Unicode を符号空間とする TFM」です。(実際にはこの # フォントは完全な等幅なので TFM に文字コードはそもそも現れなず # 問題は起こらない。) だから「dviout は 0x8000 以上の符号値を # 扱う和文 TFM をサポートしない」ではないわけです。 これは TFM の読込の問題なので、>>51135 の方法を用いて、VF を使う 方法に切り替えても回避できません。
この書き込みへの返事：