- From: Taro Yamamoto <tyamamot@adobe.com>
- Date: Mon, 7 Jul 2025 05:59:03 +0000
- To: Kobayashi Toshi <binn@k.email.ne.jp>, Yasuo Kida <kida@mac.com>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
- CC: 浦山毅 <urara2116@gmail.com>
引き続き、コメントします。 > サイドベアリングという語は、文字を側面(side)から保持する(bearing)活字ボディのマージンを意味しているため、伝統的には天地方向には使いません。しかし、漢字や仮名のようなグリフの場合には、天地のマージンのこともサイドベアリングと便宜上呼んでいる場合もなくはありません。ただ、それは欧文のグリフにはあてはまりません。 > それでは,上下については,サイドベアリングという用語は,使わない方よいということですね. はい、私はそう考えます。欧文のグリフには、天地方向では、サイドベアリングに相当するものがないからです。 > A案:それぞれのフォントの文字が持っているボディの高さ(文字の高さ)による. と言って,それ以上は何もいわない. > B案:それぞれのフォントの各文字が持っているボディの高さ(文字の高さ)による. 例えば,以下は,次のようになるという説明を加える. > 以下,B案とした場合 > B案:それぞれのフォントの持っているボディの高さ(文字の高さ)による. > 例1 日本語フォントの付属するプロポーショナルなラテン文字およびアラビア数字 この文字の高さは,どう説明できますか? 本来、プロポーショナル欧文グリフにはボディが存在しないため、縦組みでも欧文グリフを回転せずに正立させる場合には、横組みでの欧文のベースライン位置とその和文フォントの和文の全角ボディとの相対的な位置関係(欧文のベースラインがy = 0にあるとした場合の、全角ボディの下辺と上辺のy座標値、'BASE'テーブルのIdeographic EM Box)の情報を、縦組み内で配置される全角ボディに適用して、横組み時と同様の欧文グリフの位置を決める。(具体的なグリフの配置方法は実装によって異なるが、上記と同様の結果とするために必要な座標変換操作を行って欧文グリフを配置する)。このことは、日本語フォントに付属するか、独立した欧文フォントのグリフかには異存しません。 > ということは,日本語フォントに付属するプロポーショナルなラテン文字では,ボディの高さ(文字の高さ)は,定義されており,各文字は,その値を持っているということか? 日本語フォントに付属するプロポーショナルな欧文グリフであっても、プロポーショナルな欧文グリフであるかぎり、それらの欧文グリフに固有のボディの情報を取得することはできません(ボディが存在しないから)。ただし、日本語フォントに付属するプロポーショナルな欧文グリフの場合には、天地方向については、日本語フォントの全角ボディの上辺と下辺の位置を示すsTypoAscenderとsTypoDescenderをそのまま継承するため、日本語フォントの全角ボディの高さを、便宜的に、欧文グリフのボディの高さとしています。したがって、ディセンダ―やアセンダーが全角から食み出るグリフの場合には、縦組みで正立の場合には、前後のグリフと衝突します。 フォントの中には、グリフ形状そのものを表現するグリフ手続きが'glyf'や'CFF'テーブルとして含まれるため、その中のグリフごとのBBOX情報を取得することは可能ですが、そもそも、プロポーショナルの欧文を縦組みで正立させて組むことが一般に行われていないため、および、サイドベアリングに相当する情報を欧文グリフはもっていないため、欧文グリフを正立させて縦組みで組むためにそれら個別グリフのBBOX情報が使われている例を、私は知りません。 通常、BBOXの情報やy方向のmin/maxの情報が利用されるのは、行の配置やレンダリング時のメモリー確保を目的としているのではないでしょうか。 > 例2 日本語フォントの付属する全角のラテン文字およびアラビア数字 > > この文字の高さは,どう説明できますか? 原則は上記と同じですが、縦組みで欧文を正立させるために全角欧文と全角数字が広く用いられているため、フォントによっては、'VORG'テーブル内に、縦組みでグリフの縦方向での位置を、グリフが全角の中央にくるように調整するための情報をもっているものもあり、それが利用可能な場合には、それに対応するアプリケーションは、全角欧文・数字グリフを全角の中央に配置します。InDesignはそうしています。 > 例3 ラテン文字を主にしたフォント(別の言い方はできないか?) > hhea’テーブルのAscenderとDescender)には上記の意味でのascenderとdescenderの情報が含まれています。 > 欧文グリフを包含する最小の矩形(BBOX)の上辺と下辺との間の距離をグリフの高さと考えることは可能です。そして、この寸法には通常descenderからascenderまでの距離を計測して決める ↓ > 欧文グリフを包含する最小の矩形(BBOX)の上辺と下辺との間の距離をグリフの高さ.通常descenderからascenderまでの距離である.この場合,和文文字のボディの高さ(文字の高さ)と同じとなるかどうかはフォントによる.(といってよいか?) そのように言うことは間違いではありませんが、縦組みで欧文グリフを正立させるという目的では、そのグリフごとの「グリフの高さ」の情報は利用されていないのが現状です。利用方法も確立されていません。ただし、このことは、既に述べましたが、プロポーショナルの欧文・数字グリフを縦組みで正立させるという用法が一般的に行われていないために、大きな問題ではないと考えます。 つまり、縦組みが存在する和文組版中で、行方向を揃えるために90度回転させないでプロポーショナルの欧文グリフを正立させるという方法には、原理的に無理がある。ということだと考えます。それは、ボディを持たないプロポーショナルの欧文グリフの性質から自明だともいえます。 他方で、全角の欧文・数字グリフは、和文組版の要素として、和文中で利用されることだけを想定してデザインされフォント中に含まれているものであるため、縦組み中で正立させることが容易に行えるだけでなく、一部のフォントでは、縦組みの時に全角中央に配置可能とするなど、それ相応の対応策が講じられてもいる。 ということだと私は理解しています。 山本太郎
Received on Monday, 7 July 2025 05:59:09 UTC