- From: Koji Ishii <kojii@chromium.org>
- Date: Mon, 15 Aug 2022 16:11:16 +0900
- To: Nat McCully <nmccully@adobe.com>
- Cc: "public-i18n-japanese@w3.org" <public-i18n-japanese@w3.org>, "Atsushi Shimono (W3C Team)" <atsushi@w3.org>
- Message-ID: <CAHe_1d+oC9cnNAEqkFhrBpB4v1mQib5RtscdQT4YpmzXVn7CBg@mail.gmail.com>
> > > 見た目から考えると、chromeがフォント情報の何かを使って既定ではグリフの上下についてしまう空白領域を削る操作をやっている、ように見えますが、こんな操作に使えるようなフォントの情報って何かあったりするのでしょうか、、、? ご指摘のとおり、Chrome/Chromiumでは、BASEテーブルがないフォントでも適切に見えるよう、既存のフォント内のデータを使って、ヒューリスティックな調整を入れています。ルビの行位置は1 pixelずれても結構目立つので、ピクセルに丸める時の方向なども含めて、幾つかの日中韓のフォントで確認しています。 BASEテーブルがある時には使ったほうがいいかな、と思って途中まで作業していました <https://github.com/harfbuzz/harfbuzz> が、現在のヒューリスティックで問題が出るフォントも見当たらないので、現状では、BASEテーブルには未対応です。 On Tue, Aug 9, 2022 at 2:10 AM Nat McCully <nmccully@adobe.com> wrote: > > これが最も日本語組版をデジタルでやると起きる問題でしょう。emboxがいかに大事であるのにも関わらず、エンジンはascent/descentベースで組んでしまう。開発者にアドバイスを書くなら、BASEテーブル内のideoとidtpとで行の高さを計算すればルビの位置は正確に決められるよ、と。でも、やはり行の高さがemboxでやることは日本語組版優先モードにしないと欧文のみの場合に影響してしまうので気を付けいないといけないです。 > > 木田さん、このためのセクションを書くことは賛成です。自分なりに書いてみます。 > > ナット > > > ------------------------------ > *From:* Atsushi Shimono (W3C Team) > *Sent:* Monday, August 08, 2022 7:54 > *To:* W3C JLReq TF > *Subject:* ブラウザでのグリフ上下の空き (re: ルビ間の空き) > > shimonoです > > 木田さん、村田さん、とああでもないこうでもないと、ちょっと前に上がっていたFirefoxでの親文字 > とルビ文字の間の空きについていろいろやっていたのですが、奇妙な状態に見えてきてしまい、問題が > どこにあるのかちとよくわからなくなってきました。。現象としてはrbとrtの間がsolid setting出ない > という話ではあるのですが、フォントによって違ってきています。 > ということで、有識者のみなさまからのご意見募集を、と。 > > https://storage.himor.in/temp-W3C/test-ruby-embox.html > にいくつかのフォント(Windowsローカル+font.google)で表示させるように設定したページを置いてあ > りまして、画像キャプチャ―が添付になります。rbの中の一文字をspanで囲ってborderを出したものが赤 > 枠、rt全体にborderを設定したのが青枠、p全体を囲ったのが緑枠になります。 > MSゴシックなどを設定するとこれですよ!空きがないやつ!という表示になるのですが、それ以外、メ > イリヨとかgooglefontでは赤枠内の上下(Hannariは上だけ?)にアキが出ます。 > 面白いことに(なのか当然のようになのか?)rbとrtがくっついて表示されるChromeでは、赤と青の箱 > が重なるように表示されます。 > > 見た目から考えると、chromeがフォント情報の何かを使って既定ではグリフの上下についてしまう空白 > 領域を削る操作をやっている、ように見えますが、こんな操作に使えるようなフォントの情報って何かあ > ったりするのでしょうか、、、? > # TTFにはないOTFでだけのテーブルの影響、、、? >
Received on Monday, 15 August 2022 07:11:41 UTC