和文vf の fallback を dviware で

[t-tk]

(English summary follows Japanese.)
uptex-font の方で以前話題にしたことのある件を調べ始めました。今後主に dviware の改良の話に向かいたいのでこちらの tex-jp-build に Issueを立てます。

まずは、一部繰り返しになりますが、振り返りながらまとめます。
動機は次の通りです。
japanese-otf(-uptex)などで和文vfを利用する際、漢字など大量のエントリーが『文字コードを維持したまま最初のJFM のchar_type 0番にフォント名、メトリックスを割り当てる』だけのものになっている。そこが単純な割に容量を食っていて、書体数や文字数を増やそうとするとバカにならないくらい巨大になる。そこで、「和文vf の中でエントリーが見つからない場合は『文字コードを維持したまま、最初のJFM のフォント名を、かつJFMのchar_type 0番にメトリックスを割り当てる』のような動作を仕様化して dviware 側で対処しよう」、という提案です。

uptex-fontの方 で長い議論がありましたが、一部以下に再掲します。

「MAPFONTで指示されているfont IDの一番若いものがJFMであるとき、要求されたコードポイントが明言されていな場合は，それが最小の font ID に属し，かつそのコードポイントそのものを出力する」
というルールの追加でよいように思います。つまり、VFの仕様拡張としては、idを追加して新しい命令を用意して…という方向でなく、解釈を拡張するというイメージです。

例えば、現状、upphiraminw3-h.ovp は、冒頭が

(MAPFONT D 1
   (FONTNAME uphminr-h)
   (FONTCHECKSUM O 0)
   (FONTAT R 1.000000)
   (FONTDSIZE R 10.000000)
   )

で、おしまいの方に次のようなエントリーが延々と続きます。

(CHARACTER H 2F9F4
   (CHARWD R 1.000000)
   (MAP
      (SETCHAR H 2F9F4)
      )
   )

その代わり、CHARACTERのエントリーがない文字コード 0xXXXXX の要求が来た場合、従来エラーでしたがその代わりに

(CHARACTER H XXXXX
   (CHARWD R 1.000000)
   (MAP
      (SETCHAR H XXXXX)
      )
   )

であると解釈する、という新ルールです。

otf パッケージでは、現在 {,u}mkjvf によりovp を生成しています。該当部分を削除すれば済むだけですので、改造は容易でしょう。
逆に出力不能な文字がソースに来た場合、従来は{,u}platexのコンパイル時にエラーが出ましたが、新ルールの元ではdviwareの処理までエラーが出ないことになります。
逆に出力不能な文字がソースに来た場合、従来はdviwareがvfのエントリー不足を発見した時にエラーが出ましたが、新ルールの元ではdviwareが実フォントにアクセスを試みるまでエラーが出ないことになります。

---

(English summary)
I propose a new rule:
If a virtual font has no entry of a codepoint and the first MAPFONT designates (u)pTeX JFM,
we designate the glyph of the same codepoint in the TFM(JFM) with the smallest font ID.
The new rule helps to shrink size of Japanese virtual fonts.

For example, conventionally upphiraminw3-h.ovp starts with

(MAPFONT D 1
   (FONTNAME uphminr-h)
   (FONTCHECKSUM O 0)
   (FONTAT R 1.000000)
   (FONTDSIZE R 10.000000)
   )

and a huge volume of entries for fullwidth characters continue such as:

(CHARACTER H 2F9F4
   (CHARWD R 1.000000)
   (MAP
      (SETCHAR H 2F9F4)
      )
   )

Conventionally, if the virtuanfont lacks an entry of a CHARACTER 0xXXXXX, dviware rejected.
My proposal is to introduce the new rule to interpret as the fullwidth CHARACTER 0xXXXXX of uphminr-h:

(CHARACTER H XXXXX
   (CHARWD R 1.000000)
   (MAP
      (SETCHAR H XXXXX)
      )
   )

---

(Extended feature, 2023-04-29)

The rule for virtual fonts (VF) fallback is extended:
If a VF has no entry of a codepoint and the first
MAPFONT designates an OFM for (u)pTeX, then we designate the
glyph (usually with a fullwidth metric) of the same codepoint
with the same metrics of the codepoint in the OFM.

[t-tk]

前回話題になっていたソフトのリストです。

和文vfを取り扱うdviware:

• dvipdfmx → TeX Live r54319, r54979 済
• dvips → TeX Live r54794, r57024, r58812 済
• dvisvgm → サポート依頼を開発元に投稿→v2.11 リリース済, TeX Live r57502 済
• dvicopy → pTeX未対応、今回の対応も無し
• dviout → 対応難しく、今回の対応も無し
• pxdvi → obsoleteにつき対応無し

