otf-cjXX-X.ofm は何のため？

aminophen commented 5 years ago

https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=678

‪「\CID{...} や expert の縦書きが dvips でうまく行かない」という問題があります。原因は

~cidmin-v.tfm~ otf-cjmr-v.tfm と ~cidmin-v.ofm~ otf-cjmr-v.ofm の両方があって，dvips は ~cidmin-v.ofm~ otf-cjmr-v.ofm の方を優先して見つけるから

だと分かっていて，実際に dvips 起動時のオプション -noomega を付ければ解消します。

では「なぜ ofm があるのか？」という話になります。‬

‪makeotf を見ると，この ofm は昔の「CVS 版 dvipdfmx（10年以上前）用」らしいのですが

making ofm file for dvipdfmx in CVS

それ以上の情報が得られていません。

これは何かのバグ回避なのでしょうか？もしバグであれば dvipdfmx 本体で修正する方がよいでしょうし，もし直っているのならば OFM は不要だと思います。

aminophen commented 5 years ago

小川さんのサイト http://www2.kumagaku.ac.jp/teacher/herogw/history.html

2004年2月8日 OTFパッケージ・インストーラを、開発版（2004/2/7版、v1.3.0）、安定版（2004/2/7版、v1.2.0）ともに更新。またCVS版dvipdfmxにUTF/OTFパッケージ等を用いてOpenTypeFontを埋め込んだ場合に若干の不整合が生じることが発見されたため、Big/Small両pTeXパッケージのdvipdfmxを、関係部分に関して以前の仕様に戻したものに差し替えるとともに、差分インストーラを用意した。

齋藤さんのサイト http://psitau.kitunebi.com/otf.html

v1.3.1, v1.2.1(2004/2/18) CVS版のdvipdfmxに対応するためOFMファイルを作成するようにした[makeotf, mkotf.bat, mkpropofm.pl, mkcidofm.pl] プロポーショナル仮名のVFを変更[mkpkana.pl, mkvpkana.pl] 上記の変更により，マップファイルをエントリを追加[hiraginox.map(for dvipdfmx), hiragino.map(for udvips)]

この辺りの情報を集めてみます。

aminophen commented 5 years ago

調べようとしましたが，具体的にどのような問題が起きて OFM が作られたのかわかりませんでした。手元では OFM を削除して TFM が読まれる状況を作っても，dvipdfmx で問題は起きていないように見えます（もし見落としていたら教えてください）。

dvips の問題を防ぐために TeX Live では削除するというのはいかがでしょうか？

psitau commented 5 years ago

私が以前使っていた掲示板で，平田さんとやりとりをしているログが一部残っていました． dvipsと挙動を合せるために変更をされたようです．その際に，非埋め込みの場合，グリフの幅をどこから持ってくるかと話になり，ofmを使うことになったのだと微かに記憶しています．添付したファイルの平田さんの発言をご参照ください．

newbbslog.txt

zr-tex8r commented 5 years ago

cid〜.ofmというのはutfパッケージ（otfパッケージでなく）のファイルのことですか？

aminophen commented 5 years ago

すみません，時間がとれず検証が遅れております。

それと，すみません，タイトル名とコメントの cid〜.ofm は別の場所からコピペした時のミスです。（元記事に cidホゲホゲ.ofm とあったのですが，間違いなく utf ではなく otf パッケージに関する記事でした）

psitau さん，貴重なログありがとうございます。頂いた情報によると，まずは非埋め込みの場合に ofm 有無がどう影響するかを確認したほうがいいということですね。

zr-tex8r commented 5 years ago

otfパッケージのotf-cjXX-Xのことだとすると、単純にOFMを廃止して今あるJFMを使う、というのはマズイでしょう。otf-cjXX-Xは全て全角幅として作られている（TYPE定義がない）からです。

ただ、自分が考える限りでは、「字幅（全角・半角・三分・四分）が正しいJFM」を用意すれば、それで正常に処理できるような気がしています。

zr-tex8r commented 5 years ago

（ここから憶測）

otf-cjXX-Xの符号空間はAJ1です。そのため、例えば 0x260A のような「JISコードとして不正な値」が出てきます。

今ならupTeXのuppltotfを使って所望のJFMを作れますが当時はupTeXはまだ存在しません。pTeXとppltotfは「JISコードとして不正な値」を扱えないため、所望のJFMを作るにバイナリを書き出すしかありません。またそもそもJFMの符号空間に「JISコードとして不正な値」を含めるのが危険だと判断されたかもしれません。

JFMでなくOFMを使ったのはこういう事情があったのではないか、と思っています。

aminophen commented 5 years ago

古い環境を持っていないので私も憶測ですが…。

単純にOFMを廃止して今あるJFMを使う、というのはマズイでしょう。otf-cjXX-Xは全て全角幅として作られている（TYPE定義がない）からです。

なるほど。

