New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[makejvf] set3 と非漢字用 TFM の組み合わせで dvipdfmx:fatal: VF file ended prematurely. #16

Closed
aminophen opened this Issue Jul 10, 2017 · 26 comments

Comments

Projects
None yet
3 participants
@aminophen
Member

aminophen commented Jul 10, 2017

$ makejvf -i -u jis -3 -K fuga `kpsewhich upjisr-h.tfm` hoge

として upjisr-h.vf(uptex-fonts に入っている本物とは違う)と hoge.tfm と fuga.tfm を作って

%#!ptex2pdf -l -u
\documentclass{article}
\AtBeginDvi{\special{pdf:mapline hoge UniJIS-UTF16-H ipaexm.ttf}}
\AtBeginDvi{\special{pdf:mapline fuga UniJIS-UTF16-H ipaexg.ttf}}
\begin{document}
アイウエオkanji漢字
\end{document}

のようにすると,dvipdfmx 実行時に

dvipdfmx:fatal: VF file ended prematurely.

が出て PDF を作れません。set3 を使わない(-3 なし)では正常でした。

https://twitter.com/munepixyz/status/434130455684603905

@aminophen aminophen changed the title from set3 と非漢字用 TFM の組み合わせで dvipdfmx:fatal: VF file ended prematurely. to [makejvf] set3 と非漢字用 TFM の組み合わせで dvipdfmx:fatal: VF file ended prematurely. Jul 10, 2017

@aminophen aminophen added the bug label Jul 10, 2017

@zr-tex8r

This comment has been minimized.

zr-tex8r commented Jul 11, 2017

765行目あたりのコレが問題ありそうです。

	if (kanatfm || code>=0x10000)
		cc=4;
	else
		cc=3;

kanatfm だと(fnt_num_1fnt_num_2必ず入るので)1バイト増える、code>=0x10000だと(set2でなくset3になるので)1バイト増える、だから両方成立する場合はcc=5;でないといけないはずです。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 11, 2017

おお! ということは

	cc = 3;
	if (kanatfm) cc += 1;
	if (code>=0x10000) cc += 1;

ですかね。似たコードが何箇所もあるのでいろいろテストしてみます。 → 他の部分と似たコードにしたいので

			if (kanatfm)
				cc=4;
			else
				cc=3;
			if (code>=0x10000)
				cc+=1;

にします。

@zr-tex8r

This comment has been minimized.

zr-tex8r commented Jul 11, 2017

kanatfmについて気になったことがあるので書いておきます。)

仮名用TFMの分割の処理で、「仮名だと見なす」符号値の上限は以下のようになっています。

  • JISモード: 0x2576 〈ヶ〉
  • UCSモード: 0x30F6 〈ヶ〉

JISの方は(6区ギリシャ文字・7区ロシア文字・8区罫線素片は“どうでもよい”と考えると)「漢字(16区以降)以外は全部仮名」と見なしていることに相当します。

一方、Unicodeでの0x30F6あたりを見てみると:

30A0..30FF; Katakana                           ←30FFまで埋まっている
3100..312F; Bopomofo                           (日本語とは無関係)
3130..318F; Hangul Compatibility Jamo          (日本語とは無関係)
3190..319F; Kanbun                             (日本語とは無関係)
31A0..31BF; Bopomofo Extended                  (日本語とは無関係)
31C0..31EF; CJK Strokes                        (日本語とは無関係)
31F0..31FF; Katakana Phonetic Extensions       ←これは明らかに仮名
3200..32FF; Enclosed CJK Letters and Months    ←和文の記号類が含まれる
3300..33FF; CJK Compatibility                  ←和文の記号類が含まれる
3400..4DBF; CJK Unified Ideographs Extension A ←これ以降は漢字と思ってよい

なので、「0x30F6まで」だと「漢字以外は全部仮名」にはなっていないことになります。

多分「漢字以外は全部仮名」に一番近いのは「0x33FFまで」なんでしょうけど、これを採用すると「状況が悪化する」ケースが発生すると思うので、その変更はためらわれます。