和文vfを生成するソフトウェア:

• makejvf → '-O'オプション, TeX Live r54693 済
• ovp2ovf / wovp2ovf → 入力時のOVPのエントリーを削ることで対処
• japanese-otf(-uptex) (OVPのエントリーを削る) → japanese-otf-uptex v0.26 済

[t-tk]

ブランチ https://github.com/texjporg/tex-jp-build/tree/vf_fallback で試しています。
dvipdfmx は 3dc3d48 のようにしようかと考えています。
(u)pTeX の vf であることをチェックするのに「定義されている文字コードの最大値が 0x100 以上である」ということで行っています。欧文 TeX の vf では当然使っていないはずなので弾くことが出来ますが、Omega の不正な vf ではfallbackの部分にたどり着いてしまう可能性があります。しかし、本来 Omega の正常な vf ではこのfallbackには来ないはずで omega + dvipdfmx の利用者に迷惑がかかることも無いかと思います。
きちんとするには JFM をたどって (u)pTeX の JFM かどうかをチェックする方がよさそうですがよく分かりませんでした。
dvipdfmx は vf の文字幅を操作することは無く並べるだけのようです。なので今回のコードでも JFM のメトリックスを見に行くこともしていません。

[t-tk]

参照先の tfm が jfm であることを判定する方法が分かったのでそちらで判定するようにしました。 1b3e72e
本日が TeX Live 2020 の code freeze 予定日です。
手元で上手く動いていてコードも簡潔で副作用も考えにくいので、急ではありますがTeX Live svnにコミットしてしまおうと思います。 → コミットしました。r54319

[t-tk]

makejvf は 6470129 のようにしようかと考えています。
-O オプションを追加。これが設定されているときは、約物以外(全角幅のdefaultのグリフをもつ文字)はVFに記載しない。-t によるカスタム設定との同時使用は禁止。-t によるカスタム設定の方が自由度が高いため。

これは TeX Live 2020 には入れず、来年を目指します。
何かご意見や問題などがあればお知らせください。

[t-tk]

私の認識では

• wovp2ovf (ovp2ovfのweb版, ovp2ovf ver 1.xx )
• ovp2ovf (ovp2ovfのC版, omfonts -ovp2ovfに同じ, ovp2ovf ver 2.xx )

ともに、入力の *.ovp の時点で生成を省略したいエントリーを前もって削除しておけば所望のvfが作成できると思っています。今回の件ではソースの変更はしないつもりです。

dvicopy は従来の pTeX の vf も現時点では扱えないようなので、今回の拡張も対処無しにしたいと思います。もし将来 pTeX の vf も対処することがあるならば今回の拡張も含めることを期待することにします。

[aminophen]

makejvf は 6470129 のようにしようかと考えています。

試していますが，非漢字部を別の TFM に割り当てる -K オプションで全角幅の文字が仮名にならないので対策しようと思います。少し時間をください。

% cp -p jis.tfm myjis.tfm
% makejvf -K myjis-kana myjis myjis-kanji
% cp -p jis.tfm myjiso.tfm
% makejvf -O -K myjiso-kana myjiso myjiso-kanji

\documentclass[a4paper]{jsarticle}

% for myjis
\DeclareKanjiFamily{JY1}{myjis}{}
\DeclareFontShape{JY1}{myjis}{m}{n}{<-> s * [0.961] myjis}{}
\DeclareFontShape{JY1}{myjis}{m}{it}{ssub * myjis/m/n}{}
\DeclareFontShape{JY1}{myjis}{m}{sc}{ssub * myjis/m/n}{}
\DeclareFontShape{JY1}{myjis}{m}{sl}{ssub * myjis/m/n}{}
\newcommand{\myjisdefault}{myjis}
\DeclareRobustCommand\myjisfamily{\kanjifamily\myjisdefault\selectfont}
\DeclareTextFontCommand{\textmyjis}{\myjisfamily}

% for myjiso
\DeclareKanjiFamily{JY1}{myjiso}{}
\DeclareFontShape{JY1}{myjiso}{m}{n}{<-> s * [0.961] myjiso}{}
\DeclareFontShape{JY1}{myjiso}{m}{it}{ssub * myjiso/m/n}{}
\DeclareFontShape{JY1}{myjiso}{m}{sc}{ssub * myjiso/m/n}{}
\DeclareFontShape{JY1}{myjiso}{m}{sl}{ssub * myjiso/m/n}{}
\newcommand{\myjisodefault}{myjiso}
\DeclareRobustCommand\myjisofamily{\kanjifamily\myjisodefault\selectfont}
\DeclareTextFontCommand{\textmyjiso}{\myjisofamily}

