JLReq TF meeting notes 2025-1-28

[kidayasuo]

JLReq TF Meeting Notes – 2025-01-28

(日本語)

Attendees

atsushi, kida, murata, nat, tajima, tlk, toshi, yamashige

Agenda

• Impact of font fingerprinting prevention mechanisms
• How to detect the edge of Japanese characters for text-box-edge
• Selection and copy-paste behavior of ruby text
• How to determine relative sizes when combining Japanese and Latin fonts
• Bullet lists in vertical writing
• Necessity of multi-column layout in vertical writing
• Next meeting

Impact of font fingerprinting prevention mechanisms

One fingerprinting prevention approach, implemented in Safari, restricts access to fonts other than those preinstalled in the system—i.e., fonts installed by the user. This mechanism is currently being discussed in CSS Fonts, and if recommended, may be adopted by other browsers. Are there any implications for Japanese text?

Discussion

• Kida: Fonts like MJ+ (used for personal names in government contexts) may be affected, but since they are not typically used by the general public, they may be outside our scope. For business use, such fonts can be excluded via profiles.
• Tajima: I’m worried that data with IVS assuming the MJ+ font might circulate unnoticed.
• Kida: That's a separate issue, but it could certainly happen. However, if such data circulates unnoticed, the precision of the required glyphs would be different from what local governments require. Simply rendering according to IVS rules should be fine. But if expectations rise for the same level of precision as municipal systems, it would increase the size and development cost of Japanese fonts, which is undesirable.
• Nat: If a browser-based application depends on local fonts, it might be affected.
• Kida: It’s not an issue limited to Japanese.

Conclusion

No critical issues specifically for Japanese were identified.

text-box-edge: How to determine bounding boxes for Japanese text

Issues raised by Ishii-san regarding values used in properties like text-box-edge for Japanese text:

• [css-inline] Define how to synthesize ideographic-over and ideographic-under csswg-drafts#10850
• [css-inline] text-box-edge: ideographic and ideographic-ink should use ideographic fonts in the cascade list csswg-drafts#10928

There are two main problems: (1) how to synthesize appropriate values when the font lacks icft/icfb tables, and (2) synthesizing values from the first font in the list (typically a Latin font) results in inappropriate values for Japanese.

Useful references on how these properties work in English:

• https://developer.chrome.com/blog/css-text-box-trim?hl=ja
• https://goodpatch-tech.hatenablog.com/entry/figma-web-zure-shitteokou

Discussion

• Nat: Adobe fonts include icft/icfb. When not available, heuristics must be used—this is a shared issue across non-Latin scripts. The purpose of icft/icfb is to represent average character face—not usable for ink coverage but moderately helpful for trimming. Magazine House’s grid system uses average face size. Japanese generally doesn't align to edges. Kana fonts use virtual values.
• Kida: Should we explicitly note in the spec that this represents the average face size of Kanji?
• Prof. Satoshi: Could we consider bounding the actual rendered character?
• Nat: Calculating the glyph bounding box at runtime is costly.
• Nat: Just as x-height varies, so does face size. However, Japanese usually centers characters rather than aligning by edge or baseline.
• Nat: For fonts without data, we must calculate from sample Kanji. Non-Japanese fonts should ideally include this data too—it helps when combining fonts.
• Kida: It's unrealistic to expect non-Japanese fonts to include this. And even if they did, can we trust the values?
• Nat: In idtp/ideo cases, height usually equals point size, but the relative baseline is unclear. If Latin cap height is centered within the virtual body, we can determine the baseline (except for Hiragino). This method is only usable for J. K is inconsistent. Many Chinese fonts have large Latin glyphs.
• Toshi: The current reference character is "水" (water), but it may not be ideal. Characters like "永" (eternity) might have larger bounding boxes than average. We should consult professional font designers to select appropriate reference characters.

Conclusion

• For idtp/ideo: Assume Latin cap height in Japanese fonts is vertically centered in full-width (point size), and use that to compute values.

• For icft/icfb: Use bounding boxes of selected reference Kanji.

• Use the first Japanese font found in the font list, not the first font overall.

• todo: Kida to summarize these conclusions in the GitHub issues (^10850, ^10928)

• todo: Kida to obtain expert advice on reference characters and post a comment (done)

  • Feedback from Toriumi-san and Morisawa via Jiyu Koubou
  • Kanji with many strokes tend to approximate the average face size due to less layout freedom
  • Characters with left-right sweeping strokes (e.g., 水, 永, 東) tend to exceed the average face and should be avoided
  • Final candidate characters: 輩, 鬱, 酬, 湖