今ならupTeXのuppltotfを使って所望のJFMを作れますが当時はupTeXはまだ存在しません。またそもそもJFMの符号空間に「JISコードとして不正な値」を含めるのが危険だと判断されたかも

こちらは texjporg/tex-jp-build#78 で話題に出ている「jisx0213 パッケージ」が反例になりそうです。本件の OFM と同時期の成果物でありながら，JFM に「JISコードとしては不正な値」を使っているからです。

でも，逆に言えば，「jisx0213 パッケージ」が当時無事に動いていたことになるので，「今ならupTeXのuppltotfを使って所望のJFMを作れます」をやってみる価値はありますね。（昔の環境に新しい「所望のJFM」を持ち込んでも危険性は無かろう，という意味で言っています。）

aminophen commented 5 years ago

cidtfm ブランチで試してみています。まずは 769e07f で @zr-tex8r さんのコメントにあった

「字幅（全角・半角・三分・四分）が正しいJFM」を用意

をやってみました。japanese-otf/script/mkcidofm.pl というスクリプトがあったので，これをベースに japanese-otf/script/mkcidtfm.pl を作ってみています。

「現行の otf-cjXX-X.ofm」を削除（kpsewhich で見つからない状態に）した上で，「今回作った otf-cjXX-X.tfm」がちゃんと機能するのかどうかはまだ調べていません。

aminophen commented 5 years ago

「現行の otf-cjXX-X.ofm」を削除（kpsewhich で見つからない状態に）した上で，「今回作った otf-cjXX-X.tfm」がちゃんと機能するのかどうかはまだ調べていません。

これをやる前に

otfパッケージのotf-cjXX-Xのことだとすると、単純にOFMを廃止して今あるJFMを使う、というのはマズイでしょう。otf-cjXX-Xは全て全角幅として作られている（TYPE定義がない）からです。

が本当にマズイか試そうとしましたが，問題が起きる例を作れてないです…。もしかして全く問題ない？

zr-tex8r commented 5 years ago

この「和文VFの参照先の和文TFMが幅異常」というパターンは以前に調査したことがあるのですが、自分も「実際に異常が生じる例」を作れていません。

恐らく、間にVFが挟むことでdvipdfmxの「最適化」が阻害されている（“位置のリセット”が起こりやすくズレが蓄積しない）のだと推測しています。

なので、「現状のdvipdfmxでは安全」である可能性はあります。

ちなみに、doraTeX/sierraJFontはこの「異常パターンの度動作」に依拠しています。

zr-tex8r commented 5 years ago

コレはズレますね……。
upTeX：「和文VFの参照先の和文TFMが幅異常」なやつ
単純に「間にVFを挟めば大丈夫」というわけではないようです。

zr-tex8r commented 5 years ago

あれれ、明らかにダメな気がする……。

% 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}

aminophen commented 5 years ago

あー，私が走らせたテストは字幅を見やすくするために色を付けたからでした。\special 発行ごとに「“位置のリセット”が起こりやすくズレが蓄積しない」に当たっていたようです。色を付けない（\def\color#1{} とでもして無効化）とするとズレが蓄積しますね。

\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}

aminophen commented 5 years ago

今日調べてわかったことをまとめます。

dvipdfmx

一般に，dvipdfmx では「和文VFの参照先の和文TFMが幅異常」の場合，そのような文字ノードが連続するとズレが蓄積する。
現行OFM有り→和文VFの参照先は「幅が正常なOFM」なのでOK。
現行OFM無し，現行TFMだけ有→和文VFの参照先は「幅が不正なTFM」なのでNG。
現行OFM無し，新TFMだけ有→和文VFの参照先は「幅が正常なTFM」なのでOK。

dvips

一般に，dvips では「和文VFの参照先の和文TFMが幅異常」でも大丈夫らしい。（1文字ずつ配置するのでズレが蓄積しない？？？）
現行OFM有り→和文VFの参照先は「幅が正常なOFM」で，横組はOKで縦組はNG。
- ⇒ ~~縦組OFMでダメなのは dvips のバグなのか？~~ → そもそも otf-cjXX-v.ofm は -h と同じく (FONTDIR TL) なので横組用と読める。dvips はここも忠実に解釈している…とも言えるが，実装的には dvips は FONTDIR を単に無視しているだけ（それ以外の組方向はサポート外）。
現行OFM無し，現行TFMだけ有→和文VFの参照先は「幅が不正なTFM」だがOK。
現行OFM無し，新TFMだけ有→和文VFの参照先は「幅が正常なTFM」でOK。

新しい otf-cjXX-X.tfm を使うと，dvipdfmx でも dvips でも OK でした。（もちろん，ghostscript は縦組をうまく扱えないので distiller で試しました）

という訳で，新しい TFM を使うようにしたいです。何か問題があればコメントお願いします。

aminophen commented 5 years ago

念のため：TFM を作り直したものは https://github.com/texjporg/japanese-otf-mirror/tree/9c3b01652e1e7c5427d354b2de9672ba85528c87 にあります。

