JLReq TF Meeting notes draft フォント分科会 5/18

こちらは昨日のミーティングノートです。

––––––––––––––––––––––––––––––––––––––––
JLReq TF Meeting notes draft フォント分科会 5/18

背景
文字の縦書き字形には実装による不統一があり、電子書籍の作成などで課題になっている。また、約物間の半角詰めをOSレベルで実現するためのテーブルが提案されている。これらの機能の実現にはフォントとレイアウトが協調して動く必要があり、つまりオープンな仕様が必要である。フォントとレイアウトエンジンとの間の問題点を理解するため、フォントに知識のある人を招いてフォント分科会を作った。

第一回 3/30 のミーティングで村田さんの提起した縦書き字形の問題を議論した。第二回 4/20 のミーティングでは CITPC からのメンバーが加わり、石井さんの提案による約物間の半角詰めをOSレベルで実現するための OpenType テーブル chws について議論した。今回のミーティングでは、chws テーブルでカバーされない約物半角詰めについて議論する

今日のゴール
chws テーブルでカバーされない約物半角詰めをサポートする方法のオプション、フォントに何が必要かを理解する

参加者
CITPC
田原恭二さん（凸版印刷）
中内智浩さん（モリサワ）
水野昭さん（イワタ社長さん）
Masao Kyo さん（漢字のお名前、所属？）
宮田愛子さん（大日本印刷、秀英体開発室）

W3C / JLReq
石井さん
小林さん
下農さん
田嶋さん
Nat McCully さん
敏先生
村上さん
木田泰夫

議論
イントロダクション（木田）
前回の議論から、フォントをバージョンアップするのはフォント名を新しくした商品を出す必要があるなど、大きなコストが伴うことがわかった。ゆえフォントベンダーさんに対しては、小さな改良提案をバラバラに出すのではなく、ひとまとまりとして次世代のフォントはこうあって欲しい、と提案すべきかと思われる
その意味で、約物の詰めで chws でカバーできないケースについて検討しておきたい
同時に、OSやデバイスにバンドルされる場合など、限定された場所で短期にできる改良もある。そちらの方向も重要
OSバンドルやウェブフォントのベンダーの場合細かい単位でアップデートできる（石井）

前提として Shaping engine の説明（石井）
事実上 Shaping engine は三つ
Google の halfbuzz（Android/Chrome/Firefox/Linuxが使う）
Apple の CoreText（iPhone/iPad/Mac が使う）
Microsoft の DirectWrite（Windows）
halfbuzz は一つのスタイルごとに処理。OpenType ライブラリに近い
CoreText / DirectWrite は行単位・段落単位の処理も可能になっている
この違いにより、エンジンでやれること、アプリケーションがやること、の分担が違ってくる

行頭行末は二つの可能なアプローチがある（石井）
一つはアプリケーションが行頭文字行末文字に対して halt を適用する方法。欧文で optical bounds の処理をするケースに似ている。この場合は halt があれば処理が可能で、行頭行末2文字だけなのでパフォーマンスへの影響も許容範囲
もう一つは、例えば行頭に全角空白を一時的に入れて chws を適用するといったコンテキストを使う方法

マルチフォントはもっと厄介（石井）
Run が別れるので、前のテキストの後端、後ろのテキストの前端を halt で全部削った後スペースを入れるという処理になる。入れるスペースの量を決める必要がある

そもそもどうすべきかが不明確（石井）
フォントサイズが異なる、筆文字で半角にできない、70%にはできる、といった場合にどういうような処理を行う必要があるか。日本語組版として提示すべきでは
chws での処理（一つのスタイル内）の場合は空きをフォントデザイナが指定できるので、二分とは限らないデザインの自由度がある。ここは chws の良い点の一つ
二分だったのは活字組版の制限（敏先生）
JIS X 4051 の規定は参考にならない。そのようなケースについての記述があるが、その当時の例を前提に書いてあるので。平均ととると言う方法、大きい方が勝つという方法が考えられるが、大きい方が勝つという処理が良いと思う（敏先生）
JLReq で何か文書化したい。GitHub 作って（木田）
考えをまとめてメールで流す（敏先生）
行書などプロポーショナルで組む物は、全角ベースとは別の考え方が必要なのではないか（Nat）
昔からプロポーショナル問題はある。活字時代に鍵括弧やパーレン、字形が2分、空きが2分、だったが、2分は開きすぎだという議論は昔からあった。もしくは鍵括弧を全部四部とか。活字では難しかったからやっていなかった。パーレンについては、欧文が1/3だった。というのを２分の活字に入れ込んで組んだというような事例はあった（敏先生）
行頭行末をそろえてしまった時点で、約物を詰めるか、調整を避けるのを優先するか、という話が出てくる（敏先生）
前から言っている、日本語もラグでいいのではないか？というのに近づいている（木田）
認めていいとは思うが、習慣の問題でもあるので。欧文も昔は full justfy が主流だったものが、今は圧倒的に不ぞろいになっている。日本語でもいずれなってくるのではないか？（敏先生）

chws でのレイアウトのレビュー結果（敏先生）
コーテーションマークについてメールを流した

結論として、約物詰めのためにはフォントに chws と halt があれば ok（木田）
ただし、Nat が提起している問題をちゃんと理解したい。https://github.com/w3c/font-text-cg/issues/45 <https://github.com/w3c/font-text-cg/issues/45> にコメントして
もっとアドバンスドで足らない可能性はあるとは思う（石井）
chwsはいまの定義だと他の機能と併用できない（Nat）
これもどんな場合に困るのかぜひ詳しく

文字情報技術促進協議会から参加してくださっている方々との議論・コミュニケーションの方法（木田）
JLReq TF のメールリストは話題が組版全般。もし興味があればぜひ参加して欲しい。私まで連絡を
特定の議論は W3C github issueでやるという手がある。また、CITPC の GitHub や MS Teams でやるオプションもある
全体に参加という希望者がいるかもしれないが、フォントの話をする際にバックグラウンドの分かりにくさというのがある気もする
バックグラウンドについて丁寧に説明する工夫をしたい（木田）

次回
6/15 10am JST。Nat が用意してくれるデータをもとに、縦横問題に戻る
––––––––––––––––––––––––––––––––––––––––––––––––––––