JLReq meeting notes 3/9

JLreq TF meeting notes 3/9

ドラフトです。追加や訂正があったら教えてください。今週中に英語版を作って出します。


––––––––––––––––––––––
参加者
小林さん、Nat さん、下農さん、せつさん、田嶋さん、敏先生、村上さん、村田さん、木田

今日のミーティングのゴールは文字クラスの国際化に関して次のアクションアイテムを決める、であったが、chws テーブルの話題をきっかけにほとんどの時間をフォントの問題の議論に使った。フォントに関する問題を話し合うミーティングを開くこと、今まで議論してきた字間クラスをまとめたデータを作り、Unicode のプロパティに落とし込むことができるか調査する、というアクションアイテムを決めた。次回のミーティングは 3/30。


日本語組版に対するフォントの問題
前回（2021/1/26）の議論：
ボックスの中のどこにグリフがあるのかは本来的にフォントのみが知っていることであるから、約物を半角につめる機能はフォントが持つべきであろうという議論。また問題点として、ユーザーの手元には古い仕様のフォントがあること、そもそもフォント間の仕様がバラバラであることの問題が指摘されていた。

今回の議論：
chws は約物が連続する場合に半角を詰めてくれる。単一フォント単一サイズでの簡易的な組版に便利。問題点もあり、1) 文頭文末で働かない、2) サイズやフォントなどスタイルを跨ると動かない、3) 空け方や詰め方の調節をしたい場合には使えない、などの点が指摘された（Nat、村上）。この機能がゴールとする適応領域は簡易的な組版であろう。ゴールをはっきりさせることが重要。別な領域で障害や混乱の元にならないことが重要（小林）

応用範囲の広い低レベルの機能が必要との議論があった。例えば、無条件に半角に詰めて JIS X4051 や JLReq が前提としているような半角約物にするフィーチャー、など。根本的な問題は、フォントの中のどこにグリフがあるかわからないという点（Nat、村上）。

フォントとエンジンによって動作がバラバラで困るという問題が指摘された。組版の精緻さの違いなら良いのだが、基本的な所で異なると例えばマルチプラットフォーム・マルチベンダな電子書籍の開発に困る。例えば縦書きの際の挙動など基本的なところでバラバラである。フォントとエンジンの役割を決める必要がある。Florian の提案あり（URL?）（村田、田嶋）。

フォントの仕様について、現在 AdobeJapan-1 がある程度統一的な仕様の役割を果たしていて、多くの CID フォントは従っているが、TrueType フォントはバラバラ。また、AdobeJapan-1 が定めるのはグリフセットまでで、フィーチャーは Ken Lunde がAdobeのフォント SDK 用のデータを配布していた程度。つまり仕様的なものではない。この状態からもう一歩進めて、日本語フォントが守るべき何らかのガイドラインがあると良いのではないか（それによってフォントとエンジンの役割も見えてくるだろう）（木田）。文字情報技術促進協議会としても興味がある。関心のあるベンダーも多いので手伝えると思う（小林）（そっちの仕事だ！木田）。JLReq で問題点を明確化すれば、ガイドライン自身は別な組織が考えてくれるだろう（Nat）

JLReq TF ではとりあえず、問題点を明確化するためのミーティングを開くことを提案する。石井さんに来ていただくのは重要（木田、小林）


文字クラスの国際化
ほとんど時間がなく、1) 今まで議論してきた字間クラスをまとめたデータを作り、Unicode のプロパティに落とし込むことができるか調査する（木田、下農） 2) 次回のミーティングでは、字間以外にどのような文字クラスが必要か、どのような機能が文字による挙動の違いの影響を受けるかをレビューすること、を決めた。

次回のミーティングは3週間後の 3/30 火曜日、同じ時間。

木田