Re: ラテン文字のボディの大きさ

No errors and I am glad to see you reply. Sorry for English:

One point I would like to include in such information is the fact that digital fonts normally only define font metrics in terms of Latin ascent and descent, so for Japanese typography we had to define a standard placement of the baseline within the coordinate space and define a top and bottom to stand in for the virtual body, and further declare that virtual body to be the point size in height. Later when we made a variable body font (momochidori) we had to modify our declaration to say the top and bottom of the virtual body should be the cjk embox top and bottom, and the coordinate space origin remains the Latin baseline for compatibility with other fonts.
Why did we do this? Because until we did, there was no standard for placing glyphs of the font design within the virtual body. As Taro said there is no body per se, only Latin metrics. Because there is no standard across fonts and non-Latin scripts for where glyphs are to be placed in the coordinate space, ad hoc standards are created and engines favor Latin typography placement when making lines. For example in Japanese fonts the ascent and descent are often set to arbitrary values and have nothing to do with the Latin glyphs in the font. That makes the Latin glyphs incompatible with other Latin fonts just so that the Japanese glyphs are made compatible with other Japanese fonts.
In other words, different script systems for font metrics are needed but only Latin metrics exist and so everyone hijacks those metrics, which means one script works and all others do not.
There is still no standard definition for Korean metrics or Indic metrics or Arabic metrics in fonts. There is no standard for how such metrics should relate to Latin ascent and descent. Thus there is still no standard for how two fonts should align or scale their bodies. This problem is critical to non-Latin typography being supported fully and not just a second class citizen to Latin in digital fonts and engines.
Needless to say I am working on this problem and hope to define such systems and their relationships so we can have virtual bodies for all scripts not just Latin and Japanese.

Nat McCully
Principal Scientist

T 206 675 7351  |  C 206 409 0624
nmccully@adobe.com


[signatureImage]
________________________________
From: Taro Yamamoto <tyamamot@adobe.com>
Sent: Sunday, July 6, 2025 6:15:37 AM
To: Kobayashi Toshi <binn@k.email.ne.jp>; Yasuo Kida <kida@mac.com>; JLReq TF 日本語 <public-i18n-japanese@w3.org>
Cc: 浦山毅 <urara2116@gmail.com>
Subject: RE: ラテン文字のボディの大きさ


各位

アドビの山本です。

コメントします。



> A案　ボディ……現在書いているドキュメントで採用されている言い方

>　つまり，ボディとは，文字を正立させた場合の文字の左右の大きさ（幅）と上下の大きさ（高さ）



ボディという考え方は、和文フォントのように横組みだけでなく縦組みでも用いることができる、プロポーショナルでないフォントに含まれる、主要なグリフ集合（例えば漢字や仮名グリフ）に当てはまるものです。なぜなら、それらのグリフの字幅（字送り量）は横組みでも縦組みでも等幅だからです（これは長体・平体フォントについてもいえるでしょう）。ただし、それらの場合でも、そのフォント中に含まれる欧文のグリフは、多くの場合、和文グリフのボディの範囲内には収まらないので、それらの欧文グリフについては、横組み時の字幅しか存在しない、ということになると思います。つまりボディは存在しません。

　

> B案　左右の幅…字幅（これは現在書いているドキュメントでも使っている）

　　上下の高さ…文字の高さ



和文フォントに含まれている欧文グリフであれ、そうでない純粋な欧文フォントのグリフであれ、字幅は存在しますが、上下の高さは、欧文グリフを包含する最小の矩形（BBOX）の上辺と下辺との間の距離をグリフの高さと考えることは可能です。そして、この寸法には通常descenderからascenderまでの距離を計測して決めることになります。ただし、字幅とは異なり、この寸法はサイドベアリングを含みません。



> 問題2　文字の幅と高さ，特に“高さ”とは何か？

> ここまではよいが，問題はラテン文字ではどうなるか，これを議論したい．縦組を考えた場合，どうしても文字の高さを決めないといけないから．

>ラテン文字の高さとは

>例1　活字の例

>　一般に字面＋上下のサイドベアリング（と言っていいのかわからないが，いくらかの余白というか，字面とボディの間の斜面の大きさ）



活字の場合、正立した鏡像の字面のある側面を上向けにした場合、字面最下端より下方向が、活字の正面（front）の上端で終わるまでをBeardといい、字面の最上端より上方向で、活字の裏面（back）の上端で終わるまでをShoulderと呼んでいます （Legros & Grant, Typographical Printing-Surfaces, (London: Longmans, Green & Co., 1916), p. 11 にその記述があります）。しかし、これは活字の字面の下部の空白と上部の空白部分という意味であって、あまり寸法的に厳密なことを言っているのではないよう私には思えます。活字の場合には、物理的なボディの縦方向の寸法（Body Height）はボディの大きさで固定なので、寸法的にはベースラインの位置、x-height、Cap height、descender、ascender以外には重要なものは縦方向にはないと思われます。サイドベアリングという語は、文字を側面（side）から保持する（bearing）活字ボディのマージンを意味しているため、伝統的には天地方向には使いません。しかし、漢字や仮名のようなグリフの場合には、天地のマージンのこともサイドベアリングと便宜上呼んでいる場合もなくはありません。ただ、それは欧文のグリフにはあてはまりません。



> 例2　アッセンダーとデッセンダーの距離

>　これは正しいのか？　それしかデータはないのか．



日本語フォントの中に入っているプロポーショナルの欧文グリフには当てはまりませんが、欧文フォントの'OS/2'テーブルのsTypoAscenderとsTypoDescender（および’hhea’テーブルのAscenderとDescender）には上記の意味でのascenderとdescenderの情報が含まれています。



現状では、和文フォントに含まれる正立の全角欧文については、縦組みで天地方向で和文の全角の中心にくるように'VORG'テーブル内の情報を使って位置を調整している和文フォントもありますが、プロポーショナルの欧文グリフについては、そのような縦組みのための調整は行われていないと思います。また、アプリケーションもプロポーショナルの欧文グリフを縦組みで正立させて組むことは、とりあえず数字や大文字だけの短い略号であれば、（単純に全角の中心で90度回転して）和文の全角に収めただけでも、組めないわけではない、という以上の視覚的な調整はしていないように思います。（Nat might correct me if I make any errors about this.）


山本太郎