otf-cjXX-X.ofm は何のため？ #15
Comments
|
小川さんのサイト http://www2.kumagaku.ac.jp/teacher/herogw/history.html
齋藤さんのサイト http://psitau.kitunebi.com/otf.html
この辺りの情報を集めてみます。 |
|
調べようとしましたが，具体的にどのような問題が起きて OFM が作られたのかわかりませんでした。手元では OFM を削除して TFM が読まれる状況を作っても，dvipdfmx で問題は起きていないように見えます（もし見落としていたら教えてください）。 dvips の問題を防ぐために TeX Live では削除するというのはいかがでしょうか？ |
|
私が以前使っていた掲示板で，平田さんとやりとりをしているログが一部残っていました． |
|
cid〜.ofmというのはutfパッケージ（otfパッケージでなく）のファイルのことですか？ |
|
すみません，時間がとれず検証が遅れております。 それと，すみません，タイトル名とコメントの cid〜.ofm は別の場所からコピペした時のミスです。（元記事に cidホゲホゲ.ofm とあったのですが，間違いなく utf ではなく otf パッケージに関する記事でした） psitau さん，貴重なログありがとうございます。頂いた情報によると，まずは非埋め込みの場合に ofm 有無がどう影響するかを確認したほうがいいということですね。 |
|
otfパッケージのotf-cjXX-Xのことだとすると、単純にOFMを廃止して今あるJFMを使う、というのはマズイでしょう。otf-cjXX-Xは全て全角幅として作られている（TYPE定義がない）からです。 ただ、自分が考える限りでは、「字幅（全角・半角・三分・四分）が正しいJFM」を用意すれば、それで正常に処理できるような気がしています。 |
|
（ここから憶測） otf-cjXX-Xの符号空間はAJ1です。そのため、例えば 0x260A のような「JISコードとして不正な値」が出てきます。 今ならupTeXのuppltotfを使って所望のJFMを作れますが当時はupTeXはまだ存在しません。pTeXとppltotfは「JISコードとして不正な値」を扱えないため、所望のJFMを作るにバイナリを書き出すしかありません。またそもそもJFMの符号空間に「JISコードとして不正な値」を含めるのが危険だと判断されたかもしれません。 JFMでなくOFMを使ったのはこういう事情があったのではないか、と思っています。 |
|
古い環境を持っていないので私も憶測ですが…。
なるほど。
こちらは texjporg/tex-jp-build#78 で話題に出ている「jisx0213 パッケージ」が反例になりそうです。本件の OFM と同時期の成果物でありながら，JFM に「JISコードとしては不正な値」を使っているからです。 でも，逆に言えば，「jisx0213 パッケージ」が当時無事に動いていたことになるので，「今ならupTeXのuppltotfを使って所望のJFMを作れます」をやってみる価値はありますね。（昔の環境に新しい「所望のJFM」を持ち込んでも危険性は無かろう，という意味で言っています。） |
これをやる前に
が本当にマズイか試そうとしましたが，問題が起きる例を作れてないです…。もしかして全く問題ない？ |
|
この「和文VFの参照先の和文TFMが幅異常」というパターンは以前に調査したことがあるのですが、自分も「実際に異常が生じる例」を作れていません。 恐らく、間にVFが挟むことでdvipdfmxの「最適化」が阻害されている（“位置のリセット”が起こりやすくズレが蓄積しない）のだと推測しています。 なので、「現状のdvipdfmxでは安全」である可能性はあります。 ちなみに、doraTeX/sierraJFontはこの「異常パターンの度動作」に依拠しています。 |
|
コレはズレますね……。 |
|
あれれ、明らかにダメな気がする……。 % upLaTeX+dvipdfmx
\documentclass[uplatex,a4paper]{jsarticle}
\usepackage{otf}
\usepackage[kozuka-pr6n]{pxchfon}
\begin{document}
\aj半角{ナントカ}Conf
\CID{249}\CID{247}\CID{248}\CID{256}% 半角で"2019"
\end{document} |
|
あー，私が走らせたテストは字幅を見やすくするために色を付けたからでした。\special 発行ごとに「“位置のリセット”が起こりやすくズレが蓄積しない」に当たっていたようです。色を付けない（ \documentclass{jarticle}
\usepackage{otf}
\usepackage{color}
\AtBeginDvi{\special{pdf:mapline otf-cjmr-h Identity-H KozMinPr6N-Regular.otf}}
\begin{document}
\newcount\AJ\relax \AJ=0\relax
\newif\ifCOLORED \COLOREDfalse
\loop\ifnum\AJ<23060\relax
\ifnum\numexpr\AJ/20*20=\AJ\relax\vrule\par\the\AJ: \vrule\fi
\ifydir
\ifnum\AJ>230\relax\ifnum\AJ<633\relax\begingroup\color{red}\COLOREDtrue\fi\fi
\ifnum\AJ>8717\relax\ifnum\AJ<8720\relax\begingroup\color{red}\COLOREDtrue\fi\fi
\ifnum\AJ>12062\relax\ifnum\AJ<12088\relax\begingroup\color{red}\COLOREDtrue\fi\fi
\ifnum\AJ>9737\relax\ifnum\AJ<9758\relax\begingroup\color{green}\COLOREDtrue\fi\fi
\ifnum\AJ>9757\relax\ifnum\AJ<9779\relax\begingroup\color{blue}\COLOREDtrue\fi\fi
\fi
\iftdir
\ifnum\AJ>8949\relax\ifnum\AJ<9354\relax\begingroup\color{red}\COLOREDtrue\fi\fi
\ifnum\AJ>13253\relax\ifnum\AJ<13274\relax\begingroup\color{green}\COLOREDtrue\fi\fi
\ifnum\AJ>13273\relax\ifnum\AJ<13295\relax\begingroup\color{blue}\COLOREDtrue\fi\fi
\fi
\CID{\the\AJ}%
\ifCOLORED\endgroup\fi
\advance\AJ1\relax
\repeat
\end{document} |
|
今日調べてわかったことをまとめます。 dvipdfmx
dvips
新しい otf-cjXX-X.tfm を使うと，dvipdfmx でも dvips でも OK でした。（もちろん，ghostscript は縦組をうまく扱えないので distiller で試しました） という訳で，新しい TFM を使うようにしたいです。何か問題があればコメントお願いします。 |
|
念のため：TFM を作り直したものは https://github.com/texjporg/japanese-otf-mirror/tree/9c3b01652e1e7c5427d354b2de9672ba85528c87 にあります。
とは言っても，このリポジトリはあくまで非公式なので，
のどちらかとするのが筋でしょうね。 |
|
同様に「ヒラギノのプロポーショナル仮名 (\propshape)」に使われる hiraXXX-wX-X.tfm も同様の問題が起きるはずなので試そうとしましたが，こちらは「JFM では字幅もタイプも 256 種類まで」の上限に引っかかってしまいました…。
というように方策はいくつかありますが，一番めんどくさくないのは今のまま OFM ですね…。 |
|
一案として，dvips に対するこんなパッチを作ってみました。 このパッチを当てると，dvips が JFM 由来の VF からは OFM を参照しなくなります。先日のコメントのとおり，dvips では「和文VFの参照先の和文TFMが幅異常」でも問題は起きないらしいので，仮にOFMが幅正常だとしても読み込むモチベーションはないはずです。こうすれば，縦組で -noomega をわざわざ指定する必要がなくなります。 |
|
改めて考えてみると、結局 確認ですけど、現状で縦組のhirapropは「-noomega なdvips」で正常に使えている、ということでいいのでしょうか？ |
|
整理します。
そもそも，既に現在の dvipdfmx と dvips の挙動は 太字部分 で異なります。ここへ新たな異なる挙動が持ち込まれても，マイナスだとは思いません。
しかし，見方次第で「dvips では JFM 由来の VF からは OFM を参照しなくなった」⇒「OFM の存在自体は許容した」⇒「dvipdfmx が JFM 由来の VF から OFM を参照するのは許した」という風に，少々曲がった解釈をされかねない懸念はあります。 より安全そうな方策として，dvips を「縦組 JFM 由来の VF から OFM が参照された場合の挙動を改善して縦組対応する」というのを今思いつきました。
こうすれば，dvipdfmx と dvips の違いが「字幅情報さえ正しければ」と「字幅情報関係なく」だけに減る方向となります。もちろん，一般論として DVI ドライバが「JFM 由来の VF から OFM を参照した場合」の結果は仕様未定義，という立場を変えるつもりはありません。
こちらは後で確認します。 |
|
イロイロと考えてみました。
|
|
自分の結論としては、簡単な対処は |
|
私の意見もまだまとまっていないので，ひとまず「イロイロと考えてみました。」の内容を読んで思った雑多なコメントをします。
同意。特にコメントなし。
横組の議論には同意。「横組の和文VFが欧文TFMを参照する」の例を挙げるならば，dvi2dvi (ASCII pTeX DVI → NTT JTeX DVI) がありますね。 縦組の議論にも同意。たしかに dvips の挙動は理に適っているといえます。
この項の一連の議論は理解。
確かに，「縦組の和文VFが欧文TFM／OFMを参照するという挙動を保持する」に従うとすれば，「横転しない」を実現するための一案として理解できます。ただ，Omega に対応した DVI ウェアで「TFMとOFMの両方があるときはOFMを優先する」という挙動も，仕様として割と知られている気もします。 さて，これまでの議論で，特定の例に基づかずに持ち出された“一般化挙動”をピックアップします。これは，現状の「仕様」とみなしてほぼ良かろうと（私は）みなしているものです。
そして，少なくとも観察範囲において，dvips と dvipdfmx は全てを満たしています。 この観点から今まで出た案を分析します。
要は，落とし所をどうするかですねえ。 |
|
この Issue の議論には参加していなかったのですが、最近 japanese-otf 周りを触っているので考えてみました。
なので、私としては hirapropの方の「JFM では字幅もタイプも 256 種類まで」の制限に引っかかるという話、以前のJFMを拡張されたときにこの上限も撤廃されたのでしょうか? で、使用頻度、改造の手間も考えると、楽な順に次のようになるかと思います。 CTAN配布版はコミュニティ版として小さな拡張はありにする、という方針にしたので (2)位までは進めてもいいかと思っています。TeX Live 2022に入れるようがんばるかどうか。(4)までやるのは費用対効果が合わないと感じます。 |
|
https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=678 を読んで、dvipsに |
|
dvips で OFM の FONTDIR RT をJFMのid==9 と解釈するパッチ |
|
dvips で OFM の FONTDIR RT をJFMのid==9 と解釈するパッチをTeX Live svn にコミットしました。r62223
このうち (4) の 「dvipsをFONTDIR対応にする」が終わったので (4) は ofmを新しくするだけでよくなり、ハードルが下がりました。なので、(2)よりも(4)を優先して進めたいと今は考えています。 |
|
パッチも小さくテストも上々なので 「(4) ofmを新しくし、dvipsもFONTDIR対応にする」で一旦CTANに投稿予定です。今週末をめどに。 |
|
CTANに投稿しました。 @norbusan さん、 |
|
@t-tk さん、アップしました。ofmファイルだけの更新でしたよね？ |
|
ありがとうございます。 |
|
はい、tlcontribの更新にも入っています。 追伸：今度、余裕があれば、tlcontribのgh repoにPRしていただければ助かります。 |
|
さっき hiraprop のマニュアルを読んで初めて気づいたのですが、hirapropはヒラギノの中の従属欧文を使うためのパッケージなんですね。 |
|
紛らわしいかもしれませんが
|
|
コメントありがとうございます。混同していました。 |
|
本題の現象が「縦組用 OFM に FONTDIR RT を追加」かつ「dvips にそれを縦組と認識させる」により解決したことは確認できていたのですが，今度は dvipdfmx が の警告を出すようになったのを見落としていました…。dvipdfmx も実装上は OFM のディレクションを無視するという点で dvips と同じですが，警告が出すようになっていたようです。 ちなみに chkdvifont は数年前に OFM の FONTDIR 対応させたので と判定が効いていることをようやく確認できました ;-) |
|
警告は↓このあたりで出ているようです。 dvipdfmx の場合縦組みで従来から上手くいっている理由は jfm のID=9を見ているからなのか、フォントのWMode=1を見ているからなのか分かっていませんが、ofmのFONTDIR RTを見ていないという意味では正しいとも言えます。 |
|
texjporg/tex-jp-build@89b44ec でどうでしょう。 |
ありがとうございます。これは dvips と一貫していて良いですね。煩い気もするので，常には出さないように |
|
japanese-otf-uptex v0.29 を出し、 |
|
@norbusan さん https://github.com/texjporg/japanese-otf-mirror/releases/tag/2023-06-25 |
|
@t-tk さん |
|
はい。その通りで、nonfree は、README以外に変更はありません。 |
|
更新しました。 |
|
ありがとうございました。 |
https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=678
「\CID{...} や expert の縦書きが dvips でうまく行かない」という問題があります。原因は
だと分かっていて，実際に dvips 起動時のオプション -noomega を付ければ解消します。
では「なぜ ofm があるのか？」という話になります。
makeotf を見ると，この ofm は昔の「CVS 版 dvipdfmx（10年以上前）用」らしいのですが
それ以上の情報が得られていません。
これは何かのバグ回避なのでしょうか？ もしバグであれば dvipdfmx 本体で修正する方がよいでしょうし，もし直っているのならば OFM は不要だと思います。
The text was updated successfully, but these errors were encountered: