[1] [[文字]]や[[文字列]] (を表す[[グリフ]]や[[グリフ]]の列) の[[座標空間]]は複雑です。 * 基線 [SEE[ [[基線]] ]] * OpenType の座標 [115] [[OpenType]] の[[グリフ]]は、 [[座標空間]]上の[[点]]の[[集合]]として記述されます。 [116] 1つの[[グリフ]]データは、 1つの[[座標空間]]上に配置されています。 このデータを適宜、[[文字]]を[[レンダリング]]するべき位置に配置 (= [[行]]の[[座標空間]]に変換) し、 次の[[文字]]の配置処理へと進んだり、前後の[[文字]]との関係を調整したりすることになります。 [4] [[フォント単位]] [70] [CODE[kern]] [REFS[ - [3] [CITE@ja-jp[[[GPOS]] — Glyph Positioning Table (OpenType 1.9) - Typography | Microsoft Docs]], [[PeterCon]], [TIME[2022-09-06T11:34:46.000Z]] ]REFS] [71] [CITE@ja-jp[[[LTSH]] - Linear Threshold (OpenType 1.9) - Typography | Microsoft Docs]], [[PeterCon]], [TIME[2022-09-09T12:24:42.000Z]] [73] [CODE[OS/2][OS/2 (OpenType)]], [CODE[post][post (OpenType)]], [CODE[sbix]], [CODE[STAT][STAT (OpenType)]] ** 横書き用座標値 [REFS[ - [124] [CITE@en-us[[[hhea]] - Horizontal header table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:19.000Z]], [TIME[2024-11-27T11:22:38.342Z]] ]REFS] ** 縦書き用座標値 [77] [[横書き]]用の[[座標]]値を格納する [CODE[hhea]], [CODE[hmtx]] に対して、 [[縦書き]]用の [DFN[[CODE[vhea]]]] (vertical header table) [SRC[>>78]] と [DFN[[CODE[vmtx]]]] (vertical metrics table) [SRC[>>103]] があります。 [274] [[OpenType]] vertical font は [CODE[vhea]] と [CODE[vmtx]] が[RUBYB[必須][require]]です。 [SRC[>>103]] [254] [CODE[vhea]] のデータは、 [CODE[vmtx]] のデータと一貫していなければ[RUBYB[なりません][must]]。 [SRC[>>78]] ;; [255] [CODE[hhea]] / [CODE[hmtx]] にはなぜかこれに相当する規定がありません。 [79] [[縦書き]]用の[[フォント]]では [CODE[vhea]] を使うことになっていますが [SRC[>>78]]、 [[Windows]] の [[Chrome]], [[Firefox]] とも [CODE[vhea]] がないからといって[[縦書き]]表示に特別支障となることは無さそうです。 [TIME[2023-11-11T11:24:49.00Z]] [80] [CODE[vhea]] には [CODE[vmtx]] 用の[[グリフ]]数の欄がありますが、 [[Chrome]], [[Firefox]] とも [CODE[vmtx]] が存在しなくてもエラーにはならないようです。 (一方 [CODE[hmtx]] がないとエラーになります。) [273] vertical metrics coordinate system [SRC[>>103]] [275] [[グリフ]]の[DFN[[F[[RUBYB[[[縦書き原点]]][vertical origin]]]]]]の y [RUBYB[座標][coordinate]]は、 [[グリフ]]の [[tsb]] + [[グリフ]]の [[bounding box]] の top (= y の最大) です。 [SRC[>>103]] ;; [276] 通常は[[グリフ]]の上部の[[アキ]]も含めた上端ということになります。 [283] 実装は、 [CODE[CFF ]] または [CODE[CFF2]] の[[グリフ]]であり、 [[フォント]]に [CODE[VORG]] [[表]]がある場合は、 [CODE[VORG]] に指定された値でこれに替えることができます (し、定義通りの計算もできます)。 [SRC[>>103]] [279] [[縦書き原点]]のy座標の算出に必要な[[グリフ]]の[F[外接箱]]の[F[上辺]]の値は [CODE[glyf]] には入っています (>>62) が、 [CODE[CFF ]] や [CODE[CFF2]] には入っていないので計算が必要です (>>278)。 この計算を省略して[[応用]]が正確性と性能を向上させられるよう、 [DFN[[CODE[VORG]]]] [[表]]を使うことができます (が、[RUBYB[必須ではありません][optional]])。 [SRC[>>103, >>281]] ;; [280] 必須ではないので[[フォント]]の設計者はこれを含めるか含めないかを決められますし、 実装者はどちらのケースも想定する必要があることになります。 ;; [284] 正確性というのは[[丸め]]誤差などが想定されます。 [SRC[>>281]] [282] [CODE[VORG]] は [CODE[CFF ]] や [CODE[CFF2]] の [[OpenType]] [[フォント]]でのみ[RUBYB[使えます][may]]。 [[TrueType outline]] データの [[OpenType]] [[フォント]]では無視しなければ[RUBYB[なりません][must]]。 [SRC[>>281]] [286] [CODE[VORG]] の [DFN[[F[[CODE[defaultVertOriginY]]]]]] や [DFN[[F[[CODE[vertOriginY]]]]]] では、 [[グリフ]]の[F[縦書き原点]]のY座標を[[フォント]]の[RUBYB[設計座標系][design coordinate system]]において表します。 [SRC[>>281]] [287] [[グリフ]]の[F[垂直原点]]の x [RUBYB[座標][coordinate]]は、 [CODE[vmtx]] には指定されません。 [SRC[>>281]] [288] [RUBYB[縦書き][vertical writing]]実装は、 [CODE[BASE]] [[表]]に[[基線]]値があれば、 [[グリフ]]を [RUBYB[望ましい][desired]][[垂直基線]]に対して適切に x 方向で揃えるよう使うことが[RUBYB[できます][may]]。 [SRC[>>281]] [REFS[ - [78] [CITE@en-us[[[vhea]] — Vertical header table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:16.000Z]], [TIME[2024-11-26T11:33:55.547Z]] - [103] [CITE@en-us[[[vmtx]] — Vertical metrics table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:32.000Z]], [TIME[2024-11-26T11:35:50.160Z]] - [281] [CITE@en-us[[[VORG]] — Vertical origin table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:17.000Z]], [TIME[2024-12-03T04:05:51.540Z]] ]REFS] ** グリフ位置決定 [5] [[TrueType]] では、 [[グリフ]]の位置は基準となる [[pen point]] ([[pen position]]) からの[RUBYB[[[配置]]][placement]]と[RUBYB[[[前進]]][advance]]の2値で決まります。 すなわち、 現在の [[pen point]] から[RUBYB[[[テキスト]]][text]]の線に対して、 [[配置]]量だけ移動したところに[[グリフ]]を置きます。 そして次の[[グリフ]]の [[pen point]] を[[前進]]量だけ移動したところに置きます。 [SRC[>>3]] [299] 仕様書には明確な説明がありませんが、例示の図では[[前進]]の値のことを[[横書き]]では [DFN[[CODE[horiAdvance]]]], [[縦書き]]では [DFN[[CODE[vertAdvance]]]] と呼んでいます。 [SRC[>>3]] [300] 同じく説明がありませんが、例示の図では [[side bearing]] のことを[[横書き]]では ([DFN[[CODE[horiBearingX]]]], [DFN[[CODE[horiBearingY]]]]), [[縦書き]]では ([DFN[[CODE[vertBearingX]]]], [DFN[[CODE[vertBearingY]]]]) と呼んでいます。 [SRC[>>3]] [8] [[TrueType]] における[[配置]]と[[前進]]は、 [[横書き]]では[[X軸]], [[縦書き]]では[[Y軸]]の1次元値です。 [SRC[>>3]] - [7] [[左横書き]]では[[配置]]量は [[left side bearing]] ([CODE[horiBearingX]]) となります。 [[前進]]量は [[advance width]] ([CODE[horiAdvance]]) となります。 [SRC[>>3]] [[グリフ]]は最初の [[pen point]] から右へ右へと並べられていきます。 - [9] [[上縦書き]]では[[配置]]量は [CODE[vertBearingY]] となります。 [[前進]]量は [CODE[vertAdvance]] となります。 [SRC[>>3]] [[グリフ]]は最初の [[pen point]] から下へ下へと並べられていきます。 [10] [[TrueType]] では、 [CODE[kern]] [[表][OpenType表]]を使って2つの[[グリフ]]の間の空間の増減を指定できます。 [SRC[>>3]] 前の[[グリフ]]の[[前進]]量に [CODE[kern]] による調整量を足し合わせることで適切なスペースに調整できます。 [11] [[OpenType]] では、 [CODE[GPOS]] [[表][OpenType表]]を使って[[配置]]と[[前進]]を [[X軸]], [[Y軸]]の2次元で指定できます。 値は[[フォント単位]]によります。 [SRC[>>3]] - [13] [[配置]]操作で指定する (X,Y) 値は、 [[書字方向]]に関わらず、 常に典型的な[RUBYB[[[直交座標系]]][Cartesian coordinate system]] ([RUBYB[左側の基線に[[原点]]][origin at the baseline of the left side]]) 内にあります。 [SRC[>>3]] -- [104] [[書字方向]]に関わらず[[グリフ]]は同じ[[座標系]]に描画できるので[[フォント設計者]]に特に便利です。 [SRC[>>3]] - [14] [[前進]]は[[左横書き]]では[[X軸]]方向に [[advance width]] 分[[加算]] ([[右]]移動) し、 [[右横書き]]では[[X軸]]方向に [[advance width]] 分[[減算]] ([[左]]移動) します。 [SRC[>>3]] [[上縦書き]]では[[Y軸]]方向に [[advance height]] 分[[加算]] ([[下]]移動) します。 [EG[ [297] [[配置]]を使って前の[[グリフ]]と近づけたいとき[[左横書き]]では[[負]]の値を指定することになり、 [[右横書き]]では[[正]]の値を指定することになります。 [298] [[前進]]を使って次の[[グリフ]]と近づけたいとき[[書字方向]]に関わらず[[負]]の値を指定することになります。 ]EG] ;; [315] [[グリフ]]には[F[前進幅]]と[F[前進高]]がありますが、それぞれ[[横書き]]と[[縦書き]]のときに使われ、 '''行の進行方向に対する位置決定においては'''同時に使われることはありません。 (>>317 も参照。) -*-*- [301] 仕様書では明確な説明がありませんが、例示の図では、 - [302] [[横書き]]のとき [[pen position]] は[[アルファベット基線]]の左側に置かれ、 [CODE[horiBearingY]] は[[基線]]から [CODE[maxY]] まで、 [CODE[horiBearingX]] は [[pen position]] から [CODE[minX]] までの値となっています。 [SRC[>>3]] - [303] [[横書き]]のとき [[pen position]] は左右中央を通る[[基線]]の上側に置かれ、 [CODE[vertBearingX]] は[[基線]]から [CODE[minX]] まで、 [CODE[vertBearingY]] は [[pen position]] から [CODE[maxY]] までの値となっています。 [SRC[>>3]] [304] とはいえ[[横書き]]の [[pen position]] の Y 座標と [CODE[horiBearingY]] の値や、 [[縦書き]]の [[pen position]] の X 座標と [CODE[vertBearingX]] の値は、 どこを選んでも得られる結果は変わらないので、 実装上都合がいい位置だとみなすことができます。 ;; [305] なので仕様書に説明がないことは技術的には問題ないのですが、 読者の仕様書の読解と技術の理解のためにはよろしくありません。 [316] [[横書き]]では、[[グリフ]]の上下方向の配置は、 Y 座標の位置を揃えることによって行われます。 基本的には Y = 0 が[[アルファベット基線]]で、これに[[行]]が揃えられることになります。 なお[F[前進高]]は関係しません。 [317] [[縦書き]]では、[[グリフ]]の左右方向の配置は、左右中央に合わせることによって行われます。 [[グリフ]]の左右中央の位置は、[[グリフ]]の[F[前進幅]]の半分の位置となります。 基本的には[[グリフ]]の左右中央を[[行]]の中央に揃えることになります。 ;; [318] この[F[前進幅]]は、 [CODE[GPOS]] による調整の適用前の値です。 -*-*- [12] [CODE[GPOS]] [[表][OpenType表]]では更に[[装置]]依存の調整もできます。 [SRC[>>3]] [17] [CODE[GPOS]] による位置調整は、 [[lookup]] によって一致条件と一致した場合の挙動が記述されますが [SEE[ [[lookup]] ]]、 同じ[[グリフ]]に対する複数の [[lookup]] による指定は、蓄積されていきます。 [SRC[>>3]] [EG[ [18] [[機能][フォント機能]]1により [[X軸]]方向に3前進し、 [[機能][フォント機能]]2により [[Y軸]]方向に6前進し、 [[機能][フォント機能]]3により [[X軸]]方向に-2前進すると、 [[X軸]]方向には1前進し、 [[Y軸]]方向には6前進することになります。 ]EG] - [19] [CODE[GPOS]] [CODE[lookupType]] [N[1]] では、 単一の[[グリフ]]に対して、 [[X軸]]と[[Y軸]]の[[配置]]と[[前進]] (のそれぞれの[[加算]]量) を指定できます。 [SRC[>>3]] - [20] [CODE[GPOS]] [CODE[lookupType]] [N[2]] では、 2つの[[グリフ]]の[[組]]におけるそれぞれの[[グリフ]]に対して、 [[X軸]]と[[Y軸]]の[[配置]]と[[前進]] (のそれぞれの[[加算]]量) を指定できます。 [SRC[>>3]] [75] [CODE[GPOS]] では [CODE[kern]] [[機能][フォント機能]]で[[カーニング]]指定ができますが、 その他の[[機能][フォント機能]]でも同様の位置調整を行えます。 [68] [[JstfMax lookup]] では [[justification]] において加除する[[X軸]]と[[Y軸]]の[[配置]]と[[前進]]の最大値を指定できます。 実装はこれを使って 0 [[以上]]指定された値[[以下]]の調整を行えます。 [SRC[>>67]] [76] [[結合文字]]関係固有の挙動は、[[結合文字]]のレンダリングの項を参照。 [REFS[ - [67] [CITE@ja-jp[[[JSTF]] — Justification Table (OpenType 1.9) - Typography | Microsoft Docs]], [[PeterCon]], [TIME[2022-09-08T13:21:33.000Z]] ]REFS] [74] [CITE@ja[GPOSのCursive Attachment Positioningについて - にせねこメモ]], [TIME[2023-11-06T08:49:59.000Z]] [CODE[curs]] ** 添付点 [6] [[OpenType]] では、 [CODE[GPOS]] [[表][OpenType表]]を使って[DFN[[RUBYB[グリフ添付点][glyph attachment point]]]]による[[グリフ]]間の位置調整も可能です。 [SRC[>>3]] [16] [[添付点]]は[[基底グリフ]]と[[ダイアクリティカルマーク]]の位置調整のために、 あるいは[RUBYB[[[続け字]]][cursive]]における前後の[[グリフ]]の位置調整のために使えます。 [SRC[>>3]] [15] [[OpenType]] では[[グリフ]]は0個以上の[RUBYB[添付点][attachment point]]を持つことが出来ます。 [SRC[>>3]] それぞれ上の[[ダイアクリティカルマーク]]位置、 下の[[ダイアクリティカルマーク]]位置といったように使います。 [21] [CODE[GPOS]] [CODE[lookupType]] [N[3]] (cursive attachment positioning) では、 [[グリフ]]の [[entry point]] [[anchor]] と [[exit point]] [[anchor]] を設定できます。 両 point [[anchor]] は、 位置 [WEAK[([[X軸]]座標と [[Y軸]]座標の組)]] を指定します。 [SRC[>>3]] [24] 2つの[[グリフ]]を並べるとき、1つ目の[[グリフ]]の [[exit point]] から 2つ目の[[グリフ]]の [[entry point]] へと続くようにします。 [23] [[line-layout direction]] の調整については、 [[論理順]]で1つ目の[[グリフ]]の[[前進]]を調整します。 結果的に2つ目の[[グリフ]]が移動されて anchor 位置を揃えます。 [SRC[>>3]] [25] [[cross-stream direction]] の調整については、 一方の[[グリフ]]の[[配置]]を調整して他方の[[グリフ]]と anchor 位置を揃えます。 [F[[CODE[RIGHT_TO_LEFT]]]] が [N[0]] の場合、 2つ目の[[グリフ]]を調整します。 [F[[CODE[RIGHT_TO_LEFT]]]] が [N[1]] の場合、 1つ目の[[グリフ]]を調整します。 [SRC[>>3]] [26] [[entry point]] / [[exit point]] の指定された[[グリフ]]が続く場合、 その[[グリフ]]列全体の配置が連続的に影響されていきます。 [F[[CODE[RIGHT_TO_LEFT]]]] が [N[0]] なら、 最初の[[グリフ]]が[[基線]]基準で配置され、 以後どんどんずれていく形になります。 [F[[CODE[RIGHT_TO_LEFT]]]] が [N[1]] なら、 最後の[[グリフ]]が[[基線]]基準で配置され、 それに向けてどんどんずれが解消してく形になります。 [27] [DFN[[F[[CODE[RIGHT_TO_LEFT]]]]]] [[フラグ]]は [[lookup]] の [F[[CODE[lookupFlag]]]] [[ビット欄]]の第0ビットです。 [SRC[>>28]] [[lookup]] の条件を記述する他の[[フラグ]]と違って [F[[CODE[RIGHT_TO_LEFT]]]] [[フラグ]]は [F[[CODE[lookupType]]]] [N[3]] の[[グリフ]]位置調整にだけ作用します。 ;; [29] 名前に反して[[右横書き]]にはあまり関係ありません。 が巷の[[フォント]]では [F[[CODE[lookupType]]]] と無関係に[[右横書き]]向けの[[グリフ]]が収容された [[lookup]] にこのフラグが設定されていたりするようです。 ([F[[CODE[lookupType]]]] [N[3]] 以外では指定されていてもいなくても動作は変わりません。) ;; [30] [[entry point]] と [[exit point]] は、[[書字方向]]によって違う位置にしなければならないのが普通です。 1つの [[lookup]] で同じ[[グリフ]]に対して複数の[[書字方向]]用の anchor は記述できませんから、 [[書字方向]]ごとの [[lookup]] を用意しなければなりません。 ([[続け字]]で同じ[[グリフ]]で違う[[書字方向]]にそのまま適用できる例の方が稀かもしれませんが。) [31] [CODE[GPOS]] [F[[CODE[lookupType]]]] [N[4]] (Mark-to-Base Attachment Positioning, MarkBasePos) は、 [[基底グリフ]]と[[マークグリフ]]の組み合わせについて、 両[[グリフ]]にそれぞれの [[anchor point]] を指定するものです。 [SRC[>>3]] [34] [CODE[GPOS]] [F[[CODE[lookupType]]]] [N[5]] (Mark-to-Ligature Attachment Positioning, MarkLigPos) は、 [[合字グリフ]]と[[マークグリフ]]の組み合わせについて、 両[[グリフ]]にそれぞれの [[anchor point]] を指定するものです。 [SRC[>>3]] [37] [CODE[GPOS]] [F[[CODE[lookupType]]]] [N[6]] (Mark-to-Mark Attachment Positioning, MarkMarkPos) は、 基底となる[[マークグリフ]] mark2 とそれに付加する[[マークグリフ]] mark1 の組み合わせについて、 両[[グリフ]]にそれぞれの [[anchor point]] を指定するものです。 [SRC[>>3]] [35] [[基底グリフ]]の場合は [[anchor point]] は1組だけ指定できます。 [[合字グリフ]]は見かけ上複数の[RUBYB[構成部品][component]]があるかもしれないので、 [[anchor point]] をそれに合わせて複数組設定できます。 [SRC[>>3]] [32] [[マークグリフ]]は、[[基底グリフ]]と互いの [[anchor point]] が揃うように[[配置]]を調整します。 [[マークグリフ]]の位置決定は、 [[基底グリフ]]の[[前進]]後の [[pen point]] を基準とします。 [[基底グリフ]]の[[配置]]は変更しません。 両[[グリフ]]の[[前進]]は変更しません。 [SRC[>>3]] [36] [[合字グリフ]]の場合も[[基底グリフ]]と同じようにします。 [SRC[>>3]] ただし[[合字グリフ]]のときは複数組ある(かもしれない) [[anchor point]] のいずれを選ぶかが問題となります。 [SEE[ [[文字のレンダリング]] ]] [38] [[マークグリフ]]同士の場合も基底となる[[マークグリフ]] mark2 に対して同じようにします。 [SRC[>>3]] ;; [33] [[lookup]] の機能的に求められる[[基底グリフ]]、 [[合字グリフ]]、 [[マークグリフ]]といった[[グリフ級]]と、 実際に [[lookup]] に記述された[[グリフ]]に割り当てられた[[グリフ級]]は、 一致しないことも[[データ構造]]上はあり得ます。 そのような場合にどうするべきかは言及もされていません。 素直に考えると、これらの [[lookup]] は[[グリフ級]]によって使う、 使わないがまず判断されるのですから、 [[グリフ級]]が一致しないデータが混じっていても単に無視されるだけなのが好ましい実装でしょうか。 [22] 複数の [[lookup]] の指定は蓄積されることになっていますが [SRC[>>3]]、 適用されるべき [[entry point]] anchor, [[exit point]] anchor, [[マークグリフ]]用の [[anchor point]] が重複するときどう処理するべきかは不明です。 そのような指定は意味を持ちませんから、 [[フォント]]はそのような [[lookup]] を持つべきではないのでしょう。 [39] [[基底グリフ]]または[[合字グリフ]]と[[マークグリフ]]との関係による [[anchor point]] と[[マークグリフ]]と[[マークグリフ]]との関係による [[anchor point]] の両方が適用可能なときは、 [[マークグリフ]]と[[マークグリフ]]の [[anchor point]] が優先されることを意図していると考えるのが自然です。 ;; [40] こちらの場合は[[基底グリフ]]と[[マークグリフ]]の単体の組み合わせも意味があるのですから、 [[マークグリフ]]と[[マークグリフ]]の [[anchor]] との衝突は [[lookup]] の設計の誤りではなく、 優先度が仕様上明確でないことの問題です。 [69] [[JstfMax lookup]] で[[添付点]]を指定することは [CITE[OpenType]] 仕様上明確に禁止されていませんが、 その意味が定められていません。 [SRC[>>103]] [[添付点]]と「最大値」という [[JstfMax lookup]] の性質はなじまないので、 利用ではないかもしれません。 ([[justification]] によって[[添付点]]が変化するべきなら、 [[JstfMax lookup]] ではなく有効または無効にするべき [[lookup]] として別に記述できます。 [SEE[ [[JSTF]] ]]) [REFS[ - [28] [CITE@ja-jp[OpenType layout common table formats (OpenType 1.9) - Typography | [[Microsoft]] Docs]], [[PeterCon]], [TIME[2022-09-07T09:25:47.000Z]] ]REFS] ** 可変フォント [SEE[ [[HVAR]], [[VVAR]], [[MVAR]] ]] * グリフの大きさ ** 外接箱 [54] [[グリフ]]の[DFN[[RUBYB[[RUBY[外][がい]][RUBY[接][せつ]][RUBY[箱][ばこ]]][bounding box]]]]は、 [[グリフ]]のすべての[[制御点]]を含む最小の[[矩形]]です。 [SRC[>>52]] [62] [[TrueType outline]] の[[グリフ]]の[[外接箱]]は、 [CODE[glyf]] [[表][OpenType表]]の[[グリフ]]データによります。 [SRC[>>43, >>103]] [45] [CODE[glyf]] [[表][OpenType表]]の [[TrueType outline]] [[グリフ]]データは、 [DFN[[F[[CODE[xMin]]]]]], [DFN[[F[[CODE[yMin]]]]]], [DFN[[F[[CODE[xMax]]]]]], [DFN[[F[[CODE[yMax]]]]]] の4つの [CODE[int16]] 値を持ちます。 [SRC[>>44]] [47] [[TrueType outline]] [[グリフ]]のこの4値は[[グリフ]]の点 [WEAK[([[on-curve point]] も [[off-curve point]] も)]] の[[座標]]データから直接得ます。 [[rasterrizer]] が計算した [[phantom point]] は算入しません。 [SRC[>>44]] [46] [[TrueType outline]] [[グリフ]]の[DFN[[RUBYB[[RUBY[外][がい]][RUBY[接][せつ]][RUBY[矩][く]][RUBY[形][けい]]][bounding rectangle]]]]は、 左下 ([F[[CODE[xMin]]]], [F[[CODE[yMin]]]])、 右上 ([F[[CODE[xMax]]]], [F[[CODE[yMax]]]]) の[[方形]]です。 [SRC[>>44]] [278] [CODE[CFF ]] や [CODE[CFF2]] の[F[外接箱]]は、 [CODE[CharString]] データから算出することになります。 [SRC[>>103]] [53] [CODE[head][head (OpenType)]] [[表][OpenType表]]は、 [DFN[[F[[CODE[xMin]]]]]], [DFN[[F[[CODE[yMin]]]]]], [DFN[[F[[CODE[xMax]]]]]], [DFN[[F[[CODE[yMax]]]]]] の4つの [CODE[int16]] 値を持ちます。 [SRC[>>52]] [55] [CODE[head][head (OpenType)]] [[表][OpenType表]]のこの4値は、 [[フォント]]中のすべての[[グリフ]]を含む[[外接箱]]を表します。 [[contour]] なき[[グリフ]]は無視します。 [SRC[>>52]] ;; [48] [[制御点]]により定義される[[外接箱]]は[[outline]]を含むことが保証されます。 [[outline]] に接するとは限りません。 [SRC[>>44]] ;; [56] [[外接箱]]、[[外接矩形]]の2種類の語が使われていますが、表記揺れで同じ概念と思われます。 ;; [112] [[contour]] のない、つまり[[空白]]の[[グリフ]]では定義されません。 各定義により [N[0]] などの値になります。 [132] [CODE[hhea]] に [DFN[[F[[CODE[xMaxExtent]]]]]] があります。 lsb + (xMax - xMin) の最大値を表します。 [SRC[>>124]] [263] [CODE[vhea]] に [DFN[[F[[CODE[yMaxExtent]]]]]] があります。 tsb + (yMax - yMin) の最大値を表します。 [SRC[>>124]] [125] [F[[CODE[xMaxExtent]]]] は、 [[contour]] を持つ[[グリフ]]のみを使って計算する[RUBYB[べきです][should]]。 [SRC[>>124]] [246] [[可変フォント]]では[[制御点]]の座標値が変わることがありますから、[[グリフ]]の [[outline]] や[[グリフ]]の[[実現値]]を構成するすべての[[点]]の tight bounding rectangle は、 [[グリフ]]の[[既定実現値]]のものより大きかったり小さかったりします。 [CODE[head]] の [F[[CODE[xMin]]]], [F[[CODE[xMax]]]], [F[[CODE[yMin]]]], [F[[CODE[yMax]]]] は[[実現値]]の derived glyph outline を包含することもあれば、 そうでないこともあります。 非[[既定実現値]]の[[フォント]]の[[グリフ]]を包含する bounding rectangle が必要な[[応用]]は、 [[実現値]]の derived glyph outline を処理して決定する[RUBYB[べきです][should]]。 [SRC[>>52]] ;; [277] [[フォント]]内で明示された[[外接箱]]の情報と実際のグリフデータから算出される[[外接箱]]の情報が相違するとき、 どうなるのかは [CITE[OpenType]] 仕様書上必ずしも明確になっていません。 これらの情報は主に性能を目的として重複して含まれていると考えられるので、 実装は処理の最適化のために使っているでしょうから、 情報が矛盾していると誤った[[レンダリング]]になる可能性がありそうです。 また、実装戦略に関わりますから、[[相互運用性]]に問題が生じる可能性がありそうです。 場合によってはバッファー溢れなど[[セキュリティー]]に悪影響を及ぼしそうですから、 実装者は注意が必要です。 ;; [285] [[外接箱]]を使って計算する[[縦書き原点]]については、 [CODE[VORG]] (>>279) として明示することができます。 [[外接箱]]の計算に関する[[丸め]]誤差などが正確性や互換性の問題を起こし得ることが [CITE[OpenType]] 仕様書にも明記されています。 ** side bearing [106] [DFN[side bearing]] は[[グリフ]]の [[contour]] の外側の[[アキ]]を指します。 上下左右にあるうち、 - [107] [DFN[left side bearing]] ([DFN[LSB]]) は、 [[グリフ]]の配置のための[[現在位置]] ([[原点]]) から[[グリフ]]の [F[contour]] の[F[左端]]までの長さです。 [[contour]] が[[現在位置]]より左まで伸びているときは、[[負]]の値になります。 - [108] [DFN[right side bearing]] ([DFN[RSB]]) は、 [[グリフ]]の配置のための[[現在位置]] + [[グリフ]]の[F[前進幅]]の位置から [[グリフ]]の [F[contour]] の[F[右端]]までの長さです。 [[contour]] が[F[前進幅]]より右まで伸びているときは、[[負]]の値になります。 - [292] [DFN[top side bearing]] ([DFN[TSB]]) は、 [[グリフ]]の配置のための[[現在位置]] ([[垂直原点]]) から[[グリフ]]の [F[contour]] の[F[上端]]までの長さです。 [[contour]] が[[現在位置]]より上まで伸びているときは、[[負]]の値になります。 - [293] [DFN[bottom side bearing]] ([DFN[BSB]]) は、 [[グリフ]]の配置のための[[現在位置]] + [[グリフ]]の[F[前進高]]の位置から [[グリフ]]の [F[contour]] の[F[下端]]までの長さです。 [[contour]] が[F[前進幅]]より下まで伸びているときは、[[負]]の値になります。 ;; [109] [[contour]] のない、つまり[[空白]]の[[グリフ]]では定義されません。 各定義により [N[0]] などの値になります。 [256] [[side bearing]] は [DFN[sidebearing]] とも綴ります。 [CITE[OpenType]] 仕様書でも一貫性無く混用されています。 一応、単体のときは [[side bearing]] と綴りがち、 [[修飾語]]になるときは [[sidebearing]] と綴りがちという傾向は見られます。 [57] [CODE[hmtx]] に [DFN[[F[[CODE[lsb]]]]]] があります。 [[グリフ]]の [F[left side bearing]] を[[フォント設計単位]]で表します。 [SRC[>>43]] [296] [CODE[vmtx]] に [DFN[[F[[CODE[topSideBearing]]]]]] があります。 [[グリフ]]の [F[top side bearing]] を[[フォント設計単位]]で表します。 [SRC[>>281]] [111] [[グリフ]]の [F[lsb]] の値と[[グリフ]]を構成する[[制御点]]の最左の座標 ([F[[CODE[xMin]]]]) を一致させることが一般的のようです。そうすると[[グリフ]]の[[局所座標系]]の[[原点]]と[[現在位置]]が一致して、 [[フォント]]の編集時にわかりやすくなります。 [243] [CODE[glyf]] の [F[[CODE[xMin]]]] と [F[lsb]] は同じかもしれませんが、 違うこともあります。 [SRC[>>43]] [244] [CODE[head]] の [F[[CODE[flags]]]] の第1ビットは、 [[left side bearing]] point at [VAR[x]] = 0 を意味するとされています。 [[TrueType]] [[rasterizer]] にのみ関係します。 [SRC[>>52]] [60] [CODE[CFF ]] や [CODE[CFF2]] の[[グリフ]]データには [CODE[xMin]] = [[lsb]], [CODE[xMax]] を明示的には含みません。 [[side bearing]] は [CODE[CharString]] データに暗示的に含まれていて、 [CODE[CFF ]] / [CODE[CFF2]] [[rasterizer]] から得られます。 [SRC[>>43]] [252] しかし [[layout engine]] によっては [CODE[CFF ]] や [CODE[CFF2]] の場合でも [CODE[hmtx]] の [F[lsb]] を使うかも[RUBYB[しれません][may]]。 [SRC[>>43]] [61] [[フォント]]生成ツールは、 [[left side bearing]] と [CODE[CFF ]] / [CODE[CFF2]] [[outline]] の [CODE[CharString]] が暗示する [CODE[xMin]] が一致するようにする[RUBYB[べきです][should]]。 [SRC[>>43]] ;; [253] 仕様書の意図が不明瞭なのですが、 [CODE[CFF ]] や [CODE[CFF2]] の場合でも [F[lsb]] を使って[[グリフ]]を配置してもいいし、 使わないで[[グリフ]]の[[局所座標系]]をそのまま使って配置してもよく、 どちらかといえば後者が推奨されるのであり、 [[フォント]]はそれを前提にするのがいいということでしょうか。 ただ [CODE[CFF2]] の[[可変フォント]]については前者の挙動が求められています (>>245)。 [49] [F[[CODE[xMin]]]] が [[lsb]] と等しくなるように[[グリフ座標]]を取ると [[scaler]] には都合がいいです。 [SRC[>>44]] すべての[[グリフ]]がそうである場合には [CODE[head][head (OpenType)]] [[表]]のその旨のフラグを設定できます [SRC[>>52]]。 [251] [[TrueType outline]] の[[可変フォント]]に於いては、 各[[グリフ]]の [F[left side bearing]] は [F[[CODE[xMin]]]] と等しくなければ[RUBYB[なりません][must]]。 [CODE[head]] の [F[[CODE[flags]]]] の第1ビットを設定しなければ[RUBYB[なりません][must]]。 [SRC[>>43, >>52]] 従って[[可変フォント]]の [[default instance]] の[[グリフ]]の [F[lsb]] は [CODE[glyf]] から直接得ることもできます。 [SRC[>>43]] [245] [[可変フォント]]の [[non-default instance]] の [[side bearing]] は [[default instance]] と異なることがあります。 [CODE[gvar]] [[表]]を使って interpolate された [[phantom point]] 座標から得るか、 または [[default instance]] の値に [CODE[HVAR]] [[表]]の variation data を適用して得ることができます。 [SRC[>>43]] [CODE[CFF2]] [[outline]] の [[variable font]] の [[left side bearing]] は [[non-default instance]] では [CODE[hmtx]] と [CODE[HVAR]] を総合して得る[RUBYB[べきです][should]]。 [SRC[>>43]] [50] [[グリフ]]の [F[right side bearing]] は、 [[グリフ]]の [F[left side bearing]] と[F[前進幅]]から求められます。 [[グリフ]]の [F[bottom side bearing]] は、 [[グリフ]]の [F[top side bearing]] と[F[前進高]]から求められます。 [SRC[>>44]] [250] [[グリフ]]の [F[lsb]] と違ってこれらは[[フォント]]ファイル中に明示的には書かれていません。 [63] [[TrueType outline]] の[[グリフ]]の [[advance width]] ([DFN[[VAR[aw]]]]) と [[left side bearing ([DFN[[VAR[lsb]]]]) は、 [[TrueType rasterizer]] の計算する[[グリフ]]の [[phantom point]] から得られます。 [CODE[hmtx]] [[表][OpenType表]]からも得られます。 [SRC[>>43]] [64] [[right side bearing]] ([DFN[[VAR[rsb]]]]) は、次の式によります。 [SRC[>>43]] [FIG(math)[ [VAR[rsb]] = [VAR[aw]] - ([VAR[lsb]] + [F[[CODE[xMax]]]] - [F[[CODE[xMin]]]]) ]FIG] [65] [VAR[pp1]], [VAR[pp2]] を [VAR[lsb]], [VAR[rsb]] を制御する [[TrueType]] [[phantom point]] とするとき、 その [[X軸]]方向の初期位置は、次の式によります。 [SRC[>>43]] [FIG(math)[ [VAR[pp1]] = [F[[CODE[xMin]]]] - [VAR[lsb]] [VAR[pp2]] = [VAR[pp1]] + [VAR[aw]] ]FIG] [114] [CODE[head]] の [F[[CODE[flags]]]] の第1ビットが設定されているときは、 すべての[[グリフ]]に於いて [VAR[pp1]] = 0 であり、 各[[グリフ]]の [F[[CODE[xMin]]]] と [F[[[left side bearing]]]] は等しくなければ[RUBYB[なりません][must]]。 [SRC[>>52]] [66] [[グリフ]]が [[contour]] を持たないとき、 [F[[CODE[xMin]]]], [F[[CODE[xMax]]]] は定義されません。 [CODE[hmtx]] の [[left side bearing]] は [N[0]] とする[RUBYB[べきです][should]]。 [SRC[>>43]] [294] [[グリフ]]の [F[top side bearing]] は、 ideographic glyph の[RUBYB[縦組み][vertical composition]]用に使う[[グリフ]]の[[原点]]に対して計測します。 [SRC[>>281]] [131] [CODE[hhea]] には [DFN[[F[[CODE[minLeftSideBearing]]]]]], [DFN[[F[[CODE[minRightSideBearing]]]]]] があり、 [CODE[hmtx]] のうち [[contour]] がある[[グリフ]]の [[lsb]], [[rsb]] = aw - (lsb + xMax - xMin) の最小値をそれぞれ表します。 [SRC[>>124]] [262] [CODE[vhea]] には [DFN[[F[[CODE[minTopSideBearing]]]]]], [DFN[[F[[CODE[minBottomSideBearing]]]]]] があり、 [[フォント]]の [[top side bearing]] measurement, [[bottom side bearing]] measurement の最小値を[[フォント設計単位]]で表します。 [SRC[>>78]] [257] [CODE[vhea]] の最小 [[top side bearing]], [[bottom side bearing]] と [CODE[vmtx]] の [[top side bearing]] は一貫していなければ[RUBYB[なりません][must]]。 [SRC[>>78]] [126] [F[[CODE[minLeftSideBearing]]]], [F[[CODE[minRightSideBearing]]]] は、 [[contour]] を持つ[[グリフ]]のみを使って計算する[RUBYB[べきです][should]]。 [SRC[>>124]] [REFS[ - [52] [CITE@en-us[[[head]] - Font header table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:29.000Z]], [TIME[2024-11-26T12:48:16.060Z]] ]REFS] ** 前進 [117] [[グリフ]]は、 [DFN[[F[[RUBYB[[[前進幅]]][advance width]]]]]], [DFN[[F[[RUBYB[[[前進高]]][advance height]]]]]]の 2つの[RUBYB[[[前進]]][advance]]の値を持ちます。 [118] 素朴には、[[原点]] (0, 0) と ([F[前進幅]], [F[前進高]]) が[[グリフ]]の描画域と考えることができます。 ;; [119] 実際には[[基線]]の関係で [VAR[y]] 方向はもう少し複雑です。 [120] [[文字のレンダリング]]の処理では、 [[現在位置]]に[[グリフ]]の[[原点]]を揃えて配置し、 次の[[グリフ]]のために[[現在位置]]を[F[前進幅]]または[F[前進高]]の分だけ移動します。 (より厳密には >>5) [121] 現在の一般的な[[仮名]]や[[漢字]]のような[[正方形]]の[[文字]]の場合は、 [[グリフ]]は[F[前進幅]]や[F[前進高]]の範囲に収まるように設計するのが普通です。 つまり[[グリフ]]の[F[外接箱]]は[F[前進幅]]や[F[前進高]]の範囲より小さくなります。 [122] しかしそうでない[[グリフ]]も作ることが出来ます。その場合、前後の[[グリフ]]と重なる可能性があります。 [[文字]]によっては (もちろん重なり方は調整しつつ) 意図的にそうすることがあります。 [123] [F[前進幅]], [F[前進高]]は[[グリフ]]ごとに固定です。 前後の[[グリフ]]の組み合わせによって[[字間]]を調整したいときは、 [[kerning]] 機能のような他の仕組みを使うことになります。 [110] [CODE[hmtx]] に [DFN[[F[[CODE[advanceWidth]]]]]] があります。 [[グリフ]]の[F[前進幅]]を[[フォント設計単位]]で表します。 [SRC[>>43]] [295] [CODE[vmtx]] に [DFN[[F[[CODE[advanceHeight]]]]]] があります。 [[グリフ]]の[F[前進高]]を[[フォント設計単位]]で表します。 [SRC[>>281]] [42] [CODE[hdmx]] [[表][OpenType表]]は[[グリフ]]の [[advance width]] を各[[フォントサイズ]]における[[画素]]単位の[[整数]]に変換した値を格納しています。 [SRC[>>41]] [58] [CODE[CFF ]] ([[CFF]] 1) [[outline]] は[F[前進幅]]を持ちます。 [[PostScript]] processor はこれを使います。 [[OpenType]] はこれを使いません。 [SRC[>>43]] ;; [113] [[Font Collection]] は、 同じ [CODE[CFF ]] であっても異なる [CODE[hmtx]] によって異なる[F[前進幅]]を[[グリフ]]に設定できます。 [SRC[>>43]] [59] [CODE[CFF2]] [[outline]] は [[advance width]] を持ちません。 [SRC[>>43]] [105] [[TrueType outline]] の[[グリフ]]の [[advance width]] は、 [[TrueType rasterizer]] の計算する[[グリフ]]の [[phantom point]] から得られます。 [CODE[hmtx]] [[表][OpenType表]]からも得られます。 [SRC[>>43]] [51] [[variable font]] の場合は記述された[[外接箱]]が得られた[[グリフ]]のものを表すとは限りません [SRC[>>44, >>52]]。 必要なら得られた[[グリフ]]の[[制御点]]等から計算する必要があります。 [[side bearing]] は [[phantom point]] を使って、あるいは [CODE[HVAR]] のデータから計算できます [SRC[>>43]]。 [CODE[CFF2]] [[outline]] の [[variable font]] の [[advance width]] は [[non-default instance]] では [CODE[hmtx]] と [CODE[HVAR]] を総合して得る[RUBYB[べきです][should]]。 [SRC[>>43]] [289] [[グリフ]]の[DFN[[F[[RUBYB[前進高][advance height]]]]]]は、 [[グリフ]]の[F[垂直原点]]の y 座標から初めて、下方向へと[RUBYB[前進][advance]]します。 [SRC[>>281]] [290] 前進した[RUBYB[終点][endpoint]]は、 原則として、 [[連なり]]の次の[[グリフ]]の[F[垂直原点]]の y 座標となります。 [SRC[>>281]] ;; [291] [CODE[vkrn]] などによって調整されます。 [130] [CODE[hhea]] に [DFN[[F[[CODE[advanceWidthMax]]]]]] があります。 [CODE[hmtx]] の[[前進幅]]の最大値とされます。 [SRC[>>124]] [261] [CODE[vhea]] に [DFN[[F[[CODE[advanceHeightMax]]]]]] があります。 [[フォント]]の[[前進高]] measurement の最大値を[[フォント設計単位]]で表します。 [SRC[>>78]] [258] [CODE[vhea]] の最大[[前進高]]と [CODE[vmtx]] の[[前進高]]は一貫していなければ[RUBYB[なりません][must]]。 [SRC[>>78]] [247] [CODE[head]] の [F[[CODE[flags]]]] の第4ビットは、 [[instruction]] が[[前進幅]]を[RUBYB[変更][alter]]する[RUBYB[かもしれない][may]] ([[前進幅]]は[[線形]]に[[拡縮]]しない[RUBYB[かもしれない][might]]) ことを表します。 [SRC[>>52]] [REFS[ - [41] [CITE@ja-jp[[[hdmx]] - Horizontal Device Metrics (OpenType 1.9) - Typography | Microsoft Docs]], [[PeterCon]], [TIME[2022-09-08T06:01:54.000Z]] - [44] [CITE@ja-jp[[[glyf]] - Glyf data table (OpenType 1.9) - Typography | Microsoft Docs]], [[PeterCon]], [TIME[2022-09-08T06:52:01.000Z]] - [43] [CITE@en-us[[[hmtx]] - Horizontal metrix table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:26.000Z]], [TIME[2024-12-02T13:07:00.661Z]] ]REFS] ** 幅 [HISTORY[ [142] [CODE[OS/2]] に [DFN[[F[[CODE[xAvgCharWidth]]]]]] があります。 [[グリフ]]の平均幅を表します。 [SRC[>>143]] [151] 版 [N[0]] から [N[2]] までは、仕様書が [[Basic Latin]] の[[文字]]に偏向していて、 その前提で [F[[CODE[xAvgCharWidth]]]] の値を[[行]]の平均長の推測に使えると考えられていました。 [SRC[>>143]] [152] [CH[a]] から [CH[z]] までと[[間隔]]に対して重みが定義されており、 その[[グリフ]]の幅に重みを掛けた総和を [N[1000]] で割ったものが [F[[CODE[xAvgCharWidth]]]] とされていました。 [SRC[>>143]] ;; [153] おそらく[[英語]]の[[小文字]]の出現頻度から決めた重みと思われます。 [144] 版 [N[3]] 以後、 [F[[CODE[xAvgCharWidth]]]] は、 [[フォント]]中の[[零幅]]ではない[[グリフ]]の [[escapement]] = 文字送り ([RUBYB[幅][width]]) の[[算術平均]]で、[[単位]]は[[フォント設計単位]]です。 [SRC[>>143]] [146] しかしこの計算方法に従っていない[[フォント]]があります。 [SRC[>>143]] [147] [CODE[OS/2]] の[F[版]]が [N[0]] から [N[2]] のときに作られ、 その後新しい版に変更したものの値はそのままというケースがあります。 [SRC[>>143]] ;; [148] [[versioningの失敗]]案件ですね。 [149] [[CJK]] の[[フォント]]で、 [F[[CODE[xAvgCharWidth]]]] が定義上の計算値の半分くらいになっているものがあります。 [SRC[>>143]] ;; [150] 事情がよくわからないのですが、[[半角]]の平均幅を設定するものとの認識があった (もしかしたらその前提の実装もあった) ということでしょうね。 [145] 実装者は、[[行]]の[RUBYB[配置][layout]]の計算においてこの値に依存しないよう[RUBYB[強く推奨][strongly recommended]]されています。 [[応用]]は、 [F[[CODE[xAvgCharWidth]]]] を実際の[[グリフ]]の[[前進幅]]の決定に使う[RUBYB[べきではありません][should not]]。 [SRC[>>143]] ]HISTORY] [REFS[ - [143] [CITE@en-us[[[OS/2]] - OS/2 and Windows metrics table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:30.000Z]], [TIME[2024-11-27T12:28:48.399Z]] ]REFS] [314] [[文字幅]]も参照。 * 小書き (添字) [154] [CODE[OS/2]] には [DFN[[F[[CODE[ySubscriptXSize]]]]]], [DFN[[F[[CODE[ySubscriptYSize]]]]]], [DFN[[F[[CODE[ySuperscriptXSize]]]]]], [DFN[[F[[CODE[ySuperscriptYSize]]]]]] があります。 [SRC[>>143]] [155] [[小書き]] ([[subscript]] / [[superscript]]) における[[フォント開発者]]によって[RUBYB[推奨][recommended]]される水平 (X) / 垂直 (Y) サイズを[[フォント設計単位]]で表します。 [SRC[>>143]] [156] [[正]]とする[RUBYB[べきです][should]]。 [[OS/2]] [[プラットフォーム]]では[[符号付き]]の値として実装されていました ([[正]]の値が期待されるにも関わらず)。 [SRC[>>143]] [157] 推奨されるサイズが numerics とその他など2つあるときは、 numeric size とする[RUBYB[べきです][should]]。 [SRC[>>143]] [158] [CODE[OS/2]] には [DFN[[F[[CODE[ySubscriptXOffset]]]]]], [DFN[[F[[CODE[ySubscriptYOffset]]]]]], [DFN[[F[[CODE[ySuperscriptXOffset]]]]]], [DFN[[F[[CODE[ySuperscriptYOffset]]]]]] があります。 [SRC[>>143]] [160] [[小書き]]における[[フォント開発者]]によって[RUBYB[推奨][recommended]]される水平 (X) / 垂直 (Y) の offset を[[フォント設計単位]]で表します。 [SRC[>>143]] [161] X は、 [RUBYB[[[正立]]][upright]]の[[グリフ]]では通常 [N[0]] です。 [[傾き]] ([[italic]] や [[slant]]) のある[[フォント]]の[[グリフ]]では、 傾きの角度を考慮した調整量を指定します。 [SRC[>>143]] [159] [[フォント]]が[[応用]]の必要とするすべての[[小書き]]の[[グリフ]]を持ち合わせていないとき、 [[応用]]は[[フォント]]の[[グリフ]]の[[縮小]]や、 他の[[フォント]]の[[グリフ]]で代用によって[[小書き]]の[[グリフ]]を代替できるのですが、 size の値が代替[[グリフ]]の[RUBYB[推奨][recommended]]の[RUBYB[公称幅][nominal width]]となります。 size の値が[[小書き]]に使う[[フォント]]の[[em]] サイズに[[写像]]されます。 offset の値が[[小書き]]の直前の[[グリフ]]の glyph escapement point からの[[小書き]]の[[グリフ]]の[[原点]] / [[基線]]の[RUBYB[推奨][recommended]]される位置を表します。 [SRC[>>143]] [239] [[可変フォント]]においては [CODE[MVAR]] に [DFN[[CODE[sbxo]]]], [DFN[[CODE[sbxs]]]], [DFN[[CODE[sbyo]]]], [DFN[[CODE[sbys]]]], [DFN[[CODE[spxo]]]], [DFN[[CODE[spxs]]]], [DFN[[CODE[spyo]]]], [DFN[[CODE[spys]]]] があります。 [SRC[>>143]] * SVG 字形配置 [86] [CODE[SVG ]] の[[グリフ]]は、 [[SVG文書]]内の[[座標系]]によって配置された図形を[[文字列]] (の[[グリフ]]列) の座標空間に配置することになります。 [87] [[SVG文書]]の default units は、[[フォント]]の[F[フォント設計単位]]と[RUBYB[等しい][equivalent]]です。 [SRC[>>85]] ;; [272] [[OpenType]] では[[フォント設計単位]]の値のほとんどは[[整数型]]で、 [[フォント設計単位]]の粒度が設計上の最小粒度になります。 [[SVG]] 側では[[小数]]を扱うことができ、 [CODE[SVG ]] に於いても特に制約がないので、 [[OpenType]] のこの制限を超えて細かい指定ができることになります。 [88] [[SVG]] の[[原点]] (0, 0) は、[[フォント]]側の design grid の[[原点]]に揃えます。 [VAR[y]] = 0 は、 text layout に使う既定の水平[[基線]]です。 [SRC[>>85]] [89] [[フォント]]側では [VAR[y]] 軸は下方向が[[正]]となりますが、 [[SVG]] の[[座標系]]では [VAR[y]] 軸は上方向が[[正]]となります。 [SRC[>>85]] 従って [[SVG文書]]単体で表示するのと上下逆転することになります。 [93] このため字形の大部分は [VAR[x]] が[[正]]、[VAR[y]] が[[負]]の[[象限]]に配置されることがあります。 一般的な図形編集では [VAR[x]] が[[正]]、[VAR[y]] が[[正]]の[[象限]]に配置するので、 例えば [CODE[svg]] [[要素]]の [CODE[viewBox]] [[属性]]を [CODE[0 1000 1000 1000]] のように設定して、 [[SVG]] [[座標系]]を [VAR[y]] 軸方向に [N[1000]] ずらしておく技法があります。 あるいは対象となる[[要素]]に [CODE[[[transform]]="translate(0,-1000)"]] と指定することでずらす技法があります。 [[フォント]]開発工具は、 設計環境から[[フォント]]内の形式へと適切に移すことが期待されています。 [SRC[>>85 (Note, 例示)]] [90] [[SVG文書]]の initial viewport の size は、 em square です。 すなわち、 [[高さ]] = [[幅]] = [CODE[head][head (OpenType)]] の [F[[CODE[unitsPerEm]]]] です。 [SRC[>>85]] [91] [CODE[svg]] [[要素]]の [CODE[viewBox]] [[属性]]で[[幅]]と[[高さ]]が指定されていて >>90 と異なるときは、 [[SVG]] [[利用者座標系]]の scale transformation の効果を持つことになります。 [CODE[svg]] [[要素]]の [CODE[height]] [[属性]]や [CODE[width]] [[属性]]が指定されているときは、 やはり[[座標系]]の scale transformation の効果を持つことになります。 [SRC[>>85]] [92] initial viewport の size は em square ですが、 [[viewport]] を [[clip]] しては[RUBYB[なりません][must not]]。 [CODE[svg]] [[要素]]は [CODE[clip]] [[特性]]の値が [CODE[auto]]、 [CODE[overflow]] [[特性]]の値が [CODE[visible]] があるものとみなします。 [CODE[svg]] [[要素]]に [CODE[clip]] [[特性]]や [CODE[overflow]] [[特性]]の違う値が指定されていても、無視しなければ[RUBYB[なりません][must]]。 [[フォント]]は [CODE[svg]] [[要素]]に [CODE[clip]] [[特性]]や [CODE[overflow]] [[特性]]を指定する[RUBYB[べきではありません][should not]]。 [SRC[>>85]] [94] [[グリフ]]の [[advance width]] は [CODE[hmtx]] の、 [[advance height]] は [CODE[vmtx]] の指定によります。 [SRC[>>85]] ;; [95] つまり他の形式の[[グリフ]]の場合と共通です。 [96] [[SVGアニメーション]]や[[CSSアニメーション]]に対応している場合でも、 [[グリフ]]の advance は[[アニメーション]]で変化しては[RUBYB[なりません][must not]]。 [SRC[>>85]] [98] [[グリフ]]の [[bounding box]] は[[フォント]]内に明示的には記述されません。 [[bounding box]] が必要なときは[[レンダリング]]した[[グリフ]]の “ink” bounding box を使う[RUBYB[べきです][should]]。 これは animated rendering と static rendering で違うかもしれません。 [SRC[>>85]] [97] [CODE[hmtx]] の [[left side bearing]], [CODE[vmtx]] の [[top side bearing]], [CODE[head][head (OpenType)]] の [F[[CODE[flags]]]] の第1ビットは、 [[SVG]] [[グリフ]]では使いません。 [SRC[>>85]] [REFS[ - [85] [CITE@en-us[SVG - Scalable vector graphics table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:32.000Z]], [TIME[2024-11-18T08:09:48.421Z]] ]REFS] * 選択と hit testing [81] 少なくても [[Windows]] の [[Chrome]] では、 [CODE[OS/2]] の [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] の[[行箱]]の上下の決定に寄与しているように見えます。 [82] [[縦書き]]の左右位置にも影響しているのかいないのか。 [SEE[ [[基線]] ]] * ブロック軸方向の位置と大きさ ** 基線 [SEE[ [[基線]] ]] ** ascender と descender [127] [CODE[hhea]] には [DFN[[F[[CODE[ascender]]]]]] と [DFN[[F[[CODE[descender]]]]]] があり、それぞれ[[フォント]]の [[typographic ascent]] と [[typographic descent]] を表します。 [[Apple]] が使います。 [SRC[>>124]] [136] [CODE[OS/2]] には [DFN[[F[[CODE[sTypoAscender]]]]]], [DFN[[F[[CODE[sTypoDescender]]]]]] があります。 [[フォント]]の [[typographic ascender]], [[typographic descender]] を[[フォント設計単位]]で表します。 [SRC[>>143]] [[Windows]] が使います。 [SRC[>>124]] [139] 新たな text-layout 実装は [CODE[OS/2]] の方が[RUBYB[推奨][recommended]]されます。 [[フォント]]開発者は[RUBYB[一貫した配置][consistent layout]]のため対象の応用の動作を評価して双方を使う[RUBYB[べきです][should]]。 [SRC[>>124]] [234] [[可変フォント]]においては [CODE[MVAR]] に [F[[CODE[sTypo[VAR[*]]]]]] に対応する [DFN[[CODE[hasc]]]], [DFN[[CODE[hdsc]]]] があります。 [SRC[>>143]] [259] [CODE[vhea]] の [N[1.0]] 版には [DFN[[F[[CODE[ascent]]]]]] と [DFN[[F[[CODE[descent]]]]]] があります。 [RUBYB[[[中央線]]][centerline]]から[RUBYB[前行][previous line]]の [[descent]]、 [RUBYB[次行][next line]]の [[ascent]] までの[[距離]]を[[フォント設計単位]]で表します。 [SRC[>>78]] [265] [CODE[vhea]] の [N[1.1]] 版には [DFN[[F[[CODE[vertTypoAscender]]]]]] と [DFN[[F[[CODE[vertTypoDescender]]]]]] があります。 vertical typographic ascender, vertical typographic descender を表します。 [RUBYB[垂直中央[[基線]]][vertical center baseline]]から CJK / ideographic glyph の[RUBYB[設計空間][design space]] ([[ideographic em box]]) の[RUBYB[右辺][right edge]], [RUBYB[左辺][left edge]]までの[[距離]]を[[フォント設計単位]]で表したものです。 [SRC[>>78]] [234] [[可変フォント]]においては [CODE[MVAR]] に [F[[CODE[ascent]]]] / [F[[CODE[descent]]]], [F[[CODE[sTypo[VAR[*]]]]]] に対応する [DFN[[CODE[vasc]]]], [DFN[[CODE[vdsc]]]] があります。 [SRC[>>78]] [184] [F[[CODE[sTypoAscender]]]] - [F[[CODE[sTypoDescender]]]] が [F[[CODE[unitsPerEm]]]] と等しいことは[RUBYB[一般的な要件][general requirement]]では''ありません''。 [[フォント]]が対応する主たる[[言語]]に適切な [[default line spacing]] になるように設定する[RUBYB[べきです][should]]。 [SRC[>>143]] [185] [[横書き]]だけでなく[[縦書き]]でも使う想定の[[CJK]][[フォント]]では、 [F[[CODE[sTypoAscender]]]], [F[[CODE[sTypoDescender]]]] の値は [[ideographic em-box]] の上辺 (top), 下辺 (bottom) を記述するものでなければ[RUBYB[なりません][required]]。 さもなくば[[縦書き]]時におかしくなります。 [SRC[>>143]] [266] [F[[CODE[vertTypoAscender]]]] と [F[[CODE[vertTypoDescender]]]] は、通常 [FRAC[[CODE[head]] の [F[[CODE[unitsPerEm]]]]][2]], −[FRAC[[CODE[head]] の [F[[CODE[unitsPerEm]]]]][2]] に設定します。 [SRC[>>78]] -*-*- [205] 普通は[[基線]]の上方向に [[ascender]] が、 [[基線]]と等しいか下方向に [[descender]] があります。 [206] この「普通」と違う状態がどの程度許されるのかは定かではありません。 [207] [[descender]] が[[基線]]より上に来るケースがあり得ることは仕様書でも暗示的に言及されています。 その場合は[[グリフ]]が通常存在する領域の外側に[[基線]]が来ることになります。 あまり一般的ではなさそうですが、おかしなことにはならなそうです。 [208] [[descender]] の方が [[ascender]] より上に来るようなケースはどうなのでしょう。 -*-*- [306] Windows ascender / descender まで含めて3つの[[横書き]] ascender / descender が (座標軸の関係で正負の違いがあるのを除けば) 同じ値のフォントもあれば、 違う値のフォントもあります。 [307] Windows 以外の2つの ascender / descender は定義文を素直に読むと同じ値になりそうなものですが、 実際には微妙に違った値になっていることもあります。何かの互換性の問題でそうなっているのでしょうか。 [308] [CODE[hhea]] のと Windows metrics が同じ値なのに typographic metrics だけが違う値になっていることがあります。 その[[フォント]]の場合は typographic metrics が間違っているようでした。 [CODE[USE_TYPO_METRICS]] が[[偽]]なのもあってか[[レンダリング]]には使われず制作者が気づいていないものと思われます。 この事例の場合はおそらく[[フォント]]制作ソフトウェアの既定値が設定された状態で、 [[フォント]]制作ソフトウェアで2つの metrics だけが変更され typographic metrics は変更されずに残ったのでしょう。 [309] こういう事案もあるので新しい実装は単純に typographic metrics だけを見るというわけにもいかないらしく悩ましいですね。 ** 行高 [128] [CODE[hhea]] には [DFN[[F[[CODE[lineGap]]]]]] があり、 [[typographic line gap]] を表します。 [[Apple]] が使います。 [SRC[>>124]] [129] [[負]]の値は、 [N[0]] として扱う legacy platform があります。 [SRC[>>124]] [137] [CODE[OS/2]] には [DFN[[F[[CODE[sTypoLineGap]]]]]] があり、 [[typographic line gap]] を[[フォント設計単位]]で表します。 [SRC[>>143]] [[Windows]] が使います。 [SRC[>>124]] [138] 新たな text-layout 実装は [CODE[OS/2]] の方が[RUBYB[推奨][recommended]]されます。 [[フォント]]開発者は[RUBYB[一貫した配置][consistent layout]]のため対象の応用の動作を評価して双方を使う[RUBYB[べきです][should]]。 [SRC[>>124]] [235] [[可変フォント]]においては [CODE[MVAR]] に [DFN[[CODE[hlgp]]]] があります。 [SRC[>>143]] [260] [CODE[vhea]] の [N[1.0]] 版には [DFN[[F[[CODE[lineGap]]]]]] がありますが、 [RUBYB[予約][reserved]]とされ [N[0]] に設定することになっています。 [SRC[>>78]] [267] [CODE[vhea]] の [N[1.1]] 版には [DFN[[F[[CODE[vertTypoLineGap]]]]]] があり、 [[フォント]]の vertical typograohic gap を表します。 [SRC[>>78]] [269] [[可変フォント]]においては [CODE[MVAR]] に [F[[CODE[lineGap]]]], [F[[CODE[sTypoLineGap]]]] に対応する [DFN[[CODE[vlgp]]]] があります。 [SRC[>>78]] ;; [270] 予約されている [CODE[lineGap]] と対応関係にあるこの値をどのように使えるのかは定かではありませんが。 [210] line gap は[[負]]の値にできます。それが何を意味するか、 >>129 以外には明言がありません。 >>129 および他に説明がないことから常識的に類推すれば、[[正]]の値の時と反対方向の「gap」 が生じるか、 [N[0]] とみなすかのどちらかが認められる挙動であるものの、 [N[0]] とみなすのは好ましからざる古い挙動である、という感じでしょうか。 -*-*- [182] [F[[CODE[sTypoAscender]]]], [F[[CODE[sTypoDescender]]]], [F[[CODE[sTypoLineGap]]]] は組み合わせて ([[横書き]]用の) [DFN[default line spacing]] を決定する[RUBYB[べきです][should]]。 [SRC[>>143]] [181] [F[[CODE[ascender]]]] / [F[[CODE[descender]]]] / [F[[CODE[lineGap]]]], [F[[CODE[usWinAscent]]]] / [F[[CODE[usWinDescent]]]] は legacy platform 実装が platform-specific の挙動で使っていたために、 これらは後方互換性の要件に縛られており、 実装を超えた一貫した layout が実現できません。 一方 [F[[CODE[sTypoAscender]]]], [F[[CODE[sTypoDescender]]]], [F[[CODE[sTypoLineGap]]]] は[[応用]]が[[文書]]を typographically correct で可搬な形で配置できることを意図したものです。 [SRC[>>143]] [183] [F[[CODE[fsSelection]]]] の [DFN[[F[[CODE[USE_TYPO_METRICS]]]]]] (第7ビット) は、 [F[[CODE[sTypo[VAR[*]]]]]] と [F[[CODE[usWin[VAR[*]]]]]] のどちらで default line metrics を決めるかを指定します。 [SRC[>>143]] [186] [F[[CODE[USE_TYPO_METRICS]]]] が設定されている場合、 [[応用]]は [F[[CODE[sTypoAscender]]]] - [F[[CODE[sTypoDescender]]]] + [F[[CODE[sTypoLineGap]]]] を[[フォント]]の [[default line spacing]] として使うことが[RUBYB[強く推奨されます][strongly recommended]]。 [SRC[>>143]] [231] [[可変フォント]]は [F[[CODE[USE_TYPO_METRICS]]]] を設定する[RUBYB[べきです][should]]。 [SRC[>>143]] [196] [F[[CODE[sTypo[VAR[*]]]]]] と [F[[CODE[usWin[VAR[*]]]]]] のどちらで [[default line spacing]] を決めるか [F[[CODE[USE_TYPO_METRICS]]]] をみる[[応用]]があります。 この挙動は新しい[[フォント]]でより好ましく可搬な配置を実現しつつも古い[[フォント]]を使った[[遺物]]の[[文書]]との互換性を保つ有用な実装方法です。 [SRC[>>143]] [230] [[可変フォント]]では、 [[default line metrics]] は常に [F[[CODE[sTypo[VAR[*]]]]]] で設定される[RUBYB[べきです][should]]。 [SRC[>>143]] [232] [[可変フォント]]では [CODE[hhea]] の [F[[CODE[ascender]]]] / [F[[CODE[descender]]]] / [F[[CODE[lineGap]]]], は [F[[CODE[sTypo[VAR[*]]]]]] と同じ値に設定する[RUBYB[べきです][should]]。 [SRC[>>143]] [209] [[default line spacing]] が[[負]]になってしまうような値の組み合わせだとどうなるのでしょう。 そのようなものが認められるとも認められないとも特に何も記述がありません。 実装は何か対処しておかないと[[行]]が上に進んでおかしな動作になりかねません。 [268] [[応用]]は、 ([CODE[vhea]] の [N[1.1]] 版の) [[OpenType]] [[フォント]]の single spaced vertical text の recommended line spacing を、 [[ideo embox width]] + [CODE[vhea]] の [F[[CODE[vertTypoLineGap]]]] により決定できます。 [SRC[>>78]] -*-*- [311] [[Windows]] の [[Chrome]] で [F[[CODE[USE_TYPO_METRICS]]]] を設定し''ない''と、 Windows descender から Windows ascender までが[[文字列の選択]]の対象範囲となります。 また、表示位置も (おそらく) その垂直中央で揃えられます。 [[行高]]はその高さになるわけではないようですが、 同じ文書の他のフォントの影響なのか、それとも他の ascender / descender の影響なのか調べていません。 [TIME[2025-02-02T07:42:33.900Z]] ;; [313] [[文字列の選択]]の範囲は [[hit testing]] の範囲でもあるために、 前後の[[行]]のクリックなどに支障が出ます。 [312] >>311 設定''する''とこの奇妙な挙動はなくなり、 [[基線]]揃え(?)で適切な位置に字形が表示され、選択範囲も想定される[[行高]] (typo ascender / descender の範囲?) になります。 [310] [CITE@en[Font metrics settings for desktop and web fonts — TypeDrawers]], [TIME[2025-02-02T07:29:13.000Z]], [TIME[2025-02-02T07:39:15.828Z]] ** フォント高 [187] [CODE[OS/2]] に [DFN[[F[[CODE[usWinAscent]]]]]], [DFN[[F[[CODE[usWinDescent]]]]]] があります。 「Windows ascender」 metric, 「Windows descender」 metric を[[フォント設計単位]]で表します。 [SRC[>>143]] [238] [[可変フォント]]においては [CODE[MVAR]] に [DFN[[CODE[hcla]]]], [DFN[[CODE[hcld]]]] があります。 [SRC[>>143]] [188] これらには clipping region の[[基線]]上の高さを指定する[RUBYB[べきです][should]]。 [SRC[>>143]] [189] [F[[CODE[sTypoAscender]]]] / [F[[CODE[sTypoDescender]]]], [F[[CODE[ascender]]]] / [F[[CODE[descender]]]] とよく似ていますが、大きな違いは描画の限界を示すことです。 [201] また、 [F[[CODE[sTypoDescender]]]] / [F[[CODE[descender]]]] は[[基線]]の上が[[正]]、下が[[負]]となるのに対し、 [F[[CODE[usWinDescent]]]] は[[基線]]の上が[[負]]、下が[[正]]となります。 [SRC[>>143]] [100] [[Windows]] では [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] を使って maximum black height を決定します。 [[Windows]] はこの両者の距離を Font Height といいます。 [SRC[>>99]] [190] [[Windows]] [[GDI]] 実装では、 [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] が [[TrueType]] [[rasterrizer]] の bitmap surface の size を決定するために使われます。 [[Windows]] [[GDI]] は [[TrueType]] glyph outline がこの範囲外にはみ出した時切り抜き (clip) します。 [SRC[>>143]] [191] 切り抜きが好ましからざるときは、 [F[[CODE[yMax]]]] [[以上]]や [F[[CODE[yMin]]]] [[以下]]に当たる値を指定する[RUBYB[べきです][should]]。 [SRC[>>143]] [199] 古い版の [[OpenType]] 仕様書は、 [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] を [[Windows "ANSI" character set]] のすべての[[文字]]の [CODE[yMax]] / [CODE[yMin]] (の最大・最小?) に当たる値とすることを[RUBYB[提案][suggested]]していました。 [SRC[>>143]] [200] 新しいフォントでは、 [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] は対応する主要な[[言語]]をもとに決定するべきであり、 長い[[グリフ]]や [[mark]] positioning に必要になる追加分の高さも考慮するべきです。 [SRC[>>143]] ;; [202] >>193 の通り既定の位置を基に切り抜きの範囲は決まりますから、 切り抜きに関して言えば[[マーク]]が上下に追加されることは特別な配慮は不要です。 しかし >>197 のような行とみなされる範囲に[[マーク]]が含まれることは好ましいでしょうから、 その意味での配慮はやはり必要です。 [233] [[可変フォント]]では、 [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] は[RUBYB[推奨][recommended]]される clipping rectangle を指定するために使う[RUBYB[べきです][should]]。 [SRC[>>143]] [101] [[Windows]] は [F[[CODE[yMax]]]] と [F[[CODE[yMin]]]] の外側の [[pixel]] をくり抜きます。 [[TrueType]] instruction は actual scaled and rounded values と異なる Font Height を生じることがあって、 Font Height を厳密に [F[[CODE[yMax]]]] と [F[[CODE[yMin]]]] に置くと 「lost pixel」 が生じることになります。 [SRC[>>99]] [102] この grid fitting の lost pixel 問題を避けるために [DFN[[CODE[VDMX]]]] [[表][表 (OpenType)]]に修正した高さを記述できます。 [SRC[>>99]] [192] [CODE[VDMX]] があって current device aspect ratio と rasterization size に対するデータが存在するとき、 [CODE[VDMX]] のデータが [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] を上書きします。 [SRC[>>143]] [193] [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] の指定する範囲は[[グリフ]]の既定の位置に対するものです。 [CODE[GPOS]] や [CODE[kern]] による配置が適用される前の状態を指します。 [SRC[>>143]] ;; [194] [[Windows]] の [[GDI]] の実装の挙動として説明されているということは、 他の実装はこれに従う必要はないということでしょうか。 [195] [[遺物]]の[[応用]]の中には、 [F[[CODE[usWinAscent]]]] と [F[[CODE[usWinDescent]]]] から [[default line spacing]] を決めるものがあります。これは[RUBYB[強く非推奨][strongly discouraged]]です。 [F[[CODE[sTypo[VAR[*]]]]]] から決める[RUBYB[べきです][should]]。 [SRC[>>143]] [197] [F[[CODE[sTypo[VAR[*]]]]]] を使って [[default line spacing]] を決める[[応用]]であっても、 [F[[CODE[usWin[VAR[*]]]]]] を使って clipping region の size を決定できます。 [[応用]]によっては clipping region を使って編集時に再描画するべき display surface の部分を決めたり、 text が選択されたときに選択[[矩形]]を描く大きさを決めたりします。 これらは [F[[CODE[usWin[VAR[*]]]]]] の正統な用法です。 [SRC[>>143]] ;; [198] ということは clipping してレンダリングされてしまうことを防ぐために余裕を持たせてあまりに大きな値を [F[[CODE[usWin[VAR[*]]]]]] に指定してしまうと、上下の[[行]]を隠すように選択矩形が描画されてしまうリスクがあるということです。 再描画範囲の決定にしても、上下の[[行]]と被ってしまうと、上下の[[行]]の再描画まで必要だと[[応用]]は判断しないといけないはずですが、この >>197 のような仕様書の書き方だとそこまで考えないで実装してしまいそうです。。。 従って安全のため [F[[CODE[usWin[VAR[*]]]]]] は [[default line spacing]] とそうかわらないように指定するべきということになりそうです。 [REFS[ - [99] [CITE@en-us[[[VDMX]] - Vertical Device Metrics (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:16.000Z]], [TIME[2024-11-26T11:21:58.885Z]] ]REFS] ** [CODE[vertical-align]] [83] [[CSS]] の [CODE[vertical-align]] ([CODE[baseline-shift]]) では、選ばれた[[基線]]を基準に、上方 ([[横書き]]の[[上]]) を[[正]]とする値を使います。 [84] その移動量は [CODE[]] か [CODE[]] で、後者のときは [CODE[line-height]] に対する割合となります。 ** 文字高 [203] [CODE[OS/2]] に [DFN[[F[[CODE[sxHeight]]]]]], [DFN[[F[[CODE[sCapHeight]]]]]] があります。 [SRC[>>143]] [237] [[可変フォント]]においては [CODE[MVAR]] に [DFN[[CODE[xhgt]]]], [DFN[[CODE[cpht]]]] があります。 [SRC[>>143]] [204] [F[[CODE[sxHeight]]]] は、[[基線]]と non-ascending な[[小文字]]の[RUBYB[近似高][approximate height]]との距離を[[フォント設計単位]]で指定する [[metric]] です。 [SRC[>>143]] [216] [F[[CODE[sCapHeight]]]] は、[[基線]]と[[大文字]]の[RUBYB[近似高][approximate height]]との距離を[[フォント設計単位]]で指定する [[metric]] です。 [SRC[>>143]] [211] [F[[CODE[sxHeight]]]], [F[[CODE[sCapHeight]]]] は通常は[RUBYB[書体][type]]設計者が指定するものです。 [SRC[>>143]] [212] [[遺物]][[フォント]]の変換などでそれが叶わないときは、 [CC[U+0078]] [CH[x]], [CC[U+0048]] [CH[H]] の[[グリフ]]の unscaled で unhinted な[[グリフ]] [[bounding box]] の上辺 (top) と等しく設定する[RUBYB[ことができます][may]]。 [SRC[>>143]] [213] [CC[U+0078]], [CC[U+0048]] の[[グリフ]]がないときは、 [N[0]] とする[RUBYB[べきです][should]]。 [SRC[>>143]] [219] 特に説明されていませんが、[[負]]にもなるようです。 普通はないのでしょうが、該当部分が[[基線]]の下に来るときは[[負]]の値を指定することになると思われます。 [220] [N[0]] は該当部分がちょうど[[基線]]と一致する場合と適当な値がない場合 (>>213) があり得ます。前者になることはあまりないので、さほど問題にはならないのでしょう。 [214] [F[[CODE[sxHeight]]]] が指定されている場合は、フォント[RUBYB[置換][substitution]]に使うことができます。 この値に基づき[[拡縮]]して、 他の[[フォント]]の見かけの大きさに近似できます。 [SRC[>>143]] [215] [F[[CODE[sCapHeight]]]] が指定されている場合は、 [[ミリメートル]]単位の[[大文字]]高で[RUBYB[書体][type]]サイズを指定する[RUBYB[系][system]]で使えます。 [SRC[>>143]] [217] [F[[CODE[sCapHeight]]]] は[RUBYB[揃え用][alignment]]の [[metric]] としても使えます。 例えば [[drop capital]] の上辺 (top) を [[text]] の最初の[[行]]の [F[[CODE[sCapHeight]]]] [[metric]] に揃えることができます。 [SRC[>>143]] ;; [218] 説明から明らかなように、 [[ラテン文字]]に特化した機能です。 [[ラテン文字]]と似た構造を持つ[[ギリシャ文字]]や[[キリル文字]]などの多くの[[アルファベット]]系[[文字]]体系でも有用と考えられます。 (しかし他の多くの[[文字体系]]では必ずしも有意義でないことには注意が必要です。) ** 線 [162] [CODE[OS/2]] に [DFN[[F[[CODE[yStrikeoutSize]]]]]] があります。 [SRC[>>143]] [163] [F[[CODE[yStrikeoutSize]]]] には[[打ち消し線]] (strikeout stroke) の厚さ (thickness) を[[フォント設計単位]]で指定します。 [SRC[>>143]] [164] [F[[CODE[yStrikeoutSize]]]] の値は[[正]]とする[RUBYB[べきです][should]]。 [[OS/2]] [[プラットフォーム]]では[[符号付き]]の値として実装されていました ([[正]]の値が期待されるにも関わらず)。 [SRC[>>143]] [165] [F[[CODE[yStrikeoutSize]]]] の値は通常は [[em dash]] の厚さとする[RUBYB[べきです][should]]。 [SRC[>>143]] [166] [F[[CODE[yStrikeoutSize]]]] は [CODE[post]] の underline thickness と一致する[RUBYB[べきです][should]]。 [SRC[>>143]] [167] [CODE[OS/2]] に [DFN[[F[[CODE[yStrikeoutPosition]]]]]] があります。 [SRC[>>143]] [168] [F[[CODE[yStrikeoutPosition]]]] には[[基線]]に対する[[打ち消し線]] (strikeout stroke) の上辺 (top) の位置 ([DFN[strikeout position]]) を[[フォント設計単位]]で指定します。 [[正]]は[[基線]]の上、[[負]]は[[基線]]の下を表します。 [SRC[>>143]] [169] [[strikeout position]] は [[em dash]] と揃えることが[RUBYB[提案されます][suggested]]。 [SRC[>>143]] [170] [[strikeout position]] は[RUBYB[標準文字][standard character]]の認識と干渉する[RUBYB[べきではなく][should not]]、 従って [[crossbar]] と揃える[RUBYB[べきではありません][should not]]。 [SRC[>>143]] ;; [171] [[crossbar]] について特に説明はありませんが、一般的解釈によれば [CH[e]] や [CH[t]] や [CH[A]] のような字形内の横線のことをいいます。 標準文字というのもよくわかりませんが、 [[em dash]] のような記号、句読点類を除いた一般的な [[letter]] などを指すのでしょうか。 [236] [[可変フォント]]においては [CODE[MVAR]] に [DFN[[CODE[strs]]]], [DFN[[CODE[stro]]]] があります。 [SRC[>>143]] -*-*- [176] [CODE[post]] に [DFN[[F[[CODE[underlinePosition]]]]]] があります。 [SRC[>>174]] [177] [F[[CODE[underlinePosition]]]] は、 [[下線]]の上辺 (top) の [VAR[y]] 座標の[RUBYB[提案][suggested]]です。 [SRC[>>174]] [178] [CODE[post]] に [DFN[[F[[CODE[underlineThickness]]]]]] があります。 [SRC[>>174]] [179] [F[[CODE[underlineThickness]]]] は、 [[下線]]の厚み (thickness) の[RUBYB[提案][suggested]]値です。 通常は [CC[U+005F]] [CH[_]] の厚みと一致する[RUBYB[べきで][should]]、 [CODE[OS/2]] の strikeout thickness とも一致するべきです。 [SRC[>>174]] ;; [180] 従って [CH[_]] と [[em dash]] と[[下線]]と[[打ち消し線]]が同じ太さになるべき、 ということです。 [241] [[可変フォント]]においては [CODE[MVAR]] に [DFN[[CODE[undo]]]], [DFN[[CODE[unds]]]] があります。 [SRC[>>143]] * ブロック軸と成す角度 [172] [[斜体]]を考慮した配置: >>161 [173] [CODE[post]] に [DFN[[F[[CODE[italicAngle]]]]]] があります。 [SRC[>>174]] [175] [CODE[italicAngle]] は、 [[italic]] [[角度]]を表します。 [[垂直]]からの[[度数]]を[[反時計回り]]で表します。 [N[0]] は[[正立]]であり、 [[右]]に傾くと[[負]]となります。 [SRC[>>174]] [242] [[可変フォント]]においてはこれに直接対応するものがありません。 [[variation instance]] でこれに相当する値は、 [[variation instance]] を選択するのに使った [CODE[slnt]] [[user coordinates]] から得られます。 [SRC[>>174]] [REFS[ - [174] [CITE@en-us[[[post]] — PostScript Table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:18.000Z]], [TIME[2024-11-28T11:59:35.253Z]] ]REFS] ** caret [133] [CODE[hhea]], [CODE[vhea]] に [DFN[[F[[CODE[caretSlopeRise]]]]]], [DFN[[F[[CODE[caretSlopeRun]]]]]] があります。 [SRC[>>124, >>78]] [134] [[cursor]] [SRC[>>124]], [[caret]] [SRC[>>78]] の [[slope]] を [FRAC[rise][run]] として表すとされます。 [[垂直]]のとき [F[[CODE[caretSlopeRise]]]] を [N[1]] とし、 [F[[CODE[caretSlopeRun]]]] を [N[0]] とします。 [SRC[>>124, >>78]] [[水平]]のとき [F[[CODE[caretSlopeRise]]]] を [N[0]] とし、 [F[[CODE[caretSlopeRun]]]] を [N[1]] とします。 [SRC[>>78]] [140] [[可変フォント]]に於いては [CODE[MVAR]] に [DFN[[CODE[hcrs]]]] / [DFN[[CODE[hcrn]]]], [DFN[[CODE[vcrs]]]] / [DFN[[CODE[vcrn]]]] があります。 [SRC[>>124, >>78]] [264] [RUBYB[[[縦書き]]フォント][vertical font]]では[[水平]]の [[caret]] が最善です。 [SRC[>>78]] [135] [CODE[hhea]], [CODE[vhea]] に [DFN[[F[[CODE[caretOffset]]]]]] があります。 [[グリフ]]における [[slanted]] highlight [SRC[>>124]] ([[slanted]] glyph 上の highlight [SRC[>>78]]) の[RUBYB[見栄えが最も良くなる][best appearance]]ために[RUBYB[ずらす][shifted]]べき量を表します。 非 [[slanted]] な[[フォント]]では [N[0]] とします。 [SRC[>>124, >>78]] [141] [[可変フォント]]に於いては [CODE[MVAR]] に [DFN[[CODE[hcof]]]], [DFN[[CODE[vcof]]]] があります。 [SRC[>>124, >>78]] * フォントサイズ [248] [CODE[head]] に [DFN[[F[[CODE[lowestRecPPEM]]]]]] があります。 [SRC[>>52]] [249] 最小可読サイズを[RUBYB[[[画素]]][pixel]]単位で表します。 [SRC[>>52]] [271] 欄名から推察するに 1 [[em]] の長さを [[pixel]] 単位で表したものなのでしょう。 [221] [CODE[OS/2]] には [DFN[[F[[CODE[usLowerOpticalPointSize]]]]]], [DFN[[F[[CODE[usUpperOpticalPointSize]]]]]] があります。 [SRC[>>143]] [222] 複数の [[optical style]] がある[[フォント]]で使います。 [SRC[>>143]] [223] [F[[CODE[usLowerOpticalPointSize]]]] は、[[フォント]]が設計されている size の範囲の[RUBYB[下端値][lower value]]です。 指定された値は範囲に''含まれます''。 [SRC[>>143]] [228] [F[[CODE[usUpperOpticalPointSize]]]] は、[[フォント]]が設計されている size の範囲の[RUBYB[上端値][upper value]]です。 指定された値は範囲に''含まれません''。 [SRC[>>143]] [226] [F[[CODE[usLowerOpticalPointSize]]]] < [F[[CODE[usUpperOpticalPointSize]]]] でなければ[RUBYB[なりません][must]]。 [F[[CODE[usUpperOpticalPointSize]]]] の最小値は [N[2]] です。 [F[[CODE[usLowerOpticalPointSize]]]] の最大値は [N[0xFFFE]], [F[[CODE[usUpperOpticalPointSize]]]] の最大値は [N[0xFFFF]] です。 [N[0xFFFF]] は[[∞]]を意味します。 [SRC[>>143]] [225] 同じ typographic family における他の optical size variant の[[フォント]]で上端値が下端値となっていることが期待されます。 一連の optical size variant [[フォント]]群のうち optical size が最小の[[フォント]]は [F[[CODE[usLowerOpticalPointSize]]]] を [N[0]] とする[RUBYB[べきで][should]]、各[[フォント]]の範囲に隙間や重複はない[RUBYB[べきです][should]]。 [227] 複数の optical size variants で設計されていない[[フォント]]では [F[[CODE[usLowerOpticalPointSize]]]] を [N[0]], [F[[CODE[usUpperOpticalPointSize]]]] を [N[0xFFFF]] とする[RUBYB[べきです][should]]。 [SRC[>>143]] [224] [[単位]]は [[TWIPs]] で、 1 [[Twip]] = [FRAC[1][20]] ポイント = [FRAC[1][1440]] インチです。 [SRC[>>143]] [229] これらの欄は [CODE[STAT]] によって[RUBYB[上書き][superseded]]されました。 [SRC[>>143]] [240] [[可変フォント]]において直接対応するものはありません。 異なる size を対象とする variation は、 [CODE[opsz]] [[variation axis]] で実装することになっています。 [[可変フォント]]が [CODE[opsz]] [[variation axis]] に対応するときは、 これらの欄は [CODE[opsz]] 軸の [CODE[fvar]] 表の [CODE[minValue]] と [CODE[maxValue]] と同じ値にすることが[RUBYB[できます][can]]。 [SRC[>>143 ([I[Note]])]] * ヲコト点 [2] [[ヲコト点座標]] * 関連 [72] [[Adobe Font Metrics File Format]] * メモ