Selection and Copy-Paste Behavior of Ruby Text

GitHub: w3c/clreq#574

Discussion

• Kida: What should happen when selecting ruby? What string should be pasted when copying ruby text?
• Shimono: We discussed this a long time ago, led by Murata-san. Is there a record?
• Murata: I forget. I recall florian and others saying grouped ruby should result in grouped base/ruby copies, while in mono-ruby it’s acceptable for base and ruby to interleave?
• Kida: That's a different issue. Interleaving likely results from bad HTML markup.
• Tajima: There may have been past discussions on ruby not breaking properly at line ends.
• Prof. Satoshi: Ideally, base and ruby should be copied together.
• Kida: Since there's no single correct answer, let’s vote on preferred plain text behavior:
  - Append ruby directly to base (+1)
  - Base character only (+4)
  - Append ruby in parentheses after base (+3) (later, Tajima ran a Twitter poll showing Specifying the vertical positioning of the kihon-hanmen #3 as most preferred among expert respondents)
• Best behavior may vary by context, like value vs formula pasting in spreadsheets.
• Must consider cases where: (a) selection fully encloses one ruby unit, (b) selection intersects a ruby unit, (c) only ruby is selected
• Obviously, rich text pasting should preserve ruby.

Conclusion

No final conclusion. But we need consistency.
todo: Kida to help converge this discussion in JLReq-d.

How to Determine Relative Size Between Japanese and Latin Fonts

GitHub: w3c/csswg-drafts#6384 (comment)

Discussion

• Kida: For using multiple Latin fonts, font-size-adjust aligns x-height or cap height. Could a similar mechanism help align Latin and Japanese characters?
• Nat: This breaks designer intent! But it's a necessary topic under cross-script harmony.
• Prof. Satoshi: There are use cases where it's needed.
• Nat: Latin needs to be enlarged. Need to adjust based on cap height vs virtual body and shift baseline too.
• Kida: We also want to align weight. Variable fonts are useful here.

Conclusion

To be discussed and drafted in JLReq-d editorial meetings.

Bullet Lists in Vertical Writing

Yamamoto-san, Prof. Satoshi, Murata, and Kida commented on a document by Richard. The discussion was used as a basis for drafting the JLReq-d section on vertical bullet lists.

Necessity of Multi-column Layout in Vertical Writing

GitHub: w3c/jlreq-d#77

Discussion

• Kida: There’s ongoing discussion about vertical multi-column layouts
• Tajima: Apple Books has used vertical scrolling multi-columns for some time. It's controversial. Would require custom OPF properties. Production guidelines generally prohibit this, so likely viewer-side behavior.
• Kobayashi: Reading vertically set PDFs via vertical scroll isn’t that strange. Vertical scrolling is good. It’s more like pagination with vertical scroll than multi-column.
• Prof. Satoshi: So it's not that disorienting when moving page by page?
• Murata: In a11y contexts like vertical text for blind users, button mappings for up/down/left/right become important.
• Kida: We may need to recommend UI design that’s based on logical direction, not just visual orientation.
• Murata: PNP format (used for exams) is adding logical direction flags.
• Kida: Let's discuss language in the JLReq-d editorial meeting and propose it to the JLReq TF.

Conclusion

Draft language in JLReq-d editorial meetings and propose to JLReq TF.

Next Meeting

March 11, 10:00 AM JST

[kidayasuo]

出席

atsushi, kida, murata, nat, tajima, tlk, toshi, yamashige

議題

• フォントのフィンガープリント防止策の影響はあるか
• text-box-edge: 和字のエッジはどうやって見つけるか
• ルビの選択やコピー＆ペーストでの挙動
• 日本語フォントとラテンフォントを合わせるときに相対サイズを決める方法
• 縦組みの箇条書き
• 縦組みの段組の必要性
• 次回ミーティング

フォントのフィンガープリント防止策の影響はあるか

フィンガープリント防止策の一つとして、Safariではシステムにデフォルトで備わっている以外のフォント、つまりユーザーがインストールしたフォントにアクセスできないようになっている。この仕組みがCSS fontで議論されており、そこで推奨になると他のブラウザに広がる可能性がある。このような仕組みの日本語に対する影響はあるか？

議論

• 木田：MJ+（お役所の使う人名用フォント）は影響を受ける可能性があるが、これは一般ユーザーが使うようなものではないので考慮外であろう。業務用途の場合、プロファイルを作るなどで除外できる。
• 田嶋：MJ+フォントを前提としたIVSのついたデータがしれっと流れてこないか心配。
• 木田：別の問題だが確かにそういうことが起こってしまうかもしれない。ただ、しれっと流れてきた場合に必要な字形の精度は自治体のシステムとは異なる。普通にIVSのルール通り表示すれば良いのでは。しかし地方自治体のシステムと同じ精度で表示してほしいという期待が高まると日本語フォントのサイズや開発コストを増大させる。それは良いことではない。
• Nat：ブラウザベースのアプリでローカルフォントに依存するものがあれば影響を受ける可能性がある。
• 木田：特に日本語に限った問題ではない。

結論

日本語にとって重要な問題は特に見つからなかった。

text-box-edge: 日本語の文字列を囲む矩形をどのように見つけるか

下の二つの問題に対して石井さんから依頼あり。text-box-edgeなどのプロパティで使う値の日本語に対する仕様についての問題。

• [css-inline] Define how to synthesize ideographic-over and ideographic-under csswg-drafts#10850
• [css-inline] text-box-edge: ideographic and ideographic-ink should use ideographic fonts in the cascade list csswg-drafts#10928

二つの問題がある。一つはフォントにicft/icfbテーブルがない場合にどうやって適切な値を合成できるか。もう一つはフォントリストの最初のフォントからこれらの値を合成すると、最初のフォントは大抵ラテンフォントであって日本語フォントではないので、日本語に対する適切な値にならない、という問題。

下のページに、英語の場合にこれらのプロパティがどのように働くかがわかりやすくまとめられている：

• https://developer.chrome.com/blog/css-text-box-trim?hl=ja
• https://goodpatch-tech.hatenablog.com/entry/figma-web-zure-shitteokou

議論

• Nat: Adobeのフォントにはicft/icfbが入っている。入っていない場合にはヒューリスティックを利用するしかない。non-latinで共通の課題。icft/icfbの目的は平均字面。漢字で大きな文字と小さな文字の平均。inkとしては使えない。trimmingのためにはまあまあ役に立つ。マガジンハウスのグリッドシステムは平均字面を使っている。日本語はedgeに揃えることがあまりない。仮名フォントの場合には仮想的な値。
• 木田: 仕様のところに漢字の平均字面であると書いておくのがいいか？
• 敏先生：実際に表示される文字を囲むということは考えられないか？
• Nat:字形のバウンディングボックスをその場で計算するのはコストがかかる。
• Nat: x-heightが大きいフォント、小さいフォントがあるのと同様、字面が小さい大きいというのはある。ただ、日本語ではベースラインなどEdigeを基準とした配置でなく、中心をそろえているので事情は違う。
• Nat: データを持ってないフォントについては計算するしかないが、漢字の平均字面は特定の文字を選んでバウンディングボックスを利用する。icft/icfbの利用という意味では、日本語でないフォントにもこのデータを入れておいてほしい。組み合わせたときにどうやって値を決めればいいのかという参考値になる。
• 木田: そんなこと非日本語フォントがやってくれることなど期待できない。やったとしてその値は信頼できるか？
• Nat: idtp/ideoの場合には、大体はポイントサイズに等しい。が、ベースライン相対の位置がわからない。その欧文cap heightを仮想ボディと中央揃えをしたら、ベースラインがわかる（ヒラギノ以外）。その計算が利用できるのはJだけ。Kはバラバラ、Cは欧文文字が大きいフォントが多い。
• toshi: 基準となる文字、今は「水」だがだめ。永の字も平均字面よりバウンディングボックスが大きいんじゃないだろうか？フォントデザインの専門家にきちんと聞いて基準となる文字を選定した方がいい。

結論

• idtp/ideoの推定：日本語フォントに含まれるラテン文字のキャップハイトは通常全角（ポイントサイズ）に対して中央揃えされているので、そこから計算できる。

• icft/icfbの推定：基準文字を選定としてそのバウンディングボックスを使う。

• 測定のためにはフォントリストの先頭のフォントではなく、フォントリストで最初に見つかった日本語フォントを使うことが重要。

• todo: 木田がこの結論をissueにコメントする（done. #10850, #10928）

• todo: 木田が基準文字の選定についてアドバイスを得てコメントする（done）

  • 字游工房の鳥海さんを通じて鳥海さんとモリサワのコメントを得た
  • 画数の多い文字は画の配置の自由度が少なくなり、フォントデザインに関わらず平均字面に近づく
  • 偏に左払い、旁に右払いのある文字はその払いの先が平均字面からはみ出がちなので避ける。例えば「水」「永」「東」などがその例
  • 結果、次の文字を候補として選定した「輩, 鬱, 酬, 湖」

ルビの選択やコピー＆ペーストでの挙動

Selecting Ruby w3c/clreq#574

議論

• 木田: ルビを選択するときに何が起こるべきか、ルビ付きテキストをペーストしたときにペーストされるべき文字列は？
• 下農: 昔、村田さんを中心に議論したはず、どこかに残ってないか？
• 村田: 忘れた。昔の論点ではflorianなどの主張はグループルビなどは丸っとそれぞれ親・ルビで取ってくるようになるべきというような話で、モノルビの場合に親文字とルビが互い違いになるのは仕方ないみたいな感じだった？
• 木田: それは別の問題。バラバラになる場合はhtmlの書き方が悪い？
• 田嶋: ブラウザ表示でルビが改行に来た時に分かれないという問題に対応する話はあったかもしれない。
• 敏先生: 基本的には親文字列とルビ文字列でまとまってコピーされてきてほしいのではないか？
• kida: 正解がないということを前提に、プレーンテキストにコピーしてきたときにどういう挙動をしてほしいかという点についてここで投票しみよう。
  1. ルビを親文字にそのまま続ける(+1)
  2. 親文字だけ（+4）
  3. ルビを親文字の後に括弧で続ける(+3)（のちに田嶋さんがtwitterで募ったところ、#3の意見が多かった。回答者の多くは専門家だったので期待通りかもしれない）
• 場合によって最適解が異なってくる。スプレッドシートをコピー＆ペーストする際に、値をペーストするか、数式をペーストするかのオプションがあるが、そういう場合に似ている。
• 選択範囲が一つのルビ単位を完全に包む場合、選択範囲が一つのルビ単位の途中にかかっている場合、ルビだけを選択した場合、など場合に分けて考える必要がある。
• もちろんだが、rich textに対してペーストした場合には、ちゃんとルビを保存してほしい。

結論

特に結論が出なかった。が、統一した動作が欲しいので結論を出すべき。
todo: 木田: jlreq-dでの記述に向けて議論を収束させる。

日本語フォントとラテンフォントの最適な相対サイズを決める方法

font-size-adjust w3c/csswg-drafts#6384 (comment)

議論

• 木田：複数の欧文フォントを使いたい場合に、cap height / x-height を合わせるなどして相対のサイズを合わせるための仕様。欧文文字と和文文字を合わせるために似たような機構を活用できないか。
• Nat: デザイナーの意図を破壊する機能だよ！　しかしcross script harmonyの中で必要な話ではある。
• 敏先生: 欲しいケースあるよ。
• Nat: 欧文を大きくする必要がある。キャップハイトの大きさと仮想ボディとの相対サイズ。ベースラインのシフトも必要。
• 木田：ウェイトも合わせたいね。バリアブルフォントが有用。

結論

jlreq-d編集会議で議論し、文面を作る。

縦書きの箇条書き

Richardが作っているドキュメントに山本さん、敏先生、村田さん、木田らがコメントした。jlreq-d編集会議ではこの議論を元にjlreq-dの箇条書きに関する部分をドラフトした

縦組みの段組の重要性

縦組の段組 w3c/jlreq-d#77

議論

• 木田: 縦組みの段組みについての議論が出ている
• 田嶋: apple booksが前からやっている。縦組の段組の縦スクロール。賛否両論。OPFに独自プロパティが必要。作成側としてはこういうことは行うなということになっているので、ビューアー側での操作ではなかろうか
• 小林: 縦組みされた紙をPDFとかで読むときに縦スクロールでもそこまで違和感がない。縦スクロールは結構良い。段組というよりもページネーションして縦スクロール。
• 敏先生: ページ単位で動く場合はそこまで違和感がないということか。
• 村田: 縦書きで問題になるa11yでは、盲人の利用する際の上下左右ボタンとの対応関係が重要。
• 木田: a11yを考慮してUIの作り方を表示上の方向を利用するのではなく論理方向を基本とした記述をするように、というのを入れておくのがいいのかもしれない。
• 村田：設定情報の交換フォーマットPNP。受験などテスト。この仕様に、論理方向の選択を加えようとしている。
• 木田：jlreq-d編集会議で文面を議論し、JLReq TFミーティングに提案するのはどうか。

結論

jlreq-d編集会議で文面を議論し、JLReq TFミーティングに提案する。

次回ミーティング

3/11 10amから