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

Nat,

  *   Thank you for your strident translation. ^.^;

I believe the stridency came from the original text and I just faithfully translated it into Japanese. 😊



少しNatのコメントの翻訳を以下の通り修正します。



この種の情報に、もう一点含めた方が良いと思うことは、デジタルフォントでは通常、ラテン文字のアセントとディセントによってのみフォントメトリクス（フォントの寸法情報）が定義されるという事実です。そのため、日本語タイポグラフィにおいては、座標空間内でのベースラインの標準的な配置を定義し、仮想ボディの位置の上端と下端を定め、その仮想ボディをポイントサイズの高さとして宣言する必要がありました。後にVariable Fontsで可変的なボディをもつ「ももちどり」フォントを制作した際には、その定義を修正し、仮想ボディの上端と下端をCJK EMボックス（和文の全角）の上端と下端としながら、座標空間の原点は他のフォントとの互換性のためにラテンのベースラインのままとする、という宣言を行いました。



なぜ、そうしたのか？　それは、私たちが行うまでは、フォントのデザインにおいて、グリフを仮想ボディ内に配置することに関する標準が存在しなかったからです。Taroが先に書いていたように、「ボディ」というものは本来存在せず、あるのは、ラテンのメトリクス（寸法情報）だけです。フォントには、特に非ラテン文字体系においては、グリフが座標空間内のどこに配置されるべきかについての標準が存在しないため、その場限りの暫定的な種々の基準が作られますが、レンダリングエンジンが行を組む際には、ラテン文字の配置方法を優先します。例えば、日本語フォントではアセントとディセントが任意の値に設定されていることが多く、それがフォント内のラテン文字とは無関係であることがあります*。その結果、日本語のグリフの他の日本語フォントとの互換性を維持しようとすることが、そのフォントのラテン文字の他のラテンフォントとの互換性を失わせることになってしまいます。



言い換えれば、フォントメトリクスについて文字体系ごとの異なる基準が必要であるにもかかわらず、存在するのはラテンのメトリクスだけであり、そのためすべての文字体系がそれを流用することになり、一つの文字体系だけは上手く機能するが、他の文字体系ではうまく機能しないという状況になります。現在でも、韓国語、インド系文字、アラビア文字などついては、メトリクスの標準的な定義が存在していません。それらの文字体系のメトリクスがラテン文字のアセントやディセントとどのような関係にあるべきかについての標準がありません。したがって、2つのフォントがどのようにボディを揃えたり、拡大・縮小したりすべきかという標準も存在しません。このことが、非ラテン文字のタイポグラフィをラテン文字に対する二級市民としてではなく、完全にサポートする上で、致命的な問題としてあります。言うまでもなく、私はこの問題に取り組んでおり、すべての文字体系に対して仮想ボディを定義し、ラテンや日本語だけでなく、他の文字体系にも対応できるような体系とその関係性を確立したいと望んでいます。



Nat McCully
Principal Scientist
Adobe
------
From: Nat McCully <nmccully@adobe.com>
Sent: Monday, July 7, 2025 2:31 AM
To: Taro Yamamoto <tyamamot@adobe.com>; 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: ラテン文字のボディの大きさ

Thank you for your strident translation. ^.^;


Nat McCully
Principal Scientist

T 206 675 7351  |  C 206 409 0624
nmccully@adobe.com<mailto:nmccully@adobe.com>


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


Nat,

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



I’m glad to learn that my answer was free from errors. I translate your comments into Japanese as follows:



この種の情報に、もう一点含めた方が良いと思うことは、デジタルフォントでは通常、フォントメトリクスがラテン文字のアセント（上昇）とディセント（下降）によってのみ定義されるという事実です。そのため、日本語タイポグラフィにおいては、座標空間内でのベースラインの標準的な配置を定義し、仮想ボディの位置の上端と下端を定め、その仮想ボディをポイントサイズの高さとして宣言する必要がありました。後にVariable Fontsで可変的なボディをもつ「ももちどり」フォントを制作した際には、その定義を修正し、仮想ボディの上端と下端はCJK EMボックスの上端と下端としながら、座標空間の原点は他のフォントとの互換性のためにラテンのベースラインのままとする、という宣言を行いました。



