[makejvf] GLUE/KERN テーブル読み取りの改良

[aminophen]

r44817 で「GLUE/KERN テーブルを読み取って自動で MOVERIGHT すべき値（＝ write.c で言うところの skip）を決定する」というルーチンを入れました（-e オプションで有効化）。互換性については #16 に書いた通りです。

現在のルーチンは， TYPE が 0～255 に収まっている前提で書いています。 大概のケースで収まっていると想定したためですが，当然万全ではないです。第1バイトが 0x80 以上だったら… のところは本来 unsigned で読み出さないといけないのですがサボっていますので，忘れないように TODO として issue にしておきます。

訂正：よく見ると現状の JFM では TYPE の上限は 255 ですね。ということは問題ない？ #8 で増えた GLUEKERN サイズに対応しているかどうかだけ確認しておきます。

[aminophen]

r44827 で enhanced mode における GLUE/KERN テーブルの利用法を改善しました。（r44828 で svn add し忘れた version.h を追加，r44829 で ll + w + rr = zw に丸め誤差を 1 だけ許容）

version 20170716 では

• ある文字 C の字幅 w によらず，
  • (TYPE 0 の文字) の後に C が来る時のグルーを rightamount に保持
  • 文字 C を rightamount だけ左にシフト

としていましたが，

version 20170717 ではノーマルモードの挙動（case default のブロック）に近づけるため

• ある文字 C の字幅 w が zw でない場合のみ，
  • (TYPE 0 の文字) の後に C が来る時のグルーを ll に保持
  • C の後に (TYPE 0 の文字) が来る時のグルーを rr に保持
  • C の字幅 w に対して
    • ll + w + rr = zw が成り立つ場合，文字 C を ll だけ左にシフト
    • それ以外の場合（うち半角カタカナは例外），文字 C を (zw-w)/2 だけ左にシフト

としました。これでも uptex-fonts のリビルドはバイナリ一致しました。

[aminophen]

上記の 20170716 → 20170717 の改良を加えた理由は abenori/jlreq の make でした。この改良を入れないと U+2010, U+2013, U+30a0 の結果が意図しないものになったからです。

なお，abenori/jlreq の make に新しい makejvf enhanced mode を使った結果，U+00AB, U+00BB の扱いを改良することに成功したと思います（参考： abenori/jlreq#10 ）。 texjporg/uptex-fonts#2 で話題になった U+00B7 と似ていますね。

[aminophen]

#8 で増えた GLUEKERN テーブルの上限に対応できていなかったことが判明しました。ただ，LIGKERN テーブルまたは GLUEKERN テーブルのサイズが 256 以上 MAX_LIG_STEPS 以下の場合にどのバイトが何を意味するのかというドキュメントが見つかっていません。

いくつか人工的に作ってみた例では

https://gist.github.com/aminophen/157ecb92505dcee84ea7022f474e4ce3

のパッチで動くような気がしますが，「読み取った byte が 254 なら…」とハードコードしている部分は良く理解できていません。ほかにも漏れがあるかもしれないので，JFM に詳しい方教えてください。

[t-tk]

すでにご存じかと思う点を含め、私の考えを書いておきます。間違っているかもしれません。

以前はASCII MWさんのサイトにJFMの公式の解説がありました。
サイト自体がなくなってしまいましたが、internet archiveで http://ascii.asciimw.jp/pb/ptex/ を検索するとまだ読めます。
「JFMファイルの構造」に詳しい仕様が記載されています。

LIGKERN テーブルまたは GLUEKERN テーブルのサイズが 256 以上 MAX_LIG_STEPS 以下の場合

上記「JFMファイルの構造」の記載内容との関係が理解できていません。
JFMの各テーブルの上限は、実質、JFM冒頭7ワードで宣言できる数値の上限(半ワード=2バイト)で決まっていると思います。テーブルのサイズの上限はとても大きいが、「256 以上 MAX_LIG_STEPS 以下の場合」のような場合分けはJFMの仕様上は無いように見えます。

[aminophen]

ASCIIMW のサイトの内容は，texdoc jfm と同じと思います。GLUEKERN テーブルのサイズが 256 から 32510 に拡張されたのは issue 8 の時なので，巨大な LIGKERN の仕様はおそらくアスキーとは無関係なところで定義され，それがたまたま GLUEKERN にも流用され，使えるようになっているものと思います。

[aminophen]

具体的には，jfm.pdf にある

gluekern プログラムが gluekern[remender] からに収めれれていることを示す。

の「プログラム」というのがあまり明確でありません。jfm.pdf でいうところの次章の

第 1 バイト 128 以上の時、このワードでプログラム終了。

でも「プログラム」と書かれていますが，この「プログラム」が直接＝一段階で「glue または kern テーブルの何番目を読めば良いかというインデックス」を指し示す場合と，二段階を要して「そのインデックスを得るために必要なインデックス」を指し示す場合があるように私には見えています。GLUEKERN が巨大（256 以上 32510 以下）だと，charinfo テーブルに収まりきらなくなって二段階必要…ということみたいですが，そのパースの仕方が（コードとしてではなく）ドキュメントとして見つからないような気がします。

[zr-tex8r]

ふと思い出した。

dvistd – A standard for DVI drivers

コレのD.2節にTFMの仕様が書いてあって、そこで巨大LIGKERNの話も載っていますね。

[aminophen]

dvistd

存在すら知りませんでした… ありがとうございます。後で確認します。

[aminophen]

これは #47 を以って動作確認できたので完了とします。