新しい TFM を使うようにしたいです。

とは言っても，このリポジトリはあくまで非公式なので，

公式配布者である齋藤さんにこのパッチを取り入れていただく
公式は backward compatibility の為に OFM を維持してもらい，最新の TeX Live に反映される CTAN 版だけはこの修正を取り込むことを了承してもらう

のどちらかとするのが筋でしょうね。

aminophen commented 5 years ago

同様に「ヒラギノのプロポーショナル仮名 (\propshape)」に使われる hiraXXX-wX-X.tfm も同様の問題が起きるはずなので試そうとしましたが，こちらは「JFM では字幅もタイプも 256 種類まで」の上限に引っかかってしまいました…。

OFM を使い続ける。（→ 引き続き dvips の縦組でオプション -noomega が必須。）
JFM の仕様を拡張する。
hiraXXX-wX-X.tfm へのマップを定義する phiraXXXwX-X.vf からの SELECTFONT を複数の TFM に割り当て直す。（→ ptex-fontmaps のヒラギノのマップ行も増量が必要。）

というように方策はいくつかありますが，一番めんどくさくないのは今のまま OFM ですね…。

aminophen commented 5 years ago

一案として，dvips に対するこんなパッチを作ってみました。

https://gist.github.com/aminophen/d2a874fca7531cec7a5ffa97d3de3ff1

このパッチを当てると，dvips が JFM 由来の VF からは OFM を参照しなくなります。先日のコメントのとおり，dvips では「和文VFの参照先の和文TFMが幅異常」でも問題は起きないらしいので，仮にOFMが幅正常だとしても読み込むモチベーションはないはずです。こうすれば，縦組で -noomega をわざわざ指定する必要がなくなります。

zr-tex8r commented 5 years ago

改めて考えてみると、結局「特定の目的のために（それも異常時の動作を利用する前提で）わざわざdvipdfmxと異なる仕様を持ち込む」ということ話になってしまうので、アレな気がしますね。

確認ですけど、現状で縦組のhirapropは「-noomega なdvips」で正常に使えている、ということでいいのでしょうか？

aminophen commented 5 years ago

整理します。

一般論として，DVI ドライバが「JFM 由来の VF から OFM を参照した場合」の結果は仕様未定義（たまたま期待通りかもしれないし，期待はずれかもしれない）。
先のコメントでまとめたとおり，実際の挙動としては
- dvipdfmx の場合
  - 同名の OFM と TFM が存在すれば OFM が優先される。
  - 横組/縦組とも，OFM と TFM のどちらを参照しても（字幅情報さえ正しければ）期待通りになる。
- dvips の場合
  - 同名の OFM と TFM が存在すれば OFM が優先される。
  - 横組では OFM と TFM のどちらを参照しても（字幅情報関係なく）期待通りになるが，縦組では OFM だと期待外れ，TFM だと（字幅情報関係なく）期待通りになる。

改めて考えてみると、結局「特定の目的のために（それも異常時の動作を利用する前提で）わざわざdvipdfmxと異なる仕様を持ち込む」ということ話になってしまうので、アレな気がしますね。

そもそも，既に現在の dvipdfmx と dvips の挙動は 太字部分 で異なります。ここへ新たな異なる挙動が持ち込まれても，マイナスだとは思いません。

先日のパッチを当てた場合の挙動は
- dvips の場合
  - 同名の OFM と TFM が存在すれば OFM が優先される。
  - ただし，JFM→VF→ と参照された場合は OFM は選択されない。
  - 横組/縦組とも，TFM を参照するので（字幅情報関係なく）期待通りになる。

しかし，見方次第で「dvips では JFM 由来の VF からは OFM を参照しなくなった」⇒「OFM の存在自体は許容した」⇒「dvipdfmx が JFM 由来の VF から OFM を参照するのは許した」という風に，少々曲がった解釈をされかねない懸念はあります。

より安全そうな方策として，dvips を「縦組 JFM 由来の VF から OFM が参照された場合の挙動を改善して縦組対応する」というのを今思いつきました。

この案が実現した場合の挙動としては
- dvips の場合
  - 同名の OFM と TFM が存在すれば OFM が優先される。
  - 横組/縦組とも，OFM と TFM のどちらを参照しても（字幅情報関係なく）期待通りになる。

こうすれば，dvipdfmx と dvips の違いが「字幅情報さえ正しければ」と「字幅情報関係なく」だけに減る方向となります。もちろん，一般論として DVI ドライバが「JFM 由来の VF から OFM を参照した場合」の結果は仕様未定義，という立場を変えるつもりはありません。

確認ですけど、現状で縦組のhirapropは「-noomega なdvips」で正常に使えている、ということでいいのでしょうか？

こちらは後で確認します。

zr-tex8r commented 5 years ago

イロイロと考えてみました。

