フォントにおける64Kの壁について
-
- いいね！0
小熊善之
@0guma
FontForgeでTrueTypeのcmapテーブルをいじる方法ってどうやるんだろう……。exportしていじってimportでもいいんだけど。
2012-04-17 21:16:09
小熊善之
@0guma
FontForgeのスクリプトで、Select("U+100000","U+100000")みたいに16面を指定すると、Character not foundと怒られる。[表示]→[移動]でU+100000を指定するとちゃんと飛ぶのに……。
2012-04-18 14:29:33
小熊善之
@0guma
FontForgeでも、一つのフォントファイルに作れるグリフの上限は65535なのか……。がっくし……。どうやったら65535以上のグリフを格納したフォントを作れるんだ……。
2012-04-20 12:48:12
小熊善之
@0guma
OpenTypeの規格を見る限り、UCS-4のcmap（Format 12）はGlyphIDをULONG（符号なし32bit）で指定してるから、フォントファイル内にグリフが65535以上入ることを想定しているんだと思うんだがなー。：http://t.co/S1ivDqJf
2012-04-20 15:25:38
狩野宏樹
@KAN0U
@0guma MacOSX 10.2の時だかに、glyfテーブルを連結してFormat12のCMapをつけてover 64Kのグリフにアクセスできた記憶があります (maxpのグリフ数は0xFFFFに設定)。GSUBやGPOSのインデックスが16ビットなのが面倒で放棄しましたが。
2012-04-20 15:54:51
小熊善之
@0guma
@KAN0U 仕様のあちこちにUSHORT指定が残ってて、なぜかUCS-4用のテーブルだけでULONGで指定なんですね。なぜこんな珍妙な仕様になってるんだろうか……。結局は自力でツギハギをやれるようにならんとあかんということか。
2012-04-20 16:01:02
狩野宏樹
@KAN0U
@0guma 他のテーブルもバージョンを上げて対応するつもりでとりあえずCMapだけ直してみた後、開発意欲が続かなかったんじゃないですかね。本当に困るのは多漢字の人だけですから……。
2012-04-20 19:31:37
Ken Lunde 小林剣
@ken_lunde
CJK Type Blog: ISO/IEC 14496-28:2012は出版されました。 ISO/IEC 14496-28:2012 (Composite Font Representation) just published! http://t.co/tS9oj5vB
2012-04-20 21:52:59
狩野宏樹
@KAN0U
@ken_lunde @0guma Composite Font Representationはドラフトしか見ていないのですが65535文字を超えるGSUBやGPOSは実現不可能ですよね。複数ファイルによる疑似的1フォントなので全部インストールされるとは限らない危険もありますし。
2012-04-20 22:49:31
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita @KAN0U ううむ、そんな所に落とし穴が。 > Unicodeに規定された漢字は7万を優に超えているのに、TrueType/OpenTypeフォントにおいては、1フォントに含められるグリフ数が65,535文字に限られているという困った問題
2012-04-20 19:47:59
Tomoharu Sato
@higetomo
@OrangeMorishita @KAN0U 10年前だったかな。Appleの組版だと面倒な拡張する手があったんだけど、結局OpenTypeとATTの変換しないとだしー、とか何か取り沙汰されてたのそのうちUnicodev4や携帯絵文字がでたけどグリフは手つかずだったのか。
2012-04-20 20:22:53
Tomoharu Sato
@higetomo
電子書籍やタブレット端末に絵文字とプラットフォームと表現手段が多様化したけど、グリフ（字形）の64Kの壁と互換性＋多言語組版・レイアウトには手ついてなかったのかー。10年ぶりのデジャブだけど、これも枯渇問題？
2012-04-20 20:46:44
狩野宏樹
@KAN0U
@higetomo グリフレベルの情報交換に関しては、漢字ではIVSという枠組みができて、今後の進展が見込まれます。多言語レイアウトは特にインド系文字の細々とした所はXPよりWin7のほうが正確度が上がっているようです（読めないのでよく判りませんが）。ページレベルの組版に関しては
2012-04-20 23:53:48
狩野宏樹
@KAN0U
@higetomo (続き)JIS X 4051(初版は1993年)からJLREQ(第2版が出たばかり)へと時間をかけて仕様がまとめられ、英語でも読める技術文書として公開されています。フォントの格納可能字数問題が手付かずだったのは、相対的に重要性が低い問題だったからでしょう。
2012-04-20 23:58:00
Tomoharu Sato
@higetomo
@KAN0U さん、丁寧な解説ありがとうございます。グリフレベルの情報交換、多言語レイアウト、フォント（グリフ）の格納可能字数問題と整理してくださり、すっきりしました。
2012-04-21 06:07:37
小林龍生
@tlk714
JLreqは、実装の具体的技術問題には踏み込まないのが大方針です。前書きとかに、明記してあります。RT @KAN0U: @higetomo (続き)ォントの格納可能字数問題が手付かずだったのは、相対的に重要性が低い問題だったからでしょう。
2012-04-21 09:51:47
Tomoharu Sato
@higetomo
フォントの拡張の質問は、1992年に自分が「Macintoshフォントブック」をだしたあと、しばらくして、問い合わせがきたので、うっすら記憶に残っていた。国際/多言語対応の仕組みはやっぱり気づきにくいとこがあり深いなー
2012-04-21 06:18:34
小熊善之
@0guma
@ken_lunde @KAN0U blogにもありますが、現在、Unicodeがこれだけ肥大化していますし、将来的な拡張も考えると、きちんとフォントの規格を見直した方が良いと思います。
2012-04-21 00:09:23
狩野宏樹
@KAN0U
@0guma @ken_lunde XMLで仮想フォントを記述する方法が決まっただけでアプリが個別に実装しなければならないのではあまり意味がなくて(ブラウザ実装者は、webフォントのレイヤで同じ事が実現可能だと言うでしょう)、OSのAPIが対応してくれなければ実用的でありません。
2012-04-21 10:00:04