なぜ、そうしたのか？　それは、私たちが行うまでは、フォントのデザインにおいて、グリフを仮想ボディ内に配置することに関する標準が存在しなかったからです。Taroが先に書いていたように、「ボディ」というものは本来存在せず、あるのは、ラテンのメトリクス（寸法情報）だけです。フォント特に非ラテン文字体系においては、グリフが座標空間内のどこに配置されるべきかについての標準が存在しないため、その場限りの暫定的な種々の基準が作られ、レンダリングエンジンが行を組む際には、ラテン文字の配置方法を優先します。例えば、日本語フォントではアセントとディセントが任意の値に設定されていることが多く、それがフォント内のラテン文字とは無関係であることがあります*。その結果、日本語のグリフの他の日本語フォントとの互換性を維持しようとすることが、そのフォントのラテン文字の他のラテンフォントとの互換性を失わせることになってしまいます。



言い換えれば、フォントメトリクスについて文字体系ごとの異なる基準が必要であるにもかかわらず、存在するのはラテンのメトリクスだけであり、そのためすべての文字体系がそれを流用することになり、一つの文字体系だけは上手くこうするが、他の文字体系はうまく機能しないという状況になっています。現在でも、韓国語、インド系文字、アラビア文字などついては、メトリクスの標準的な定義が存在していません。それらの文字体系のメトリクスがラテン文字のアセントやディセントとどのような関係にあるべきかについての標準がありません。したがって、2つのフォントがどのようにボディを揃えたり、拡大・縮小したりすべきかという標準も存在しません。このことが、非ラテン文字のタイポグラフィをラテン文字に対する二級市民としてではなく、完全にサポートする上で、致命的な問題としてあります。言うまでもなく、私はこの問題に取り組んでおり、すべての文字体系に対して仮想ボディを定義し、ラテンや日本語だけでなく、他の文字体系にも対応できるような体系とその関係性を確立したいと望んでいます。



Nat McCully
Principal Scientist

Adobe
----
*  [Taro:  As it is thought that the sTypoAscender and sTypoDescender data in the ‘OS/2’ table should be compatible with the Ascender and Descender data in the ‘hhea’ table, and in a Japanese font, the sTypoAscender and sTypoDescender data need to be used to define the Japanese EM body position relative to the Latin baseline (y = 0), the Ascender and Descender information for Latin glyphs are not available in these tables. On the other hand the EM body positioning information can be stored in the ideographic EM box information in the ‘BASE’ table today. But it is possible that few layout engines today reference the ‘BASE’ table entries appropriately.]

山本注記：‘OS/2’テーブルの sTypoAscender とsTypoDescenderのデータは’hhea’テーブルのAscenderとDescenderのデータと互換でなければならないと考えられているため、そして、日本語フォントでは、the sTypoAscender and sTypoDescenderのデータは日本語の全角ボディの、欧文のベースライン位置（y = 0）からの相対位置を指示するために使う必要があるため、この種のテーブル中に欧文グリフのAscenderとDescenderを収容することができません。ただし、日本語の全角ボディの、欧文のベースライン位置（y = 0）からの相対位置については、現在では’BASE’テーブルのIdeographic EM Boxのデータとして記載することができるようになっています。ただし、必ずしもレイアウトエンジンの多くがが’BASE’テーブルのそれらのエントリーを適切に参照しているとは限りませんが。]



From: Nat McCully <nmccully@adobe.com<mailto:nmccully@adobe.com>>
Sent: Sunday, July 6, 2025 11:32 PM
To: Taro Yamamoto <tyamamot@adobe.com<mailto:tyamamot@adobe.com>>; Kobayashi Toshi <binn@k.email.ne.jp<mailto:binn@k.email.ne.jp>>; Yasuo Kida <kida@mac.com<mailto:kida@mac.com>>; JLReq TF 日本語 <public-i18n-japanese@w3.org<mailto:public-i18n-japanese@w3.org>>
Cc: 浦山毅 <urara2116@gmail.com<mailto:urara2116@gmail.com>>
Subject: 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<mailto:nmccully@adobe.com>



[signatureImage]

________________________________

From: Taro Yamamoto <tyamamot@adobe.com<mailto:tyamamot@adobe.com>>
Sent: Sunday, July 6, 2025 6:15:37 AM
To: Kobayashi Toshi <binn@k.email.ne.jp<mailto:binn@k.email.ne.jp>>; Yasuo Kida <kida@mac.com<mailto:kida@mac.com>>; JLReq TF 日本語 <public-i18n-japanese@w3.org<mailto:public-i18n-japanese@w3.org>>
Cc: 浦山毅 <urara2116@gmail.com<mailto: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.）

山本太郎