「未定義動作」については、TeX界隈の習慣に従って、「リスクを把握した上なら未定義動作の利用も許容される」ものとする。
- ここでDVIウェアごとに実際の挙動が異なる場合は「ドライバ依存」ということになる。LaTeXにおける一般的なドライバ依存の対策の方法（ドライバオプションを設ける）も選択肢になりうる。
「和文VFがOFMを参照する」について。（字幅は正常とする）
- 欧文TFMとOFMの扱いは一貫して同等であるべき。(〠)
- 「横組の和文VFが欧文TFMを参照する」だったら自分も使ったことがある。多分他にも使っている人はいるはず。
- 「横組の和文VFが欧文TFMを参照する」の挙動がどうであるべきかは割と明確である。
- だから「横組の和文VFが欧文TFMを参照する」のは可能であることが望ましいし、また(〠)の観点からいうと「横組の和文VFがOFMを参照する」のも可能であってほしい。
- 一方で「縦組の和文VFが欧文TFM／OFMを参照する」については、挙動がどうであるべきかが明確でない。
- dvipsでの挙動は「縦組モード中で欧文を出力した」のと同等だと思われる。（この場合、DVIにおいては欧文の箇所で“モード”が変わるわけではない。baseline shiftが入るという違いはある。）
- 「VFにおけるグリフとは小さなDVI文書のことである」というVFの原則と照合すると、これ自体は理に適っている。
- だから「縦組の和文VFが欧文TFM／OFMを参照する」のも、dvipsとdvipdfmxで動作は違うが、挙動を保持する価値はある。
- もちろん、texjporgとして「和文VFが欧文TFM／OFMを参照する」についての“仕様”を決めて、各DVIウェアでの挙動を統一するという方針もありうる。その場合でも(〠)の観点は重視すべきだと思う。
「期待通り」について。
- 特定のケース（hiraprop）での挙動の如何を根拠にしてDVIウェアの挙動を決めてはいけない。
- だとすると「縦組では OFM だと期待外れ，TFM だと（…）期待通り」の「期待通り」とは何なのか。より一般化なケースで議論できないか。
- そこで一般に「縦組の和文VFが参照する論理フォントとしてJFMとOFMがある」というケース(♨)を考える。
- 欧文TFMとJFMは同時に存在できない（ファイル名が同一だから）なのでここでは(〠)を考慮する必要がない。
- この場合、「論理フォントとしては両者は等価であるべきで、ドライバ依存を吸収するために敢えて2つの版を用意している」と考えられる。
- 「縦組和文VFからJFMを参照した」場合は（字幅異常の件は措いて）参照先が縦組和文として機能すべきであることは自明である。
- となると、「両者は等価であるべき」なので、OFMの方も縦組和文として機能することが期待されているはず。
- 先述の通り、dvipsの“事実上の仕様”ではこのケースでのOFMは「横転した欧文」として機能する。従って、これは決して「期待通り」にならない。
以上より、「縦組の和文VFが参照先としてJFMとOFMの両方がある場合」は、dvipsではJFMの方を優先させるとする方針が考えられる。
- hirapropのケースを含めて(♨)の多くの問題を解決できる(♡)というメリットがある。また「ドライバ依存を吸収したい」という議論の帰結であるので「DVIウェア間で挙動が異なる」こと自体はデメリットにならない。
- ただ「“仕様”が複雑すぎて解りにくい」というデメリットはある。
- 複雑さを減らすために条件を緩和して「和文VFが参照先としてJFMとOFMの両方がある場合」とすることも考えられる。横組の場合はdvipsでOFMと同等なJFMを作ることは常に可能(♤)なので。
- ただし(♡)・(♤)については「dvipsでは字幅異常のTFMの挙動が定まっている」ことが前提になる。実装を確認しておくべきかも。

zr-tex8r commented 5 years ago

自分の結論としては、簡単な対処は
「（縦組の？）和文VFが参照先としてJFMとOFMの両方がある場合、dvipsではJFMを優先させる」
ということになりました。自きもちとしては、「字幅異常のTFM」は「欧文TFMを参照する横組和文VF」と比べてもずっと気持ちが悪いものなのであまり使いたくありません。また「欧文TFMとOFMで対応が食い違ってしまう」のも避けたいところです。

aminophen commented 5 years ago

私の意見もまだまとまっていないので，ひとまず「イロイロと考えてみました。」の内容を読んで思った雑多なコメントをします。

「未定義動作」について

同意。特にコメントなし。

「和文VFがOFMを参照する」について

横組の議論には同意。「横組の和文VFが欧文TFMを参照する」の例を挙げるならば，dvi2dvi (ASCII pTeX DVI → NTT JTeX DVI) がありますね。

縦組の議論にも同意。たしかに dvips の挙動は理に適っているといえます。

「期待通り」について

この項の一連の議論は理解。

以上より、「縦組の和文VFが参照先としてJFMとOFMの両方がある場合」は、dvipsではJFMの方を優先させるとする方針が考えられる。