一方で、仮名詰めの実装コードを見ると、そこでは「小書き片仮名ク」(0x31F0)などの「Katakana Phonetic Extensions」の文字を明らかに仮名と扱っています。そうすると、仮名TFMの処理でこれらが仮名でないとされるのは矛盾であり“バグ”といえるかも知れません。これの“修正”として「0x31FFまで」に変更することは考慮の余地があると思います。実際にこの変更で「状況が悪化する」ことはまず無いと思われます。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 11, 2017

漢字以外は全部仮名

というより,引数なしで makejvf を実行した時のヘルプに「-K <TFMfile> 非漢字部用に作成する…」と書かれているので,C source の kanatfm という字面とは違って「漢字以外は全部仮名とみなしている」ではなく,少なくとも JIS モードは本当に「非漢字」を意図しているはずです。

UCS モードは確かに kanatume と kanatfm が矛盾しているので直したいですね。非漢字部ということにこだわると 0x33FF までにすべきですが,悪化するケースがどのくらい重要なのか…?

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 11, 2017

両方成立する場合はcc=5;でないといけない

r44775 でコミットしました。kanatfm の範囲はまだ考えていません。

@zr-tex8r

This comment has been minimized.

zr-tex8r commented Jul 12, 2017

少なくとも JIS モードは本当に「非漢字」を意図しているはずです。

仕様上「非漢字」だとすると、「0x33FFまで」にするのもアリかと思います。(オプションで可変にしておけば、“前のまま”が欲しい人も対処できますしね……。)

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 12, 2017

順に見ていきます。

[1] 0x30F6 で kanatfm の範囲が終わっているのは「明らかなバグ」と思いますし,異論は出ないでしょう。0x30FF までは必ず kanatfm に含めるということで決定とします。

(添付画像を見れば,現状の 0x30F6 で終わった結果は明らかに違和感を感じるはず)