% map file
\AtBeginDvi{\special{pdf:mapline rml H ipaexm.ttf}}
\AtBeginDvi{\special{pdf:mapline gbm H ipaexg.ttf}}
\AtBeginDvi{\special{pdf:mapline myjis-kana H ipaexm.ttf}}
\AtBeginDvi{\special{pdf:mapline myjis-kanji H ipaexg.ttf}}
\AtBeginDvi{\special{pdf:mapline myjiso-kana H ipaexm.ttf}}
\AtBeginDvi{\special{pdf:mapline myjiso-kanji H ipaexg.ttf}}

\pagestyle{empty}
\begin{document}

\myjisfamily
[漢字・あいうえお。漢字も、大丈夫（かなだけ別）だよ]

\myjisofamily
[漢字・あいうえお。漢字も、大丈夫（かなだけ別）だよ]

\mcfamily
[漢字・あいうえお。漢字も、大丈夫（かなも同じ）だよ]

\gtfamily
[漢字・あいうえお。漢字も、大丈夫（かなも同じ）だよ]

\end{document}

[aminophen]

非漢字部を別の TFM に割り当てる -K オプションで全角幅の文字

391c95c でどうでしょう？

[t-tk]

ご検討有難うございます。
-K オプションとは知りませんでした。
kanatfm の対象が「非漢字部」ということですがその集合がよく分かりません。
JIS X 0208の6区(0x2621..0x2658, ギリシャ文字), 7区(0x2721..0x2771, キリル文字) はどちらに含まれるのでしょうか? もしこれらがkanatfmの対象になるのならば、エントリーを省略しない方に回すことになりそうです。

[aminophen]

kanatfm の対象

if (!kanatfm || code > 0x2576)

