Re: JLReq-D: Fonts Section [DRAFT]へのコメント

敏先生、太郎さん

太郎さん、ありがとうございます。私からの返信は下に埋めます...

________________________________
From: Taro Yamamoto <tyamamot@adobe.com>
Sent: Thursday, December 8, 2022 23:20
To: 敏 小林 <binn@k.email.ne.jp>; Nat McCully <nmccully@adobe.com>; 泰夫 木田 <kida@mac.com>; public-i18n-japanese <public-i18n-japanese@w3.org>
Subject: RE: JLReq-D: Fonts Section [DRAFT]へのコメント


Natが現れないので、先に私からコメントさせていただきます。

(Nat, please correct anything incorrect in my comments given below, if any. Thanks).



>> What has been the state of the art until now?

の中の以下

>> The font Ascent and Descent add up to equal the Ideographic Embox....



>活字を考えると，Ascentの上側，Descentの下側にすこし余白があるのではないか？

および

> This last point forces font foundries to set the “ascent” and “descent” and baseline/origin of Japanese fonts ...> この意味ですが，“ascent” and “descent” and baseline/originを日本語フォントでも設定しているということか？



これは、現在のOpenTypeフォントのように、sTypAscenderやsTypoDescenderまたIdeographic EMboxの情報を用いていない場合に、欧文グリフのメトリクスに、roman-centricな環境のせいで課せられる制約について説明しているものと理解します。


(Nat, I suspect here you are discussing the limitations and constraints which used to be imposed upon the metrics of Latin glyphs in a Japanese font due to the Roman-centric assumptions of the rendering environment, especially in those days when the trick of using s.TypoAscender and s.TypoDescender was not used, and the Ideographic EM Box information was not used. Correct?)

フォントにはボディを示すものは（普通は）sTypoAscenderとsTypoDescenderです。和文フォントの場合には漢字のボディの高さをそのメトリクスに入れています。よって、欧文のascentとdescentや、欧文フォントの普段のボディ（デザインスペース）とは違う使い方です。同じメトリクスは欧文フォントと和文フォントとで違う意味になってしまい、アプリ側では和欧混植は簡単にできなくなります。CJKフォントのボディの決め方は色々あって、ごちゃごちゃになりがちです。それが問題になって、BASEテーブルのideoとidtpを追加して、和文フォントのボディ専用のメトリクスとして定義できるようにしましたが、いまだに広く使われていなくて、アプリ側で計算しなければならない場合が多いです。もちろん、欧文（非漢字）フォントとの整合性を高めるために適切な和文ボディのサイズをBASEに入れればいいのに、誰も入れていないのが事実です。


他方で、現在の日本語OpenTypeフォントに含まれる欧文グリフのデザインそのものは、全角ボディの制約をまったく受けません。全角ボディとは無関係です。実際、多くの書体でgやjの下のdescenderは全角ボディの下辺よりも下に伸びています。（手動写真植字機においては、写口マスクの形状が通常全角の仮想ボディの正方形だったため、全角内に収める必要がありました。そのために写植書体に附属する欧文には、descenderを異常に短くしたおかしなグリフが使われることになったのです。この制約はデジタルフォントにはありません。）


> At that point the term “virtual body” will mean a type body equal in “height” to the point size, but the ideographic embox will reside inside that body and be a different “height”.

> これまで，文字のサイズは，活字のボディ，あるいは仮想ボディのサイズを意味していた．したがって，字面の大きさを示すものではなかった．上記の意味は，今後は，この字面あるいはグリフの大きさで文字サイズを示すということか？



これは、例えば、字幅の狭いコンデンス体のフォントが既に存在しますが、将来的には、欧文と同じように、それぞれのフォント（あるいはそれぞれのグリフ）の仮想ボディの形状は、必ずしも常に従来の全角正方形に限定されることはなくなる、たとえそれが文字サイズの基準として存続し続ける必要があったとしても。ということを意味していると思います。


(Nat, I guess here you mean that although there are some condensed Japanese fonts today, in the future, the shape and dimensions of the body of each Japanese font (or each glyph in a Japanese font) will not always be limited to or constrained by the conventional square EM square, like proportional Latin fonts of today, even if it is necessary to continue to use the square EM body as the reference for type sizing and type size specification. If my interpretation is wrong, please so advise me.)

