JLReq TF meeting notes フォント分科会 4/20

遅ればせながら、一ヶ月前のミーティングのメモです。

JLReq TF meeting notes フォント分科会 4/20

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

第一回 3/30 のミーティングで村田さんの提起した縦書き字形の問題を議論した。今回のミーティングでは石井さんの提案による、約物間の半角詰めをOSレベルで実現するための OpenType テーブル chws について議論する。また今回から文字情報技術促進協議会 (CITPC) からフォントの専門家が参加する。

今日のゴール
石井さんの chws テーブルを理解する

参加者
CITPC
安藤央さん（フォントワークス）
田中さん（台湾から）
田原恭二さん（凸版印刷）
Masao Kyo さん（漢字のお名前、所属？）
水野昭さん（イワタ社長さん）
宮田愛子さん（大日本印刷、秀英体開発室）
山本太郎さん（Adobe）

W3C / JLReq
石井さん
小林さん（前半）
下農さん
せきさん（xfqさん, W3C, clreq）
田嶋さん
Nat McCully さん
敏先生
Florian Rivoal さん (W3C)
村上さん
木田泰夫

議論
自己紹介とコンテキストの説明
CITPC から数名が参加してくださったので、自己紹介
Florian が他の言語でフォントの関わる問題についていくつか紹介してくれた。必要なベースラインやメトリックが定義されていない言語がある。日本語と繁体中国語では、句読点の周りのスペースが異なる。

半角詰めに halt では不十分か？（石井さん）
halt があればアプリケーションが自分で半角詰めを実装できる。ただし halt で全て行うとパフォーマンスが悪い
また halt で問題のあるケースがあるかもしれないと Nat（https://github.com/w3c/font-text-cg/issues/45 <https://github.com/w3c/font-text-cg/issues/45>）

chws テーブルの説明（石井さん）
約物半角詰めをOSに入れたい。OS/ウェブブラウザが行う簡易な組版の中で連続約物の詰めを実現するのが目的。カスタマイズ性は低い。chws なら約物の連続する場合を高速に実行できる
サンプルページの紹介
https://kojiishi.github.io/chws/samples.html <https://kojiishi.github.io/chws/samples.html>
https://kojiishi.github.io/chws/test.html <https://kojiishi.github.io/chws/test.html>

chws テーブル質疑
プリミティブが欲しい場合は halt で大丈夫そう（木田）
chws テーブルではでカバーできないケース（木田）
行頭行末の約物半角詰め
フォントやサイズの異なる run の間の約物半角詰め
行頭で halt を使うのか、コンテキストで行くのか（つまり chws を使う？）のはこれからの議論の課題（石井）
フォントにテーブルがない場合はどうする？
JLReq に従って決め打ち？（Florian） - word は決め打ちもある（石井）
テーブルがあるかどうかどうやって見分ける？
TrueType は開けてみないとわからない。OpenType は比較的仕様がまとまっている
（結論？）

フォントの立場から
テーブルを加えるためにフォントをバージョンアップすることになるが可能か（木田）
フォントは基本的にバージョンアップはできない。印刷事故につながる。機能を加えるとしたら、別の名前で新しい製品となる（水野、山本）
微細な変更の場合は、バージョンアップでやることもある。メーカーによって方針が異なる（山本）
フォント名ではなく、構造的に何か区別がつけられる属性があると良いね（木田）
OS バンドルの場合はバージョンアップで対応（石井、木田）。Windows で古いバージョンのフォントをインストールする方法をサポートというケースがあった（山本）

電子書籍の印刷事故？
出版社は紙と同じ基準を電子書籍にも当てはめようとする。出版社が直してと言う場合には外字にするしかない（田嶋）
通常は包摂されている文字について別な文字と気にしてはいけないはず（山本）
漢字字形に対する教育。電子書籍はゆるい、ソフトウェア的、という認識、啓蒙が必要。JLReq で何か言えないか？（木田）

UTR#50 vs AJ1 の食い違い
どこかで互換性を断ち切るという考えもある（石井）
挙動の食い違いの原因は複雑。原因が、フォントとアプリケーション独自の動作の組み合わせで8類型位に分類される（山本）
ぜひ資料をシェアして欲しい（木田）次の会議までに流す資料を用意する（Nat）
AJ1とUAX#50の齟齬というところに矮小化せず、フォントが何をしてアプリケーションが何をするかというような議論をしたい（木田）

Wrap up
JLReq では問題を理解して文書化できればいいと思う（木田）
次回は 5/18 10a JST。縦横の詳細を Nat の資料ベースで
––––––––––––––––––––––––––––––––––––––––––––––––––