$ makejvf -u jis -K ukana `kpsewhich upjisr-h.tfm` ukanji
\documentclass{article}
\AtBeginDvi{\special{pdf:mapline ukana UniJIS-UTF16-H ipaexm.ttf}}
\AtBeginDvi{\special{pdf:mapline ukanji UniJIS-UTF16-H ipaexg.ttf}}
\begin{document}
4E00	一	丁	丂	七	丄	丅	丆	万	丈	三	上	下	丌	不	与	丏\par
4E10	丐	丑	丒	专	且	丕	世	丗	丘	丙	业	丛	东	丝	丞	丟\par
4E20	丠	両	丢	丣	两	严	並	丧	丨	丩	个	丫	丬	中	丮	丯\par
4E30	丰	丱	串	丳	临	丵	丶	丷	丸	丹	为	主	丼	丽	举	丿\par
4E40	乀	乁	乂	乃	乄	久	乆	乇	么	义	乊	之	乌	乍	乎	乏\par
4E50	乐	乑	乒	乓	乔	乕	乖	乗	乘	乙	乚	乛	乜	九	乞	也\par
4E60	习	乡	乢	乣	乤	乥	书	乧	乨	乩	乪	乫	乬	乭	乮	乯\par
4E70	买	乱	乲	乳	乴	乵	乶	乷	乸	乹	乺	乻	乼	乽	乾	乿\par
4E80	亀	亁	亂	亃	亄	亅	了	亇	予	争	亊	事	二	亍	于	亏\par
4E90	亐	云	互	亓	五	井	亖	亗	亘	亙	亚	些	亜	亝	亞	亟\par
4EA0	亠	亡	亢	亣	交	亥	亦	产	亨	亩	亪	享	京	亭	亮	亯\par
4EB0	亰	亱	亲	亳	亴	亵	亶	亷	亸	亹	人	亻	亼	亽	亾	亿\par
4EC0	什	仁	仂	仃	仄	仅	仆	仇	仈	仉	今	介	仌	仍	从	仏\par
4ED0	仐	仑	仒	仓	仔	仕	他	仗	付	仙	仚	仛	仜	仝	仞	仟\par
4EE0	仠	仡	仢	代	令	以	仦	仧	仨	仩	仪	仫	们	仭	仮	仯\par
4EF0	仰	仱	仲	仳	仴	仵	件	价	仸	仹	仺	任	仼	份	仾	仿\par
3000	 	、	。	〃	〄	々	〆	〇	〈	〉	《	》	「	」	『	』\par
3010	【	】	〒	〓	〔	〕	〖	〗	〘	〙	〚	〛	〜	〝	〞	〟\par
3020	〠	〡	〢	〣	〤	〥	〦	〧	〨	〩	 〪	 〫	 〬	 〭	 〮	 〯\par
3030	〰	〱	〲	〳	〴	〵	〶	〷	〸	〹	〺	〻	〼	〽	〾	〿\par
3040		ぁ	あ	ぃ	い	ぅ	う	ぇ	え	ぉ	お	か	が	き	ぎ	く\par
3050	ぐ	け	げ	こ	ご	さ	ざ	し	じ	す	ず	せ	ぜ	そ	ぞ	た\par
3060	だ	ち	ぢ	っ	つ	づ	て	で	と	ど	な	に	ぬ	ね	の	は\par
3070	ば	ぱ	ひ	び	ぴ	ふ	ぶ	ぷ	へ	べ	ぺ	ほ	ぼ	ぽ	ま	み\par
3080	む	め	も	ゃ	や	ゅ	ゆ	ょ	よ	ら	り	る	れ	ろ	ゎ	わ\par
3090	ゐ	ゑ	を	ん	ゔ	ゕ	ゖ			 ゙	 ゚	゛	゜	ゝ	ゞ	ゟ\par
30A0	゠	ァ	ア	ィ	イ	ゥ	ウ	ェ	エ	ォ	オ	カ	ガ	キ	ギ	ク\par
30B0	グ	ケ	ゲ	コ	ゴ	サ	ザ	シ	ジ	ス	ズ	セ	ゼ	ソ	ゾ	タ\par
30C0	ダ	チ	ヂ	ッ	ツ	ヅ	テ	デ	ト	ド	ナ	ニ	ヌ	ネ	ノ	ハ\par
30D0	バ	パ	ヒ	ビ	ピ	フ	ブ	プ	ヘ	ベ	ペ	ホ	ボ	ポ	マ	ミ\par
30E0	ム	メ	モ	ャ	ヤ	ュ	ユ	ョ	ヨ	ラ	リ	ル	レ	ロ	ヮ	ワ\par
30F0	ヰ	ヱ	ヲ	ン	ヴ	ヵ	ヶ	ヷ	ヸ	ヹ	ヺ	・	ー	ヽ	ヾ	ヿ\par
\end{document}

20170712-upkanjikana-0

[2] さて,どこまでを kanatfm に含めるかですが,uniblock.c が「その文字が日本語かどうか」という方針を
明記したファイルなので参照します。(これは Adobe の cid2code.txt を基にしたもの)

ZR さんのコメントで

3190..319F; Kanbun                             (日本語とは無関係)

と書かれているのですが,これは ENTRY_J すなわち日本語として扱われています。

3190	㆐	㆑	㆒	㆓	㆔	㆕	㆖	㆗	㆘	㆙	㆚	㆛	㆜	㆝	㆞	㆟\par

これは返り点とかの記号なのだと思いますが,見た目が「漢字に相当似ている」ので悩みますが,「非漢字」というアスキーの仕様になるべく近づけた方が良いと私は思うので,「0x33FFまで」を支持します。

(オプションで可変にしておけば、“前のまま”が欲しい人も対処できますしね……。)

上の「明らかなバグ」があることを加味すると,文字通り“前のまま”は誰も望まないと思ってしまいます。面倒なので「オプションで可変に」は考えなくて良いのではと思います。

@zr-tex8r

This comment has been minimized.

zr-tex8r commented Jul 12, 2017