確かに，「縦組の和文VFが欧文TFM／OFMを参照するという挙動を保持する」に従うとすれば，「横転しない」を実現するための一案として理解できます。ただ，Omega に対応した DVI ウェアで「TFMとOFMの両方があるときはOFMを優先する」という挙動も，仕様として割と知られている気もします。

さて，これまでの議論で，特定の例に基づかずに持ち出された“一般化挙動”をピックアップします。これは，現状の「仕様」とみなしてほぼ良かろうと（私は）みなしているものです。

[1] 和文VFが欧文TFM／OFMを参照する
[2] 欧文TFMとOFMの扱いは一貫して同等である
[3] TFM（欧文TFMかJFMか問わない）とOFMの両方があるときはOFMを優先する

そして，少なくとも観察範囲において，dvips と dvipdfmx は全てを満たしています。

この観点から今まで出た案を分析します。

「和文VFが参照先としてJFMとOFMの両方がある場合，dvips では JFM を優先させる」は，[1] と [2] は維持するが，[3] は満たさなくなる。
「dvips が JFM 由来の VF からは OFM を参照しない」は，[2] は維持するが，[1] と [3] は満たさなくなる。
「縦組 JFM 由来の VF から OFM が参照された場合の挙動を改善して縦組対応する」は，[1] と [3] を維持するが，[2] は満たさなくなる。（一方で，その結果 [4] JFMとOFMの扱いを一貫して同等にする，という新たな“一般化挙動”が生まれる。）

要は，落とし所をどうするかですねえ。

t-tk commented 2 years ago

この Issue の議論には参加していなかったのですが、最近 japanese-otf 周りを触っているので考えてみました。 https://github.com/texjporg/japanese-otf-mirror/issues/15#issuecomment-523896777 の挙動から私が思うに

dviwareのパッチなしに現状を変える(ofmを削除する)のならば「新しいotf-cjXX-X.tfm を使う」が正しい方向だと感じる。(⛄)
dvipsで縦組みのofmが現状でNGなのはofmの(FONTDIR TL)のせいでもあるし、dvipsがFONTDIRのTL以外をサポートしていない点が制限になっている所為と感じる。(☔)

なので、私としては ⛄の方向では、新しいtfmを作ってofmを削除する ☔の方向では、FONTDIRを縦組用にした新しいofmを作り、dvipsもそのFONTDIRをサポートするように拡張するのが仕様としてはきれいな方向なのなと思います。 ☔の方向は欧文tfmと横組みofmの一貫性も、ofmの仕様の整合性も縦横共に保てますし、jfmとofmの優先順位も気にならなくなると思います(どっちが先でも仕様として正しいjfm/ofmならば正しく組める)。

hirapropの方の「JFM では字幅もタイプも 256 種類まで」の制限に引っかかるという話、以前のJFMを拡張されたときにこの上限も撤廃されたのでしょうか? もう一点分からなかったのは「和文VF」と「omegaの多バイトのVF」ってどうやって区別するの? という点です。「VFの指している先がJFMの場合は和文VFである」という仕様にすればよい? じゃあ、指している先として hoge.tfm(中身はjfm)とhoge.ofmの両方が存在した場合は和文?

で、使用頻度、改造の手間も考えると、楽な順に次のようになるかと思います。 (1) 現状維持、(2) otf-cjXX-X.tfm だけ @aminophen さんの新版にする、(3) hirapropも新しいtfm を作る、(4) ofmを新しくし、dvipsもFONTDIR対応にする

CTAN配布版はコミュニティ版として小さな拡張はありにする、という方針にしたので (2)位までは進めてもいいかと思っています。TeX Live 2022に入れるようがんばるかどうか。(4)までやるのは費用対効果が合わないと感じます。

t-tk commented 2 years ago

https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=678

を読んで、dvipsに「VFの指している先の0番のhoge.tfmがJFMでありかつ、hoge.ofm も共存している場合は hoge.tfm(JFM)を優先させる」のようなの判定方法は急いで入れてもいいかもしれないと思いました。 TeX Live 2022 に入れるにはバイナリーの改造は急いだほうがいいし、 dvipsのオプションに --noomega と --noptex があるので明示的にどちらかを読ませたい場合は選択できますし。

aminophen commented 2 years ago

時間が経って忘れかけていました。コメントありがとうございます。現状では私は以下の考えです。

otf-cj〜.tfm → 私が作った「正しい字幅のJFM」を入れて「OFM」を削除するのがよい
ヒラギノのプロポーショナル → 同じことをやりたいが，字幅の種類が256を超えるのでJFMを作れない → OFMを読む以外に手段がない

よって，dvipsの機能修正をすべきかどうかは悩ましく，とりあえず otf-cj〜の件だけ対応して，ヒラギノの方はゆっくり考えたいです。

t-tk commented 2 years ago

コメントありがとうございます。やはり現時点ではdvipsの修正は時期尚早と思います。↓の (2) を試してみます。