今までの和文フォントのボディは漢字のemboxと同じだったのですが、欧文フォントは文字の高さや幅（例えば "M" の幅と高さ）をそのままボディとしてメトリックスに入れていないのです。フォントによって、サイズは一緒にも関わらずある同じ文字の字形の高さはバラバラ。将来は和文フォントの幅や高さをバリアブルになっていれば、欧文と同じように漢字の高さはフォントサイズが同じでもバラバラになることは考えられる。sTypoAscenderとsTypoDescenderの高さは今まで通りサイズの高さになり続けるのでしょうが、漢字そのものの高さはそれより高く、低くデザインできるのを想像します。要するに今までassociatedだったものはdissociatedになってしまいますので開発はより複雑になります。



> 6日の会議で，山本さんは，たしかラテン文字のcapital lineとbase lineの中心と和文文字の中心が位置をそろえる基準になる，といっていたと記憶しているが，ラテン文字と和文文字の位置を決める場合，その位置決めとしては，以下の5つが考えられる．

1　ラテン文字のascender lineとdescender lineの中心に和文の中心ををそろえる

2　ラテン文字のcapital lineとbase lineの中心に和文の中心ををそろえる

3　ラテン文字のmean lineとbase line（x height）の中心に和文の中心ををそろえる

4　和文文字に設定されているbase lineにラテン文字のbase lineをそろえる

　＊縦組の場合にも和文文字のbase lineは設定されているとして

5　ラテン文字のbase lineに和文の仮想ボディのい下端（または左端）をそろえる

> 実際はどうなっているのか？

> また，これを選択できるという仕組みを考えられないか？

たしかに、色々な場合が考えられますが、現実的には、1, 3, 5はあまり実用的ではないと考えられます。多くの場合、欧文が上がりすぎます。（下図参照）。

[sample1.jpg]

多くの場合、Cap.ハイトの中心を和文の全角の中心の高さに揃えることで、最適とは言えないまでも、他の場合よりも妥当な結果が得られると考えます。そのため、Adobeの欧文フォントには、Cap.ハイトの中心と和文の全角ボディの中止の高さが一致するように、和文全角ボディの情報（BASEテーブルのIdeographic em-box）が設定されています。


ただし、和欧混植について考える場合の前提として、和文書体も欧文書体も多様なため、個別の組み合わせについては、最終的には個別に調整するしかないということを認識する必要があると考えます。そのためいつも完璧に自動的に揃えられるような一般的な方法は存在しないと思われます。ただ、現在行われている対応で理想的かというと、それはまだまだ不十分です。現在、フォント側で対応できているのは、おそらく、


欧文ベースラインと和文の全角との相対的な上下方向の位置関係



だけです。上で触れましたが、OpenTypeフォントはBASEテーブルにIdeographic em-boxの情報をもつことができます。それは、個別の欧文フォントにとってCap.ハイトの中心を和文の全角ボディの高さに合わせるための、全角ボディのy位置の情報をもっています。それによって、アプリケーションは欧文の大文字の高さの中心の高さと和文の全角の中心の位置を揃えることが可能となっています。


大きさ

　画線の太さ

　字幅



については、現在フォント側に用意されている情報だけで「和欧混植」を最適化することはできません。ただし、アプリケーション側でこれらを調整することは可能です。InDesignの合成フォント機能を用いると、組み合わせる欧文フォントの大きさとベースライン位置の微調整も可能になっています。また、可変軸をもつVariable Fontsを利用することで、将来的には画線の太さや字幅を可変的により精密に調整して最適なペアリングが可能になるのではないかと予想します。



すべてのご質問には答えられませんでしたが、私の説明で不十分な点、間違っている点を含め、Natにより詳しく説明していただけるのではないかと察します。



山本太郎
アプリには欧文ベースラインと和文emboxとの関係を決めないと和欧混植はできないので、まずはemboxのどこに各欧文フォントのベースラインを置くか。そして、欧文フォントは和文フォントに比べて小さいか、大きいか、決めて調整する。調整したらウェートなども考えるとか。和欧混植の行は、和文中心か、欧文中心かで、高さ（ハイライトやラップ境界線とか）と送り方（原点と方向）などは決められます。

これら全部絵で説明した方がいいと思います。...

ナット