そうですね。現在の値の0x30F6は、何かの意図があったわけでなく「考慮不足のためのバグだった」で確かですね。そうすると、妥当な値は、「非漢字」として最適な0x33FFしかないような気がしてきました。0x31FFだと、「2xxxと3xxxで扱いが異なる」ことの合理的な説明がつかなそうです。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 12, 2017

「非漢字」として最適な0x33FF

r44778 でコミットしました。(メモ:これでこの issue は完了のつもり)

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 13, 2017

あっ,半角カタカナとか,まだ非漢字のブロックが残っていますね。 この辺の扱いはどうしましょうか?

@zr-tex8r

This comment has been minimized.

zr-tex8r commented Jul 13, 2017

そうですね、今の方針だと厳密な「Unicodeの漢字」の範囲を使ったほうがよいですね。

(以下のものが漢字、それ以外が非漢字)

  • 3400..4DBF
  • 4E00..9FFF
  • F900..FAFF
  • 20000..2FFFF
@aminophen

This comment has been minimized.

Member

aminophen commented Jul 13, 2017

そうすると,write.c で分岐条件を複雑化するより,uniblock.c で「漢字は J,非漢字は j」みたいなフラグを立てておいたほうが効率がいいしバグも防げますね。

→ 漢字は英語で時々 Han Characters なので,フラグ名は"H"にしようかな…とか考えていたけど,それよりも struct ublock のサイズを増やしたほうが GCJKH とか GCJH とか数値を uniblock.h でたくさん定義しなくて良いから楽ですね。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 13, 2017

半角カタカナ -H オプションと非漢字 -K オプションの併用って,そもそも今までサポートされていなかったっぽいですね…(もちろん -K を使わずに -H だけ使った場合は正常。)

挙動が変わって困るどころか,変えないと困るケースみたいです。

$ makejvf -i -u jis -H -K ukana `kpsewhich upjisr-h.tfm` ukanji
\documentclass{article}
\AtBeginDvi{\special{pdf:mapline ukanji UniJIS-UTF16-H ipaexg.ttf}}
\AtBeginDvi{\special{pdf:mapline ukana UniJIS-UTF16-H ipaexm.ttf}}
\begin{document}
[これは漢字とカタカナです。]
\end{document}

20170713-hankana-0

で,今度は「厳密な『Unicodeの漢字』の範囲を使う」というパッチを作ってみました。なお,半角カタカナのところのコードを kanatfm 対応にする作業はまだなので,現状ではまだ半角カタカナの配置が変なままです。(直し方がまだよくわからない…)

20170713-hankana-1

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 13, 2017

半角カタカナ -H オプションと非漢字 -K オプションの併用って,そもそも今までサポートされていなかったっぽいですね…

現状ではまだ半角カタカナの配置が変なまま

あ,これって「PS 用の TFM が不正だから」のような気がしてきました。要するに「ナントカ-hk.tfm を自前でコピーするなりして使いましょう」な話ですかね? うーん…

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 13, 2017

「makejvf に -H オプションを付けたのに,生成する PS 用の非漢字部 TFM が半角カタカナに非対応」なのって,なんだか不自然だと思うのですが,そうなっている理由ってあるのでしょうか?

@t-tk

This comment has been minimized.

Collaborator

t-tk commented Jul 13, 2017

makejvfの-Kオプションというものは、私自身は使ったことがありませんし、テストで走らせたことすらありません。「明らかなバグ」「考慮不足」と言われると、ちょっと違和感ありますし、内心穏やかでありません。表現には配慮していただきたい。
-uオプションと-Kオプションの組合せは、私の感覚では「未実装」です。

何かの意図があったわけでなく「考慮不足のためのバグだった」

0x30F6 が現れたのは、おそらく機械的にJISのコード値をUnicodeに置き換えて出てきたためだと思います。「考慮不足」というより「仕様検討すらしていない」が正しいです。