(1) 現状維持、(2) otf-cjXX-X.tfm だけ @aminophen さんの新版にする、(3) hirapropも新しいtfm を作る、(4) ofmを新しくし、dvipsもFONTDIR対応にする

t-tk commented 2 years ago

そもそも縦組みの実装のあるべき姿は?というところに立ち返って考えようとして、ググってみたら一番まとまっていたのが↓でした。 (漢字語|縦組)タイプセット土村さんのところで14年前に議論したものです。こんなに後になって役に立つとは。リンク切れになっているものが多々あります。散逸しないようまとめ直したいと思いました。取り急ぎ要点のみを記します。

script	WMode	JFM ID	DVI #255	組み方向	字送り方向	行送り方向	Omega風に言うと	OFM FONTDIR
欧文	---	---	0	横組み	水平左→右	垂直上→下	TLT	TL
和文	0	11	0	横組み	水平左→右	垂直上→下	TLT	TL
欧文	---	---	1	縦組み	垂直上→下	水平右→左	RTR	TL
和文	1	9	1	縦組み	垂直上→下	水平右→左	RTT	(RT:今回候補)
欧文	---	---	1	縦組み(座標回転)	水平左→右	垂直上→下	TLT	TL
和文	1	9	1	縦組み(座標回転)	水平左→右	垂直上→下	TLL	(RT:今回候補)

WMode はPostScript, PDF, TrueType, OpenType のフォントの属性としてCJKの文字の組方向を表すオペランド。 JFM ID は pTeX の JFM で組方向を表すオペランド。 DVI #255 は pTeX の拡張 DVI命令で組方向を示すもの。「縦組み(座標回転)」は、出力結果は縦組みと同じだが、座標系を90度回転させたものと考えた場合。

PostScript / PDF の場合は WMode の切り替えでグリフの中でのカレントポイントの起点座標と移動ベクトルを切り替えているだけ。行送り方向は moveto などで指定する。 pTeX では、DVI命令#255 とJFM IDの組み合わせで文字送り方向と文字の向きを決めている。 pTeX の和欧混植をOmega風に言うと、座標の取り方により RTR(欧)とRTT(和)の組み合わせと見ることもできるし TLT(欧)とTLL(和)の組み合わせと見ることもできる。

(2022/03/02追記) japanese-otf-uptex/test/uplatex の方にサンプル (direction-utf8.tex など) を入れた。やはり、和文縦組みのグリフは ofm では FONTDIR RT で表すのが適切だと考える。

t-tk commented 2 years ago

欧文とアラビア文字の混植は TLT(欧文) と TRT(アラビア文字) の混植となり OFM の FONTDIR は TL(欧文) と TR(アラビア文字) になるらしい。実際、omarab.ovp の FONTDIR は TR になっています。

日本語の縦組みの場合、RTT の書字方向を FONTDIR RT で組むと考えるのが自然に思えます。しかし、実際にはTLの欧文フォントとの混植が必要なので、「TL の欧文フォントをRTの和文フォントと混植する結果 pTeXの縦組みの組み方になる」、と考えても整合性は取れていると思います。

[1] 和文VFが欧文TFM／OFMを参照する
[2] 欧文TFMとOFM(FONTDIR TL)とJFM(ID 11)の扱いは一貫して同等である
[3] TFM（欧文TFMかJFMか問わない）とOFMの両方があるときはOFMを優先する
[4] JFM(ID 9)とOFM(FONTDIR RT)の扱いは同等

今回、[1]～[3] は従来の仕様を継承し [4] の仕様を今回追加することになります。自然な拡張になっているといえます。もし仮に、pTeX の縦組みに通常のTFM(欧文)に追加してOFM(欧文)の横組みを混植したくなった場合、欧文はOFM(FONTDIR TL)を組み合わせれば組版できます。落としどころとしては妥当だと思います。

t-tk commented 2 years ago

dvips で OFM の FONTDIR RT をJFMのid==9 と解釈するパッチ https://github.com/texjporg/tex-jp-build/commit/d3f4db01509173f2fafaf6a4f6cddd11aa23f0ce と otf-ciXX-X.ofm に FONTDIR RT を加えるパッチ https://github.com/texjporg/japanese-otf-mirror/commit/a66f53c4405114dbe0b4aac6e9e91a5652edcf99 の組み合わせで予定通り上手く動くことを確認しました。副作用も見つかっていないし、無いはずなので、このまま進めます。 dvips の方は後で TeX Live svn にコミットしておきます。

t-tk commented 2 years ago

dvips で OFM の FONTDIR RT をJFMのid==9 と解釈するパッチをTeX Live svn にコミットしました。r62223 [dvips] OFMのFONTDIR RTをpTeXの縦組みと解釈させる? https://github.com/texjporg/tex-jp-build/issues/135

