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?)

他方で、現在の日本語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.)



> 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により詳しく説明していただけるのではないかと察します。



山本太郎