「makejvfの機能をフルにUnicode化してupTeXで使えます」という水準までは達していないのは事実だと思う反面、今まで不具合報告が10年以上もなかったことを考えると必要度が相当に低い機能なのだと思います。必要のない機能に貴重な開発リソースを割くことは私には出来ません。
必要に応じて整備していくことには異論はないですし、自然で便利な仕様で動くようになる方向に開発するのは結構だと思いますし、それを進めてくださるのはありがたいです。
makejvfに限らず、この手の「未実装」は他にもまだまだあるかも、です。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 13, 2017

ちょっと違和感ありますし、内心穏やかでありません。表現には配慮していただきたい。

気を悪くされたのであれば申し訳ありません。

私の経験として,ここ一年間「何かの挙動を変えると,変えた後に必ず互換性至上主義の方が現れて,変えるなという主張が現れる」ことに悩まされることが多くありました(そして今も現在進行形で同じ状況にいて,不快な思いをすることがあります)。そこで,いかなる小さな変更であっても,事前に「それが明記された仕様(=ヘルプメッセージなど)に反する=バグである」と認定できるかどうかが自分の中のゴーサインになっています。変えた後に信じられん,戻せと言われると嫌な思いをする(した)からです。

仕様検討すらしていないケースがあることも承知しております。バグ認定も特定個人へ向けたものではないですし,使っている人・使いたいと思う人(例えば私など)が可能な範囲でサポートすれば良いと考えています。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 13, 2017

「バグ」という表現ですが,ずっと私の中でもどう表現すべきか悩んでいます。自分の中で一番近いのは「著者の意図しない挙動」なのですが,「意図」という表現は曖昧さを含むので(コードを読んでいる人の主観が入る余地がある),使うのをむしろ避けるようにしています。そうすると適切な表現が出てこないので,結局妥協して「バグ」と呼んでいます。もちろんこの表現の捉え方は人それぞれなのは重々承知なのですが…

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 15, 2017

20170715-makejvf-hankana.patch を適用すれば,「半角カタカナで使われる PS 用 TFM」が適切に作られるはずです。 → r44804

@t-tk

This comment has been minimized.

Collaborator

t-tk commented Jul 15, 2017

TeX Liveへのコミットありがとうございます。ここのtex-jp-buildも追いつきました。

意図はおおむねご理解いただけたと思っていますが、もう少しだけ。
「バグ」という言葉を“言葉狩り”するつもりはありません。
よく言う「バグか仕様か」の二者択一の言い方では今回の件は「バグ」に分類されると思いますし、
ちょっと前に見つかったmendexやupbibtexの不具合も「バグ」だと思います。
しかし、今回の件では「バグ」でも「仕様」でもなく「未実装」だという思いがあり、「明らかなバグ」「考慮不足」のような表現で力強く“断定”してほしくないなあ、という感じです。

ところで、バージョン番号をそろそろ変えませんか?

私としては今後以下をしたいと思っています。

  • Unicode 10.0.0のテーブルへ更新
  • cid2code.txtを新しくして ENTRY_* を更新
  • vfに書き込む文字の集合を外部ファイルで与えられるような機能追加

cid2code.txtは最近更新が頻繁なので、もう少し待ったほうがいいのかもしれません。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 15, 2017

力強く“断定”してほしくないなあ、という感じです。

承知しました。

ところで、バージョン番号をそろそろ変えませんか?

同意します。upTeX パッチが行き渡って十分時が経っているので,-u1.22 のバージョンは消して 20170715 のように日付に一本化するというのはどうでしょう?

私としては今後以下をしたいと思っています。

良いと思います。「vfに書き込む文字の集合を外部ファイルで与えられるような機能追加」は,この前私が試作した「各文字の右シフト量・下シフト量を外部ファイルで与えられるような機能追加」と同様に,何かわかりやすい文法を決める必要がありますね。シフト量は先日

MOVE <code> <right> <down>

というのを考えていましたが,文字集合はどうしましょうか。

@t-tk

This comment has been minimized.

Collaborator

t-tk commented Jul 16, 2017

長くなってきたので入力ファイルの件は別にissueを立てました。

