Re: GSUB/vert があるかどうかを知る (was Re: フォント分科会

あ、処理されたかどうか、という意味でした。

木田

> 2021/03/31 9:45、Koji Ishii <kojii@chromium.org>のメール:
> 
> ちなみに質問がこちらの場合
> 
> それが横倒しされたかどうかがわかる方法があれば良いですのにね。
> 
> GSUB/vertがある文字にかかったかどうかと、それが横倒しになったかどうかは別事象なので、「横倒しかどうかをわかるか」というと、答えはNOになります。
> 
> 子がなとか句読点のように、向きを変えずに位置や形を変えるだけの場合もあります。
> 
> On Wed, Mar 31, 2021 at 9:37 AM 木田泰夫 <kida@me.com <mailto:kida@me.com>> wrote:
> 石井さん、
> 
> ありがとうございます。なるほど、これは難しそうですね。可能だけれど困難、の具合がよくわかりました。きっととても優先度の高いことならなんとかなるけれど、縦書き問題にその困難を解消する手間は割けそうにない、そんな感じですね。ウェブブラウザのコードをよくご存知の石井さんがいてくださって良かった。
> 
>> チェックのために一度通して、その結果によって処理を変えてもう一度通すとなると、二度通ることになりますので、処理時間に相当な影響が出ます。
> 
> vert 単独で変換されるかをチェックする部分が加わるので、二度通る、という事になるのですね。もし一度のパスでそれが横倒しされたかどうかがわかる方法があれば良いですのにね。
> 
> 少しの救いはこのコードパスは縦書きの時だけに必要だということですね。
> 
> 木田
> 
>> 2021/03/31 1:23、Koji Ishii <kojii@chromium.org <mailto:kojii@chromium.org>>のメール:
>> 
>> 良いポイントですね。実はこの質問に答えることが、容易ではありません。CSS WGでも一度この質問が出て、当時MozillaにいたJohn Daggett氏の「困難」という見解を聞いて、これが可能である前提でのデザインを棄却しました。
>> 
>> GSUBは、入力と出力が共にグリフIDである変換ボックスと考えられます。OpenTypeでは、この変換ボックスを任意の段数で組むことができます。例えばlocl <https://docs.microsoft.com/en-us/typography/opentype/spec/features_ko#tag-locl>とvertの２つのfeatureがオンの場合、loclがまずグリフIDを変換し、その変換結果をvertに入れて、その変換結果を表示します。loclはデフォルトでオンなので、ユーザーが意識しなくても、多段組になることは多いです。このため、すべての変換ボックスを組んで、文字コードを入力してみないと、vertで変換がかかったかどうかはわかりません。
>> 
>> とはいえ、通常は１～２段程度のことが多いし、いずれにしても表示するには一度すべてのGSUBを通しますから、可能か、不可能か、で言えば、可能です。
>> 
>> ただし、この処理は、全体の処理時間の中で非常に多くの割合を占めています。単純なページでは20%程度だと思いますが、80%超を見たこともあります。チェックのために一度通して、その結果によって処理を変えてもう一度通すとなると、二度通ることになりますので、処理時間に相当な影響が出ます。
>> 
>> また、難易度は、アプリの構成によっても異なります。ツメのところでお話しようと思っていたのですが、昨今はOpenTypeが複雑になってきたので、外部ライブラリ化していることが多いです。アプリ内でOpenType処理をすべて持っている場合には、それぞれのGSUBで実際に変換が発生したかどうかを知ることはもちろん可能なので、処理速度の問題さえ許容できるのであれば「困難」とまでは行かないように思います。
>> 
>> 外部ライブラリ化している場合、この情報を外に出していない場合が多い、というよりも、私の知っているライブラリは全て出していません。このため、ライブラリの変更から検討する必要が出てきます。
>> 
>> 現在、 Blink/Gecko/WebKitは、OpenType処理を外部ライブラリに依存しているため、処理時間の問題と合わせ考えると、「困難」という見解に同意です。
>> 
>> 
>> On Tue, Mar 30, 2021 at 5:01 PM 木田泰夫 <kida@me.com <mailto:kida@me.com>> wrote:
>> 石井さん、
>> 
>> > 特定のグリフ、文字に対して GSUB/ver? があるかどうかを知る簡単な方法はあるのかな？
>> 
>> 
>> これ、ミーティングで石井さんに伺いたいと思っていて忘れていました。
>> 
>> レイアウトエンジン、例えばウェブブラウザから、特定の文字に対して GSUB/verX があって、つまり横転するに違いない、ということを知ることは簡単ですか？
>> 
>> もしそれができれば、正立横転の「判断」をフォントに任せずに、ウェブブラウザから完全にコントロールできますかね？
>> 
>> 木田
>> 
>> > 2021/03/30 9:43、木田泰夫 <kida@me.com <mailto:kida@me.com>>のメール:
>> > 
>> > 
>> >> 現実問題として、1)はある意味Unicodeで属性がすでにあり、2)はGSUB/vert or vrt2を持つかどうかで判定してやればいい、という感じで何とかなる、的な話をおっしゃられている、ということでしょうか？？
>> > 
>> > それでうまく動くならそう言うことになりますかね。
>> > 特定のグリフ、文字に対して GSUB/ver? があるかどうかを知る簡単な方法はあるのかな？
>> > 
>> >> # あ、なんか、2010年頃に大変そーだなー、と眺めていた議論をふとちょっと思い出したようなほのか
>> >> なかおり・・・
>> > 
>> > で自分で拾うはめに :D
>> > 
>> > 木田
>> > 
>> > 
>> >> 2021/03/30 9:40、Atsushi Shimono (W3C Team) <atsushi@w3.org <mailto:atsushi@w3.org>>のメール:
>> >> 
>> >> 
>> >> 
>> >> On 2021/03/30 08:48, 木田泰夫 wrote:
>> >>> # 五月雨式にすみません
>> >>> フォントとレイアウトエンジンの契約の混乱という意味で、ラテン文字のイタリックのケースが解決の一つの参考になるかもしれないと思いつきました。イタリックの指定があった場合、もしフォントがイタリックを持っていればそれが使われます。が、そうでない場合、web ではむりくり oblique を作りますよね。もちろん高品質な結果にはならないんですが、なんとかそれで意図は伝わる、と。
>> >>> これを日本語縦書きに適用すると、1) 各々の文字が縦書きでどの向きになるべきかの共有された合意があり、レイアウトエンジンはそれを知っている。2) 各々のグリフについて、フォントがそれを合意された向きにしてくれるかをエンジン側で知る手段がある。この二つが満たされれば、フォントの品質がバラバラでも縦横問題はなんとかなる？
>> >> 
>> >>　 現実問題として、1)はある意味Unicodeで属性がすでにあり、2)はGSUB/vert or vrt2を持つかどうか
>> >> で判定してやればいい、という感じで何とかなる、的な話をおっしゃられている、ということでしょう
>> >> か？？
>> >> 
>> >> 
>> >> # あ、なんか、2010年頃に大変そーだなー、と眺めていた議論をふとちょっと思い出したようなほのか
>> >> なかおり・・・
>> >> 
>> >> 
>> >>> 文字によってはフォントがやってくれないとどうしようもないものもありますが、その必須部分は「日本語フォント」の必要最小限の定義にする。
>> >> 
>> >> 
>> > 
>> 
>