(1) 現状維持、(2) otf-cjXX-X.tfm だけ @aminophen さんの新版にする、(3) hirapropも新しいtfm を作る、(4) ofmを新しくし、dvipsもFONTDIR対応にする

このうち (4) の「dvipsをFONTDIR対応にする」が終わったので (4) は ofmを新しくするだけでよくなり、ハードルが下がりました。なので、(2)よりも(4)を優先して進めたいと今は考えています。 otf-cjXX-X.tfm の更新は、j-otf-uptex で \CID{} の多書体化の構想があるので、それと一緒でもいいかなと思い始めています。

t-tk commented 2 years ago

パッチも小さくテストも上々なので「(4) ofmを新しくし、dvipsもFONTDIR対応にする」で一旦CTANに投稿予定です。今週末をめどに。「(2) otf-cjXX-X.tfmの更新」は jotf-uptex の \CIDT{} などの多書体化と一緒にぼちぼち検討します。

t-tk commented 2 years ago

CTANに投稿しました。

@norbusan さん、 nonfree を TLContrib にインストールしていただけますか? https://github.com/texjporg/japanese-otf-mirror/releases/download/2022-03-05/japanese-otf-nonfree-20220305.0.tar.gz

norbusan commented 2 years ago

@t-tk さん、アップしました。ofmファイルだけの更新でしたよね？

t-tk commented 2 years ago

ありがとうございます。縦組みofm の他、COPYRIGHT に typo があったので、そこも更新しています。

diff -urN japanese-otf-nonfree-20220217.0/COPYRIGHT japanese-otf-nonfree-20220305.0/COPYRIGHT
--- japanese-otf-nonfree-20220217.0/COPYRIGHT   2022-02-17 19:43:11.000000000 +0900
+++ japanese-otf-nonfree-20220305.0/COPYRIGHT   2022-03-05 17:11:41.000000000 +0900
@@ -1,5 +1,5 @@
 Copyright (C) 2003--2019 SAITO Shuzaburo and INOUE Koichi
-Copyright (C) 2007--2020 TANAKA Takuji
+Copyright (C) 2007--2022 TANAKA Takuji
 Copyright (C) 2017--2022 Japanese TeX Development Community
 All rights reserved.

diff -urN japanese-otf-nonfree-20220217.0/README japanese-otf-nonfree-20220305.0/README
--- japanese-otf-nonfree-20220217.0/README  2022-02-17 19:44:23.000000000 +0900
+++ japanese-otf-nonfree-20220305.0/README  2022-03-05 17:14:23.000000000 +0900
@@ -19,4 +19,4 @@
 COPYRIGHT file, which is the 3-clause BSD license.

 Japanese TeX Development Community
-20220217.0
+20220305.0
Binary files japanese-otf-nonfree-20220217.0/ofm/hirakaku-w3-v.ofm and japanese-otf-nonfree-20220305.0/ofm/hirakaku-w3-v.ofm differ
Binary files japanese-otf-nonfree-20220217.0/ofm/hirakaku-w6-v.ofm and japanese-otf-nonfree-20220305.0/ofm/hirakaku-w6-v.ofm differ
Binary files japanese-otf-nonfree-20220217.0/ofm/hiramaru-w4-v.ofm and japanese-otf-nonfree-20220305.0/ofm/hiramaru-w4-v.ofm differ
Binary files japanese-otf-nonfree-20220217.0/ofm/hiramin-w3-v.ofm and japanese-otf-nonfree-20220305.0/ofm/hiramin-w3-v.ofm differ
Binary files japanese-otf-nonfree-20220217.0/ofm/hiramin-w6-v.ofm and japanese-otf-nonfree-20220305.0/ofm/hiramin-w6-v.ofm differ

norbusan commented 2 years ago

はい、tlcontribの更新にも入っています。ありがとうございます。

追伸：今度、余裕があれば、tlcontribのgh repoにPRしていただければ助かります。

t-tk commented 2 years ago

さっき hiraprop のマニュアルを読んで初めて気づいたのですが、hirapropはヒラギノの中の従属欧文を使うためのパッケージなんですね。そうすると縦組みの場合には横組み用の従属欧文フォントをRTRの方向で組むのが正しいのかもしれない、と思いました。そのときの和文はどうなっているのかなど、ちゃんと理解しないとあるべき実装が作れないようです。 hiraprop は CTAN にも出していないので、ぼちぼち見てみます。

aminophen commented 2 years ago

紛らわしいかもしれませんが

私が問題にしていたのは japanese-otf(-uptex)-nonfree パッケージの機能 \propshape において「ヒラギノのプロポーショナル仮名が dvips で縦組にならない」です。これは字幅種類256を超えるため現行 JFM フォーマットでは対応できず OFM が必要なせいですが，これは「FONTDIR RT 対応の新しい dvips」に「FONTDIR RT を追加して再生成した OFM」を読ませればすれば良いと思います。
hiraprop パッケージは従属欧文のせいぜい256文字が対象なので，こちらは現状のままで OK → 何もしないのが正しいと思います。