バージョン番号は今 "ver.1.1a-u1.22" ですがメインの番号も変えて
"ver.2.0-20170716" 1日2回以上更新した場合は番号更新なし
とかでどうでしょう。
あと、そろそろCOPYRIGHT にコミュニティ、もしくは個人の名をいれた方が良いかもしれません。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 16, 2017

メインの番号も変えて

メイン番号は付けずに日付だけで良いのでは,と思っています。 #14 と同じ理由ですが,v2.0 から v2.1 にするのはどんな場合かとか,小さなバグフィックスなのに v2.x から v3.x にするのを躊躇うという非本質的な理由で更新が滞るのは避けたいからです。

COPYRIGHT は upLaTeX と同じような表示が良いと思います(アスキー + ttkさん + texjporg)。

@t-tk

This comment has been minimized.

Collaborator

t-tk commented Jul 16, 2017

#14 について、停滞しているのは私が意見表明していないことが大きいかもです。済みません。気にはなっているのですが。

makejvf の場合は、「バージョン番号を他のソフトや機能から呼び出して制御を変える」みたいなことがないと思われるので、認識しやすければ何でもよいし、「小さなバグフィックスなのに v2.x から v3.x にするのを躊躇う」みたいなことは、開発者・メンテナーの腹次第だと思います。
なので、日付のみでもv2.0-日付でもどちらでもよいです。

COPYRIGHTの件、同意です。更新作業はconflictのことが気になっているだけで私がしてもよいです。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 16, 2017

バージョン番号は日付のみ,COPYRIGHT は上記通り,の方向でいきたいと思います。

更新作業はconflictのことが気になっているだけで

次のコミットの際に,この辺で触れた GLUE/KERN テーブルの読み取りコードを入れようと考えています。これで従来とはルーチンが変わるので(従来の JVF 作成には全く影響しない見込み),そこでバージョン番号を新しくします。

@aminophen

This comment has been minimized.

Member

aminophen commented Jul 16, 2017

r44817 で「GLUE/KERN テーブルを読み取って自動で MOVERIGHT すべき値(= write.c で言うところの skip)を決定する」というルーチンを入れました。ただし,これは enhanced mode(勝手に名付けました)でのみ使われるルーチンで,デフォルト挙動は変化しません。

デフォルトを変えなかった理由は,min10.tfm のように「正しくない分類をしている JFM」の場合に非互換な変化が発生するためです。

min10.tfm は JIS 2146〈‘〉〜JIS 2149〈”〉と JIS 216B〈°〉〜JIS 216D〈″〉が,本来あるべき TYPE とは異なる場所に分類されています。例えば〈?〉と〈”〉が同じ TYPE,つまり幅や JFM グルーの入り方が同じというのはあまり自然ではないと思います。

(CHARSINTYPE O 4
   ・ : ; ! ´ ` ‐ ‖ | ‘ ’ 
   )
(CHARSINTYPE O 5
   ? ¨ ^ ヽ ゝ “ ” ° ′ ″ § 
   )

これをもとに自動で MOVERIGHT 量を決定すると,出来上がる min10.vf は元の min10.vf と異なるわけです。自然な分類がなされている jis.tfm の場合は,自動で MOVERIGHT 量を決定して出来上がる jis.vf は元の jis.vf と「ほぼ」バイナリ一致します(「ほぼ」というのは,最後の桁が 1 だけ違う=丸め誤差)。この違いは今のところ警告で見やすくしています。

$ makejvf -e `kpsewhich jis.tfm` rml
[Warning] Conflicting MOVERIGHT value for code 2146,
[Warning]   makejvf default:    fff84d61
[Warning]   suggested from JFM: fff84d62 <= I'll use this ...
(略)

おそらく,これで「繁体中国語用の -c オプション」は実装しなくても,-e オプションで代用可能になっていると思います。あとで uptex-fonts を新しい makejvf 20170716 でリビルドして試してみます。

同時に,この r44817 でバージョン番号を「20170716」に上げて,COPYRIGHT とヘルプメッセージを新しくしました。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment