RE: ラテン文字の位置

Nat,
I agree with you completely. This is my personal view, but if you need to adjust the size of certain glyphs, such as proportional Latin glyphs, you often need to change stroke widths (and escapement widths, possibly) also, and sometimes even switch to a different Latin typeface. Variable Fonts with adjustable axes are very useful for this purpose. And this works not only for Japanese and Latin combinations but also for mixing any scripts or languages.
(In Japanese:
これは私個人の考えですが、特定のグリフ、例えばプロポーショナルラテングリフの大きさを調整する必要があるとき、画線の太さ（場合によっては字幅も）もしばしば変更する必要が生じ、さらに別の欧文書体に切り替える必要がある場合もあります。このような目的には、可変の軸をもつVariable Fontsがきわめて有効です。このことは、日本語と欧文との組み合わせだけでなく、異なるスクリプトや言語の組み合わせにもあてはまるでしょう)

Regards,

--Taro

From: Nat McCully <nmccully@adobe.com>
Sent: Tuesday, December 30, 2025 12:36 PM
To: Taro Yamamoto <tyamamot@adobe.com>; Kobayashi Toshi <binn@k.email.ne.jp>; JLReq TF 日本語 <public-i18n-japanese@w3.org>
Subject: Re: ラテン文字の位置

太郎さんのご指摘には問題がないと感じています。ただし、一つ強調したいポイントがあります。フォントにはoriginと高さしかなく、その高さがスクリプトごとに異なることです（例えば、欧文はascentとdescentですが、和文は仮想ボディの上下）。そのため、レイアウトエンジンは重要なマトリクス（例えば、x-heightや和文仮想ボディの中央）のオフセットを計算しなければならないことが多いです。一行に複数のフォントやスクリプトを綺麗に配置するためには、必ず微調整が必要で、その方法はエキスパートしかわかりません。和文がメインの場合、欧文フォントを少し大きくしたり、ベースラインを微調整することもあります。その逆も同様です。合成フォントという機能はありますが、その必要性や存在自体を理解している人はほとんどいません。しかし、multiscriptの組版を行うには、マトリクスの関係と微調整の知識が必要だと思います。現在、ATypIのためにこのことについての発表を書いており、その一部は役立つかもしれません。


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: Wednesday, December 24, 2025 10:26:30 PM
To: Kobayashi Toshi <binn@k.email.ne.jp<mailto:binn@k.email.ne.jp>>; JLReq TF 日本語 <public-i18n-japanese@w3.org<mailto:public-i18n-japanese@w3.org>>
Subject: RE: ラテン文字の位置


コメントします。



*         問題1　フォント情報としては，図形データのほかに配置の基準となる基準点の情報はあるのか，ないのか．基準点の情報があれば，それを配置の基準にできる．各文字の字形のサイズが異なるというか，ボディと字面との関係では，各文字ごとに余白の大きさは異なり，字形だけでは管理できない．



OpenTypeの何も付加的な情報（BASEテーブルなど）のないフォントの場合、フォントの再現と配置に必要となる最低限の情報は以下のとおりで、これらはどのフォントにも通常は含まれています。（各グリフのアウトライン情報は当然与えられるものとします。）



1.       まず、文字座標系があります。x, yの二次元座標空間です。原点は(x, y) = (0, 0)です。これが基準点です。したがって、基準点は本源的にあらゆるフォントに備わっています。

2.       UPM （Units Per EM）全角あたりのユニット数。（ただし、これは大きさの基準、および表示・印字文字サイズとの比例関係だけを示す情報です。）
これが、1000であれば、全角が1000ユニットの文字座標系の中に輪郭線の情報が記述されていることを意味します。これによって、レイアウトソフトウェアは、利用者が印刷・表示の段階で文字サイズをSizeとして指定すると、そのSizeとUPMとの関係から、文字サイズと全角が等しくなるように、変換を行います。UPM = 1000であれば、文字座標系の輪郭線の座標データを Size / 1000倍したものが表示される文字の輪郭線の座標になります。（通常は、グリフの輪郭線をこの全角ボディを基準にしてデザインしますが、どのような大きさでどのような位置に実際の輪郭線をデザインし配置するかはデザイナー次第です。ただし、通常の正方形のボディをもつ日本語フォントでは、UPM = 1000なら1000 x 1000の正方形の中に仮名や漢字をデザインします）。
　なお、このUPMはあくまで文字座標系の上でのユニット数なので、個別フォントの中での全角の大きさでしかありません。例えば、TrueTypeフォントではUPM = 2048とするのが普通です。この数の大小は、整数座標値だけを用いる場合は、グリフをデザインする場合の精密さに影響します。UPMが小さいと、非常に細かい部分で曲線の連続性を保てない場合があり得ます。ただし、輪郭線記述形式がCFF/CFF2ベースのOpenTypeフォントでは通常 UPM = 1000を用いています。

3.       欧文グリフのAscenderとDescenderの情報（OS/2テーブルのsTypoAscenderとsTypoDescenderおよびその他の欧文固有の関連位置情報）。

4.       和文の全角ボディの上辺と下辺の情報（日本語フォントでは、伝統的にOS/2テーブルのsTypoAscenderとsTypoDescenderとして全角ボディの上辺と下辺のy座標値を記録します。）



ただし、欧文グリフは通常 y = 0の位置をベースラインとします。この宇宙では「はじめに、ラテン文字ありき」なのです。



*         問題4　国の基準点は，どこにあるのか．それはフォントによるのか．以下では，国の上端として考えていく．もっとも，それはどこでもいい．上端とした場合，文字サイズが決まれば，下端も中央の位置もわかる．

原理的には、上記のような付加的な情報（BASEテーブルなど）のないフォントの場合、国の基準点は、上記の4で示される（OS/2テーブルのsTypoAscenderとsTypoDescender）の全角ボディの情報となります。そしてその基準点をどこにおいても原理的には自由です。しかし、歴史的な背景があり、輪郭線記述形式がCFF/CFF2ベースのOpenTypeフォントの多くは、y = -120を国のボディの下辺の位置としてきました。その理由は、sTypoAscenderとsTypoDescenderをその情報のために用いなかった時代の実装との互換性および歴史的経緯からと予想します。

*         問題5　aの基準点は，国と同じか，それともベースラインの位置か．



付加的な情報（BASEテーブルなど）のないフォントの場合、aの基準点は、世界中のbのフォントと揃わなければならないため、y = 0のラテン文字のベースラインに揃います。（そうでないフォントも皆無ではありませんが、慣習的な想定からは外れた実装です）。国との関係は上記のとおりです。



*         ‘5.2　aの基準点はベースラインと考える．この場合，OpenTypeフォントのBASEテーブルのIdeographic EM-boxの属性をaに与えておけば，配置位置は決まる．



原理的にはそうですが、現状の多くのフォントでは、上記の何も付加的な情報（BASEテーブルなど）のない国のフォントの場合の4のOS/2テーブルのsTypoAscenderとsTypoDescenderの情報と互換となる内容をBASEテーブルに記述しています。このことは、将来は変わるかもしれません。しかし、現時点ではまだ、BASEテーブルの内容を活用しているアプリケーションソフトウェアの数が多数とは言えないため、過去の実装との互換性の観点から、慎重な観察が必要と私は（個人的には）考えます。



*         問題6　bについては，OpenTypeフォントのBASEテーブルのIdeographic EM-boxの属性があれば，それにより国とaの上下位置は決まる．これはわかった．



はい、そのとおりです。が、レイアウトソフトウェアがそれに対応している必要があります。そうでなければ、国のフォントの情報だけに依存して、bを配置することになります。その場合にはaとbの差はありません。



*         問題7　bについては，EM-boxの属性がない場合は，どうなるのか．bのベースライン位置を国のどこか適当な位置に合わせるのか．そうとすれば，どの位置に合わせているアプリケーションが多いのか．



問題6で述べたとおり、 bがIdeographic EM-boxの情報を持っているとは限りません、その場合には、a.と同じ方法で配置されます。BASEテーブルについて何も知らないアプリケーションは、それについて何もしないので、日本語の行中においては、その日本語のフォントの欧文のy = 0の位置と同じ位置のベースラインでbを配置します。



以上、参考まで。



Nat, if you find any incorrect points in what I wrote above, please let me know. Thanks.



山本太郎