ルビ・圏点の位置決めに使うフォントのメトリクス値（アセンダ・ディセンダ）についての言及がない

[tats-u]

Noto Sans CJK/源ノ角ゴシックやメイリオなどは、sTypoAscender << Win Ascent・hhea Ascenderになっています。

現在のJLReqやCSSの規格書ではどちらのメトリクス値を親文字の文字の外枠の上端にすべきかを明記していません。そのため、環境によって実装の差異が出てしまいます。

↓Firefox（Windows、他も同様）でのルビ。おそらくWin Ascent。ルビと親文字の間が空きすぎ

↓Chromeでのルビ。おそらくsTypoAscender。これぐらいの間隔がちょうどよい。

↓Chromeでの圏点（間隔が狭い方はルビでの代用）本物の圏点はおそらくWin Ascentで間が空きすぎ。

↓Wordでの圏点・ルビ。おそらくsTypoAscender。

↓JLReqでの例その1

↓JLReqでの例その2

↓JLReqでの例3

↓JLReqでの圏点の例

JLReqの例を見る限りではWin Ascent（またはhhea Ascender）ではなく、sTypoAscender推奨だと思われます。ディセンダも同様です。JLReqでも指針として書くべきではないでしょうか？

[kidayasuo]

指摘ありがとうございます。JLReq/JLReq-dで議論します。

[tats-u]

ディセンダも同様なので修正しました。

[macnmm]

BASE テーブルの idtp と ideo が正しい仮想ボディーの上辺と下辺です。Using the various ascender and descender values in CJK fonts is going to be whatever the foundry decided to use, and much of the time those values are not appropriate for correct J typography (correct J line height etc). They often are set larger to accomplish some UI compatibility problem, or to match other fonts in some way. Conversely, setting those values to the embox is a compromise many foundries did to try to support the embox, but because it was undefined how to set those values, no standard exists. That is why BASE ideo exists.

[tats-u]

ありがとうございます。

• 日本語フォントならば基本的にこれらのメトリクスはあると思ってもよいですか？
• 中国語・韓国語のフォントにもあると思ってもよいですか？

両方とも是であればCSSの仕様書にそのまま提言してよいと思います。

[macnmm]

BASE の ideo がある場合は、フォントメーカーがCJK圏の仮想ボディに対するサイズ・アラインメントなどの情報を考慮して作ったことになります。でも、残念なことに全てのフォントが持っていることはありませんのでフォールバックの仕組みも必須です。

[tats-u]

フォールバックに使うメトリクスも何か合意があったりするのでしょうか？
ないならば「BASEのidtp・ideoがあるなら優先して使え」程度の追加でよいでしょうね。

[tats-u]

FontForgeで内蔵のWindows日本語フォントを調べたところ、意外と対応状況が悪いことがわかりました。

フォント名	ictb	icft	ideo	idtp
ＭＳ ゴシック			⭕️
メイリオ
游ゴシック Medium	⭕️	⭕️	⭕️
Noto Sans JP
BIZ UDゴシック
UDデジタル教科書体N

源ノ角ゴシックVFも上の４つのメトリクスはありませんでした。

[tats-u]

上のことから、普通の一般人（Appleユーザは除く）が文章を書いたりサイトを閲覧する分には基本的にフォールバックの方が使われるのではないでしょうか？