の 0x2576 は，その下の方にあった

	if (kanatfm) {
		if (code <= 0x2576)

に依拠しています（妥当かどうかはさておき）。個人的には，

• 6区ギリシャ文字
• 7区ロシア文字
• 8区罫線素片

が漢字側なのは違和感がありますが，アスキー版の挙動が今に至るまで維持されているため今回もそれに従いました。

UCS mode については #16 のときの議論のとおりです。

[t-tk]

kanatfm の文字集合は了解しました。391c95c に同意します。

[t-tk]

japanese-otf-uptex は、私の所「和文vf の fallback を使った vf の軽量化」で検討します。

[t-tk]

IPAmj明朝フォントの変体仮名で遊んでみました。
uplatex + dvipdfmx ver.20200315 で予定通り変体仮名が埋め込まれました。
しかしupTeX(とdviware)が合成用の濁点・半濁点に対応していないので、IPAmj明朝フォントが濁点・半濁点付きグリフを持っているのにもかかわらず利用できていません。
#46 の開発項目が実現できれば同時に出来るはずで、いつかは実現したいところです。

\documentclass{ujarticle}
\AtBeginDvi{\special{pdf:mapline uprml-h unicode ipamjm.ttf}}

\begin{document}

\section{変体仮名}

𛀂𛀃𛀄𛀅𛀆𛀇𛀈𛀉𛀊𛀋𛀌𛀍𛀎𛀏
𛀐𛀑𛀒𛀓𛀔𛀕𛀖𛀗𛀘𛀙𛀚𛀛𛀜𛀝𛀞𛀟
𛀠𛀡𛀢𛀣𛀤𛀥𛀦𛀧𛀨𛀩𛀪𛀫𛀬𛀭𛀮𛀯
𛀰𛀱𛀲𛀳𛀴𛀵𛀶𛀷𛀸𛀹𛀺𛀻𛀼𛀽𛀾𛀿
𛁀𛁁𛁂𛁃𛁄𛁅𛁆𛁇𛁈𛁉𛁊𛁋𛁌𛁍𛁎𛁏
𛁐𛁑𛁒𛁓𛁔𛁕𛁖𛁗𛁘𛁙𛁚𛁛𛁜𛁝𛁞𛁟
𛁠𛁡𛁢𛁣𛁤𛁥𛁦𛁧𛁨𛁩𛁪𛁫𛁬𛁭𛁮𛁯
𛁰𛁱𛁲𛁳𛁴𛁵𛁶𛁷𛁸𛁹𛁺𛁻𛁼𛁽𛁾𛁿
𛂀𛂁𛂂𛂃𛂄𛂅𛂆𛂇𛂈𛂉𛂊𛂋𛂌𛂍𛂎𛂏
𛂐𛂑𛂒𛂓𛂔𛂕𛂖𛂗𛂘𛂙𛂚𛂛𛂜𛂝𛂞𛂟
𛂠𛂡𛂢𛂣𛂤𛂥𛂦𛂧𛂨𛂩𛂪𛂫𛂬𛂭𛂮𛂯
𛂰𛂱𛂲𛂳𛂴𛂵𛂶𛂷𛂸𛂹𛂺𛂻𛂼𛂽𛂾𛂿
𛃀𛃁𛃂𛃃𛃄𛃅𛃆𛃇𛃈𛃉𛃊𛃋𛃌𛃍𛃎𛃏
𛃐𛃑𛃒𛃓𛃔𛃕𛃖𛃗𛃘𛃙𛃚𛃛𛃜𛃝𛃞𛃟
𛃠𛃡𛃢𛃣𛃤𛃥𛃦𛃧𛃨𛃩𛃪𛃫𛃬𛃭𛃮𛃯
𛃰𛃱𛃲𛃳𛃴𛃵𛃶𛃷𛃸𛃹𛃺𛃻𛃼𛃽𛃾𛃿
𛄀𛄁𛄂𛄃𛄄𛄅𛄆𛄇𛄈𛄉𛄊𛄋𛄌𛄍𛄎𛄏
𛄐𛄑𛄒𛄓𛄔𛄕𛄖𛄗𛄘𛄙𛄚𛄛𛄜𛄝𛄞


「生𛁛𛂦゙」「生そば」

「天𛂱゚𛃭」「天ぷら」

「𛁈る𛀸」「しるこ」

\end{document}

[t-tk]

makejvf v20200412, -Oオプション追加, TeX Live r54693 完了。

[t-tk]

dvips の対応は少々苦労しましたが eca7562 で出来ているように思います。
t-tk/japanese-otf-uptex#3 で作った upexpminr-h.vf などを使ってテストしていますが、手元では vf の軽量化以前と同様の結果を得ることが出来ています。
debug 用のメッセージがオプション -d 4 (D_FONT)で出ます。
vf がpTeX用かどうかの判定をしていてpTeX以外の欧文TeX, Omegaへの動作の影響は無いはずです。また、エントリー省略のない従来のpTeX用vfの動作への影響も無いはずです。

pprescan.c の pscanpage() のルーチンに処理が回るケースを見つけることが出来ておらずそのテストが出来ていません。どういうケースがあるのかご教示いただけると助かります。scanpage.c とほぼ同じことをしているのでおそらく大丈夫であろうと思ってはいますが。

[t-tk]

dvips は私のテストでは上手く動いているようで副作用も無いはずなので TeX Live svn にコミット (r54794) しました。
まずい所があったらご指摘お願いします。

[t-tk]

TeX Live svn r57024 コミットしました。

[t-tk]

dvisvgm は原作者の方が対応してくださりv2.11としてリリースされた模様です。

[t-tk]

japanese-otf の軽量化は、今回の調査で効果の大きさが確認できましたが、今の時点では不採用として閉じることにします。
全ての検討が終わったのでここも閉じます。

[t-tk]

TeXフォーラムの投稿 dvips が otf の expert に対応していないようです。 でdvips + 軽量vfでの不具合のご指摘がありました。
dvipsの修正が必要な模様。

\documentclass[dvips,uplatex]{jsarticle}
\usepackage[expert]{otf}
\begin{document}
% あ安 % OK
安あ % NG
\end{document}

dvips(k) 2021.1
japanese-otf-uptex v0.26
で不具合確認。

[t-tk]

dvips + 軽量vf の問題、0db0c2f で直ったと思います。

[t-tk]

TeX Live svn r58812 コミットしました。

[t-tk]

変体仮名のテストの縦組み版です。
uplatex + dvipdfmx ver.20200315以降 + IPAmj明朝フォント
dvipdfmxは -l オプションを付加。

% 変体仮名のテスト、縦組み版
\documentclass[landscape]{utarticle}
\AtBeginDvi{\special{pdf:mapline uprml-v unicode ipamjm.ttf -w 1}}

\begin{document}

\section{変体仮名}

𛀂𛀃𛀄𛀅𛀆𛀇𛀈𛀉𛀊𛀋𛀌𛀍𛀎𛀏
𛀐𛀑𛀒𛀓𛀔𛀕𛀖𛀗𛀘𛀙𛀚𛀛𛀜𛀝𛀞𛀟
𛀠𛀡𛀢𛀣𛀤𛀥𛀦𛀧𛀨𛀩𛀪𛀫𛀬𛀭𛀮𛀯
𛀰𛀱𛀲𛀳𛀴𛀵𛀶𛀷𛀸𛀹𛀺𛀻𛀼𛀽𛀾𛀿
𛁀𛁁𛁂𛁃𛁄𛁅𛁆𛁇𛁈𛁉𛁊𛁋𛁌𛁍𛁎𛁏
𛁐𛁑𛁒𛁓𛁔𛁕𛁖𛁗𛁘𛁙𛁚𛁛𛁜𛁝𛁞𛁟
𛁠𛁡𛁢𛁣𛁤𛁥𛁦𛁧𛁨𛁩𛁪𛁫𛁬𛁭𛁮𛁯
𛁰𛁱𛁲𛁳𛁴𛁵𛁶𛁷𛁸𛁹𛁺𛁻𛁼𛁽𛁾𛁿
𛂀𛂁𛂂𛂃𛂄𛂅𛂆𛂇𛂈𛂉𛂊𛂋𛂌𛂍𛂎𛂏
𛂐𛂑𛂒𛂓𛂔𛂕𛂖𛂗𛂘𛂙𛂚𛂛𛂜𛂝𛂞𛂟
𛂠𛂡𛂢𛂣𛂤𛂥𛂦𛂧𛂨𛂩𛂪𛂫𛂬𛂭𛂮𛂯
𛂰𛂱𛂲𛂳𛂴𛂵𛂶𛂷𛂸𛂹𛂺𛂻𛂼𛂽𛂾𛂿
𛃀𛃁𛃂𛃃𛃄𛃅𛃆𛃇𛃈𛃉𛃊𛃋𛃌𛃍𛃎𛃏
𛃐𛃑𛃒𛃓𛃔𛃕𛃖𛃗𛃘𛃙𛃚𛃛𛃜𛃝𛃞𛃟
𛃠𛃡𛃢𛃣𛃤𛃥𛃦𛃧𛃨𛃩𛃪𛃫𛃬𛃭𛃮𛃯
𛃰𛃱𛃲𛃳𛃴𛃵𛃶𛃷𛃸𛃹𛃺𛃻𛃼𛃽𛃾𛃿
𛄀𛄁𛄂𛄃𛄄𛄅𛄆𛄇𛄈𛄉𛄊𛄋𛄌𛄍𛄎𛄏
𛄐𛄑𛄒𛄓𛄔𛄕𛄖𛄗𛄘𛄙𛄚𛄛𛄜𛄝𛄞


「生𛁛𛂦゙」「生そば」

「天𛂱゚𛃭」「天ぷら」

「𛁈る𛀸」「しるこ」

\end{document}

[t-tk]

和文vf の fallback について、若干の機能拡張をしたいと思います。

「MAPFONTで指示されているfont IDの一番若いものがJFMであるとき、要求されたコードポイントが明言されていな場合は，それが最小の font ID に属し，かつそのコードポイントそのものを出力する」『文字コードを維持したまま、最初のJFM のフォント名を、かつJFMのchar_type 0番にメトリックスを割り当てる』
とこのIssueの冒頭に書きました。
その拡張として、

1. JFMではなく、「JFM風に使いたいOFM」の場合も同様にする
2. 『文字コードを維持したまま、最初のJFM/OFM のフォント名かつJFM/OFMでの同じ文字コードのメトリックスに、メトリックスを割り当てる』

の二つです。

(1)は、JFMよりも優先でOFMが読み込まれる場合があり、その時にもfallback機構を使いたいから、
(2)は、JFMのchar_type 0番ではなく、fallback先のJFM/OFMで規定されている文字幅にすることで、半角カナやCIDの1/2,1/3,1/4幅などにも対応可能にしたいから、です。

Ref.
[dvips] pTeXの和文用TFM(JFM)をOFMに優先させる?
otf-cjXX-X.ofm は何のため？

dvipdfmx, dvips は期待通り動いているようなので、TeX Live svnにコミットする方向で考えています。

[t-tk]

dvipdfmx: TeX Live svn コミット済み r66965
dvips: TeX Live svn コミット済 r66966

dvisvgm: submitted a request to the dvisvgm repo at github.
Virtual font fallback to OFM for pTeX

[t-tk]

Support by dvisvgm have done:
mgieseki/dvisvgm@2ab9ee2

my tests:
t-tk/texlive-source@27ac1f7

ここは閉じます。