t-tk commented 2 years ago

コメントありがとうございます。混同していました。同じ名前でほぼ同じ内容のofm (SEVENBITSAFEFLAGが異なるのみ) が japanese-otf/ofm/hiramin-w3-h.ofm hiraprop/ofm/hiramin-w3-h.ofm のようにあり、共通に使われていました。また hiraprop/ofm の方はもともと v が含まれていませんでした。 hiraprop の方は FONTDIR RT に変更するかどうかの対象にはならないと理解しました。

aminophen commented 2 years ago

本題の現象が「縦組用 OFM に FONTDIR RT を追加」かつ「dvips にそれを縦組と認識させる」により解決したことは確認できていたのですが，今度は dvipdfmx が

dvipdfmx:warning: I may be interpreting a font direction incorrectly.

の警告を出すようになったのを見落としていました…。dvipdfmx も実装上は OFM のディレクションを無視するという点で dvips と同じですが，警告が出すようになっていたようです。

ちなみに chkdvifont は数年前に OFM の FONTDIR 対応させたので

$ chkdvifont -v otf-cjmr-v.ofm
    "otf-cjmr-v" is a ofm level 1 file :  0  -> 23059
        PARAMETERS:
          lh:    18
          bc:     0
          ec: 23059
          nw:     5
          nh:     2
          nd:     2
          ni:     1
          nl:     0
          nk:     0
          ne:     0
          np:     6
        + FONTDIR: RT
    checksum        = 00000000
    design size     = 10485760 2^{-20} points = 10 points

と判定が効いていることをようやく確認できました ;-)

t-tk commented 2 years ago

警告は↓このあたりで出ているようです。 https://github.com/texjporg/tex-jp-build/blob/2fbeb9587723a6414a73ba3154280b0ed6540b2c/source/texk/dvipdfm-x/tfm.c#L632-L635

dvipdfmx の場合縦組みで従来から上手くいっている理由は jfm のID=9を見ているからなのか、フォントのWMode=1を見ているからなのか分かっていませんが、ofmのFONTDIR RTを見ていないという意味では正しいとも言えます。 dvipsのときに縛った条件「ofmを読み込む際 !noptex かつ fontlevel==1 かつ ec>= 0x2E00 の場合、ofm をpTeXの和文用であるとみなし、さらに FONTDIRが RT のとき、ofmをpTeXの和文用の縦組み用であるとみなす。」に適合する場合に警告を出さないかあるいはマイルドな表現にするか、位の対策を思いつきます。 dvipdfmxでは dvips における noptex オプションに相当するものはなさそうですね。「dvi の postamble にある dvi のフォーマットが 2 ではなくて 3 である」を根拠に切り替える手もあるかもしれません。(言うのは簡単だが面倒。)

t-tk commented 2 years ago

https://github.com/texjporg/tex-jp-build/commit/89b44ec8d0fc0a31d6ca927699420c58333da4d7 でどうでしょう。該当する場合の警告の文句を差し替えただけですが。

dvipdfmx:warning: I will interpret a font direction as pTeX vertical writing.

aminophen commented 2 years ago

https://github.com/texjporg/tex-jp-build/commit/89b44ec8d0fc0a31d6ca927699420c58333da4d7 でどうでしょう。

ありがとうございます。これは dvips と一貫していて良いですね。煩い気もするので，常には出さないように dpx_conf.verbose_level でデバッグ専用にしてもいいと思います。

t-tk commented 2 years ago

TeX Live tl23/dev が始まったので TeX Live svn r62963, r62964 コミットしました。

t-tk commented 1 year ago

japanese-otf-uptex v0.29 を出し、 japanese-otf をCTANに投稿しました。 otf-cjXX-X.tfm の文字幅を正しくし、otf-cjXX-X.ofm はCTAN配布から削除しました。ヒラギノ prop の方の ofm は、そのままになっています。

t-tk commented 1 year ago

@norbusan さんいつもありがとうございます。 japanese-otf-uptex の更新をしました。 nonfree の方は今回ドキュメントだけの更新で、ソフトウェアの機能に更新はありません。なので、重要度は低いですが、何かの折にでも TLcontrib へのインストールをしていただければと思います。

https://github.com/texjporg/japanese-otf-mirror/releases/tag/2023-06-25 の japanese-otf-nonfree-20230625.0.tar.gz

norbusan commented 1 year ago

@t-tk さんいつもお世話になります。確認のためなんですが、nonfreeの内容はREADME以外の変更がないようです。これでよろしいですか？

t-tk commented 1 year ago

はい。その通りで、nonfree は、README以外に変更はありません。

norbusan commented 1 year ago

更新しました。引き続きよろしくお願いいたします。

t-tk commented 1 year ago

ありがとうございました。ここは閉じます。

texjporg / japanese-otf-mirror

otf-cjXX-X.ofm は何のため？ #15

dvipdfmx

dvips