横書き用座標値

縦書き用座標値

[77] 横書き用の座標値を格納する hhea, hmtx に対して、 縦書き用の vhea (vertical header table) >>78 と vmtx (vertical metrics table) >>103 があります。

[274] OpenType vertical font は vhea と vmtx が必須 (require) です。 >>103

[254] vhea のデータは、 vmtx のデータと一貫していなければなりません (must) 。 >>78

[79] 縦書き用のフォントでは vhea を使うことになっていますが >>78、 Windows の Chrome, Firefox とも vhea がないからといって縦書き表示に特別支障となることは無さそうです。 2023-11-11T11:24:49.00Z

[80] vhea には vmtx 用のグリフ数の欄がありますが、 Chrome, Firefox とも vmtx が存在しなくてもエラーにはならないようです。 (一方 hmtx がないとエラーになります。)

[273] vertical metrics coordinate system >>103

[275] グリフの縦書き原点 (vertical origin) の y 座標 (coordinate) は、 グリフの tsb + グリフの bounding box の top (= y の最大) です。 >>103

[283] 実装は、 CFF または CFF2 のグリフであり、 フォントに VORG 表がある場合は、 VORG に指定された値でこれに替えることができます (し、定義通りの計算もできます)。 >>103

[279] 縦書き原点のy座標の算出に必要なグリフの外接箱の上辺の値は glyf には入っています (>>62) が、 CFF や CFF2 には入っていないので計算が必要です (>>278)。 この計算を省略して応用が正確性と性能を向上させられるよう、 VORG 表を使うことができます (が、必須ではありません (optional) )。 >>103, >>281

[282] VORG は CFF や CFF2 の OpenType フォントでのみ使えます (may) 。 TrueType outline データの OpenType フォントでは無視しなければなりません (must) 。 >>281

[286] ORG の defaultVertOriginY や vertOriginY では、 グリフの縦書き原点のY座標をフォントの設計座標系 (design coordinate system) において表します。 >>281

[287] グリフの垂直原点の x 座標 (coordinate) は、 xmtx には指定されません。 >>281

[288] 縦書き (vertical writing) 実装は、 BASE 表に基線値があれば、 グリフを 望ましい (desired) 垂直基線に対して適切に x 方向で揃えるよう使うことができます (may) 。 >>281

グリフ位置決定

[5] TrueType では、 グリフの位置は基準となる pen point (pen position) からの配置 (placement) と前進 (advance) の2値で決まります。 すなわち、 現在の pen point からテキスト (text) の線に対して、 配置量だけ移動したところにグリフを置きます。 そして次のグリフの pen point を前進量だけ移動したところに置きます。 >>3

[8] TrueType における配置と前進は、 横書きではX軸, 縦書きではY軸の1次元値です。 >>3

• [7] 左横書きでは配置量は left side bearing (horiBearingX) となります。 前進量は advance width (horiAdvance) となります。 >>3 グリフは最初の pen point から右へ右へと並べられていきます。
• [9] 上縦書きでは配置量は vertBearingY となります。 前進量は vertAdvance となります。 >>3 グリフは最初の pen point から下へ下へと並べられていきます。

[10] TrueType では、 kern 表を使って2つのグリフの間の空間の増減を指定できます。 >>3 前のグリフの前進量に kern による調整量を足し合わせることで適切なスペースに調整できます。

[11] OpenType では、 GPOS 表を使って配置と前進を X軸, Y軸の2次元で指定できます。 値はフォント単位によります。 >>3

• [13] 配置操作で指定する (X,Y) 値は、 書字方向に関わらず、 常に典型的な直交座標系 (Cartesian coordinate system) (左側の基線に原点 (origin at the baseline of the left side) ) 内にあります。 >>3
  • [104] 書字方向に関わらずグリフは同じ座標系に描画できるのでフォント設計者に特に便利です。 >>3
• [14] 前進は左横書きではX軸方向に advance width 分加算 (右移動) し、 右横書きではX軸方向に advance width 分減算 (左移動) します。 >>3 上縦書きではY軸方向に advance height 分加算 (下移動) します。

[12] GPOS 表では更に装置依存の調整もできます。 >>3

[17] GPOS による位置調整は、 lookup によって一致条件と一致した場合の挙動が記述されますが lookup 、 同じグリフに対する複数の lookup による指定は、蓄積されていきます。 >>3

• [19] GPOS lookupType 1 では、 単一のグリフに対して、 X軸とY軸の配置と前進 (のそれぞれの加算量) を指定できます。 >>3
• [20] GPOS lookupType 2 では、 2つのグリフの組におけるそれぞれのグリフに対して、 X軸とY軸の配置と前進 (のそれぞれの加算量) を指定できます。 >>3

[75] GPOS では kern 機能でカーニング指定ができますが、 その他の機能でも同様の位置調整を行えます。

[68] JstfMax lookup では justification において加除するX軸とY軸の配置と前進の最大値を指定できます。 実装はこれを使って 0 以上指定された値以下の調整を行えます。 >>67

[76] 結合文字関係固有の挙動は、結合文字のレンダリングの項を参照。

[74] GPOSのCursive Attachment Positioningについて - にせねこメモ, 2023-11-06T08:49:59.000Z https://nixeneko.hatenablog.com/entry/2017/01/14/200258

curs

添付点

[6] OpenType では、 GPOS 表を使ってグリフ添付点 (glyph attachment point) によるグリフ間の位置調整も可能です。 >>3

[16] 添付点は基底グリフとダイアクリティカルマークの位置調整のために、 あるいは続け字 (cursive) における前後のグリフの位置調整のために使えます。 >>3

[15] OpenType ではグリフは0個以上の添付点 (attachment point) を持つことが出来ます。 >>3 それぞれ上のダイアクリティカルマーク位置、 下のダイアクリティカルマーク位置といったように使います。

[21] GPOS lookupType 3 (cursive attachment positioning) では、 グリフの entry point anchor と exit point anchor を設定できます。 両 point anchor は、 位置 (X軸座標と Y軸座標の組) を指定します。 >>3

[24] 2つのグリフを並べるとき、1つ目のグリフの exit point から 2つ目のグリフの entry point へと続くようにします。

[23] line-layout direction の調整については、 論理順で1つ目のグリフの前進を調整します。 結果的に2つ目のグリフが移動されて anchor 位置を揃えます。 >>3

[25] cross-stream direction の調整については、 一方のグリフの配置を調整して他方のグリフと anchor 位置を揃えます。 RIGHT_TO_LEFT が 0 の場合、 2つ目のグリフを調整します。 RIGHT_TO_LEFT が 1 の場合、 1つ目のグリフを調整します。 >>3

[26] entry point / exit point の指定されたグリフが続く場合、 そのグリフ列全体の配置が連続的に影響されていきます。 RIGHT_TO_LEFT が 0 なら、 最初のグリフが基線基準で配置され、 以後どんどんずれていく形になります。 RIGHT_TO_LEFT が 1 なら、 最後のグリフが基線基準で配置され、 それに向けてどんどんずれが解消してく形になります。

[27] RIGHT_TO_LEFT フラグは lookup の lookupFlag ビット欄の第0ビットです。 >>28 lookup の条件を記述する他のフラグと違って RIGHT_TO_LEFT フラグは lookupType 3 のグリフ位置調整にだけ作用します。

[31] GPOS lookupType 4 (Mark-to-Base Attachment Positioning, MarkBasePos) は、 基底グリフとマークグリフの組み合わせについて、 両グリフにそれぞれの anchor point を指定するものです。 >>3

[34] GPOS lookupType 5 (Mark-to-Ligature Attachment Positioning, MarkLigPos) は、 合字グリフとマークグリフの組み合わせについて、 両グリフにそれぞれの anchor point を指定するものです。 >>3

[37] GPOS lookupType 6 (Mark-to-Mark Attachment Positioning, MarkMarkPos) は、 基底となるマークグリフ mark2 とそれに付加するマークグリフ mark1 の組み合わせについて、 両グリフにそれぞれの anchor point を指定するものです。 >>3

[35] 基底グリフの場合は anchor point は1組だけ指定できます。 合字グリフは見かけ上複数の構成部品 (component) があるかもしれないので、 anchor point をそれに合わせて複数組設定できます。 >>3

[32] マークグリフは、基底グリフと互いの anchor point が揃うように配置を調整します。 マークグリフの位置決定は、 基底グリフの前進後の pen point を基準とします。 基底グリフの配置は変更しません。 両グリフの前進は変更しません。 >>3

[36] 合字グリフの場合も基底グリフと同じようにします。 >>3 ただし合字グリフのときは複数組ある(かもしれない) anchor point のいずれを選ぶかが問題となります。 文字のレンダリング

[38] マークグリフ同士の場合も基底となるマークグリフ mark2 に対して同じようにします。 >>3

[22] 複数の lookup の指定は蓄積されることになっていますが >>3、 適用されるべき entry point anchor, exit point anchor, マークグリフ用の anchor point が重複するときどう処理するべきかは不明です。 そのような指定は意味を持ちませんから、 フォントはそのような lookup を持つべきではないのでしょう。

[39] 基底グリフまたは合字グリフとマークグリフとの関係による anchor point とマークグリフとマークグリフとの関係による anchor point の両方が適用可能なときは、 マークグリフとマークグリフの anchor point が優先されることを意図していると考えるのが自然です。

[69] JstfMax lookup で添付点を指定することは OpenType 仕様上明確に禁止されていませんが、 その意味が定められていません。 >>103 添付点と「最大値」という JstfMax lookup の性質はなじまないので、 利用ではないかもしれません。 (justification によって添付点が変化するべきなら、 JstfMax lookup ではなく有効または無効にするべき lookup として別に記述できます。 JSTF )

可変フォント

HVAR, VVAR, MVAR

外接箱

[54] グリフの外 (がい) 接 (せつ) 箱 (ばこ) (bounding box) は、 グリフのすべての制御点を含む最小の矩形です。 >>52

[62] TrueType outline のグリフの外接箱は、 glyf 表のグリフデータによります。 >>43, >>103

[45] glyf 表の TrueType outline グリフデータは、 xMin, yMin, xMax, yMax の4つの int16 値を持ちます。 >>44

[47] TrueType outline グリフのこの4値はグリフの点 (on-curve point も off-curve point も) の座標データから直接得ます。 rasterrizer が計算した phantom point は算入しません。 >>44

[46] TrueType outline グリフの外 (がい) 接 (せつ) 矩 (く) 形 (けい) (bounding rectangle) は、 左下 (xMin, yMin)、 右上 (xMax, yMax) の方形です。 >>44

[278] CFF や CFF2 の外接箱は、 CharString データから算出することになります。 >>103

[53] head 表は、 xMin, yMin, xMax, yMax の4つの int16 値を持ちます。 >>52

[55] head 表のこの4値は、 フォント中のすべてのグリフを含む外接箱を表します。 contour なきグリフは無視します。 >>52

[132] hhea に xMaxExtent があります。 lsb + (xMax - xMin) の最大値を表します。 >>124

[263] vhea に yMaxExtent があります。 tsb + (yMax - yMin) の最大値を表します。 >>124

[125] xMaxExtent は、 contour を持つグリフのみを使って計算するべきです (should) 。 >>124

[246] 可変フォントでは制御点の座標値が変わることがありますから、グリフの outline やグリフの実現値を構成するすべての点の tight bounding rectangle は、 グリフの既定実現値のものより大きかったり小さかったりします。 head の xMin, xMax, yMin, yMax は実現値の derived glyph outline を包含することもあれば、 そうでないこともあります。 非既定実現値のフォントのグリフを包含する bounding rectangle が必要な応用は、 実現値の derived glyph outline を処理して決定するべきです (should) 。 >>52

side bearing

[106] side bearing はグリフの contour の外側のアキを指します。 上下左右にあるうち、

• [107] left side bearing (LSB) は、 グリフの配置のための現在位置 (原点) からグリフの contour の左端までの長さです。 contour が現在位置より左まで伸びているときは、負の値になります。
• [108] right side bearing (RSB) は、 グリフの配置のための現在位置 + グリフの前進幅の位置から グリフの contour の右端までの長さです。 contour が前進幅より右まで伸びているときは、負の値になります。
• [292] top side bearing (TSB) は、 グリフの配置のための現在位置 (垂直原点) からグリフの contour の上端までの長さです。 contour が現在位置より上まで伸びているときは、負の値になります。
• [293] bottom side bearing (BSB) は、 グリフの配置のための現在位置 + グリフの前進高の位置から グリフの contour の下端までの長さです。 contour が前進幅より下まで伸びているときは、負の値になります。

[256] side bearing は sidebearing とも綴ります。 OpenType 仕様書でも一貫性無く混用されています。 一応、単体のときは side bearing と綴りがち、 修飾語になるときは sidebearing と綴りがちという傾向は見られます。

[57] hmtx に lsb があります。 グリフの left side bearing をフォント設計単位で表します。 >>43

[296] vmtx に topSideBearing があります。 グリフの top side bearing をフォント設計単位で表します。 >>281

[111] グリフの lsb の値とグリフを構成する制御点の最左の座標 (xMin) を一致させることが一般的のようです。そうするとグリフの局所座標系の原点と現在位置が一致して、 フォントの編集時にわかりやすくなります。

[243] glyf の xMin と lsb は同じかもしれませんが、 違うこともあります。 >>43

[244] head の flags の第1ビットは、 left side bearing point at x = 0 を意味するとされています。 TrueType rasterizer にのみ関係します。 >>52

[60] CFF や CFF2 のグリフデータには xMin = lsb, xMax を明示的には含みません。 side bearing は CharString データに暗示的に含まれていて、 CFF / CFF2 rasterizer から得られます。 >>43

[252] しかし layout engine によっては CFF や CFF2 の場合でも hmtx の lsb を使うかもしれません (may) 。 >>43

[61] フォント生成ツールは、 left side bearing と CFF / CFF2 outline の CharString が暗示する xMin が一致するようにするべきです (should) 。 >>43

[49] xMin が lsb と等しくなるようにグリフ座標を取ると scaler には都合がいいです。 >>44 すべてのグリフがそうである場合には head 表のその旨のフラグを設定できます >>52。

[251] TrueType outline の可変フォントに於いては、 各グリフの left side bearing は xMin と等しくなければなりません (must) 。 head の flags の第1ビットを設定しなければなりません (must) 。 >>43, >>52 従って可変フォントの default instance のグリフの lsb は glyf から直接得ることもできます。 >>43

[245] 可変フォントの non-default instance の side bearing は default instance と異なることがあります。 gvar 表を使って interpolate された phantom point 座標から得るか、 または default instance の値に HVAR 表の variation data を適用して得ることができます。 >>43 CFF2 outline の variable font の left side bearing は non-default instance では hmtx と HVAR を総合して得るべきです (should) 。 >>43

[50] グリフの right side bearing は、 グリフの left side bearing と前進幅から求められます。 グリフの bottom side bearing は、 グリフの top side bearing と前進高から求められます。 >>44

[250] グリフの lsb と違ってこれらはフォントファイル中に明示的には書かれていません。

[63] TrueType outline のグリフの advance width (aw) と left side bearing (lsb) は、 TrueType rasterizer の計算するグリフの phantom point から得られます。 hmtx 表からも得られます。 >>43

[64] right side bearing (rsb) は、次の式によります。 >>43

[65] pp1, pp2 を lsb, rsb を制御する TrueType phantom point とするとき、 その X軸方向の初期位置は、次の式によります。 >>43

[114] head の flags の第1ビットが設定されているときは、 すべてのグリフに於いて pp1 = 0 であり、 各グリフの xMin と left side bearing は等しくなければなりません (must) 。 >>52

[66] グリフが contour を持たないとき、 xMin, xMax は定義されません。 hmtx の left side bearing は 0 とするべきです (should) 。 >>43

[294] グリフの top side bearing は、 ideographic glyph の縦組み (vertical composition) 用に使うグリフの原点に対して計測します。 >>281

[131] hhea には minLeftSideBearing, minRightSideBearing があり、 hmtx のうち contour があるグリフの lsb, rsb = aw - (lsb + xMax - xMin) の最小値をそれぞれ表します。 >>124

[262] vhea には minTopSideBearing, minBottomSideBearing があり、 フォントの top side bearing measurement, bottom side bearing measurement の最小値をフォント設計単位で表します。 >>78

[257] vhea の最小 top side bearing, bottom side bearing と vmtx の top side bearing は一貫していなければなりません (must) 。 >>78

[126] minLeftSideBearing, minRightSideBearing は、 contour を持つグリフのみを使って計算するべきです (should) 。 >>124

前進

[117] グリフは、 前進幅 (advance width) , 前進高 (advance height) の 2つの前進 (advance) の値を持ちます。

[118] 素朴には、原点 (0, 0) と (前進幅, 前進高) がグリフの描画域と考えることができます。

[120] 文字のレンダリングの処理では、 現在位置にグリフの原点を揃えて配置し、 次のグリフのために現在位置を前進幅または前進高の分だけ移動します。 (より厳密には >>5)

[121] 現在の一般的な仮名や漢字のような正方形の文字の場合は、 グリフは前進幅や前進高の範囲に収まるように設計するのが普通です。 つまりグリフの外接箱は前進幅や前進高の範囲より小さくなります。

[122] しかしそうでないグリフも作ることが出来ます。その場合、前後のグリフと重なる可能性があります。 文字によっては (もちろん重なり方は調整しつつ) 意図的にそうすることがあります。

[123] 前進幅, 前進高はグリフごとに固定です。 前後のグリフの組み合わせによって字間を調整したいときは、 kerning 機能のような他の仕組みを使うことになります。

[110] hmtx に advanceWidth があります。 グリフの前進幅をフォント設計単位で表します。 >>43

[295] vmtx に advanceHeight があります。 グリフの前進高をフォント設計単位で表します。 >>281

[42] hdmx 表はグリフの advance width を各フォントサイズにおける画素単位の整数に変換した値を格納しています。 >>41

[58] CFF (CFF 1) outline は前進幅を持ちます。 PostScript processor はこれを使います。 OpenType はこれを使いません。 >>43

[59] CFF2 outline は advance width を持ちません。 >>43

[105] TrueType outline のグリフの advance width は、 TrueType rasterizer の計算するグリフの phantom point から得られます。 hmtx 表からも得られます。 >>43

[51] variable font の場合は記述された外接箱が得られたグリフのものを表すとは限りません >>44, >>52。 必要なら得られたグリフの制御点等から計算する必要があります。 side bearing は phantom point を使って、あるいは HVAR のデータから計算できます >>43。 CFF2 outline の variable font の advance width は non-default instance では hmtx と HVAR を総合して得るべきです (should) 。 >>43

[289] グリフの前進高 (advance height) は、 グリフの垂直原点の y 座標から初めて、下方向へと前進 (advance) します。 >>281

[290] 前進した終点 (endpoint) は、 原則として、 連なりの次のグリフの垂直原点の y 座標となります。 >>281

[130] hhea に advanceWidthMax があります。 hmtx の前進幅の最大値とされます。 >>124

[261] vhea に advanceHeightMax があります。 フォントの前進高 measurement の最大値をフォント設計単位で表します。 >>78

[258] vhea の最大前進高と vmtx の前進高は一貫していなければなりません (must) 。 >>78

[247] head の flags の第4ビットは、 instruction が前進幅を変更 (alter) するかもしれない (may) (前進幅は線形に拡縮しないかもしれない (might) ) ことを表します。 >>52

幅

基線

基線

ascender と descender

[127] hhea には ascender と descender があり、それぞれフォントの typographic ascent と typographic descent を表します。 Apple が使います。 >>124

[136] OS/2 には sTypoAscender, sTypoDescender があります。 フォントの typographic ascender, typographic descender をフォント設計単位で表します。 >>143 Windows が使います。 >>124

[139] 新たな text-layout 実装は OS/2 の方が推奨 (recommended) されます。 フォント開発者は一貫した配置 (consistent layout) のため対象の応用の動作を評価して双方を使うべきです (should) 。 >>124

[234] 可変フォントにおいては MVAR に sTypo* に対応する hasc, hdsc があります。 >>143

[259] vhea の 1.0 版には ascent と descent があります。 中央線 (centerline) から前行 (previous line) の descent、 次行 (next line) の ascent までの距離をフォント設計単位で表します。 >>78

[265] vhea の 1.1 版には vertTypoAscender と vertTypoDescender があります。 vertical typographic ascender, vertical typographic descender を表します。 垂直中央基線 (vertical center baseline) から CJK / ideographic glyph の設計空間 (design space) (ideographic em box) の右辺 (right edge) , 左辺 (left edge) までの距離をフォント設計単位で表したものです。 >>78

[234] 可変フォントにおいては MVAR に ascent / descent, sTypo* に対応する vasc, vdsc があります。 >>78

[184] sTypoAscender - sTypoDescender が unitsPerEm と等しいことは一般的な要件 (general requirement) ではありません。 フォントが対応する主たる言語に適切な default line spacing になるように設定するべきです (should) 。 >>143

[185] 横書きだけでなく縦書きでも使う想定のCJKフォントでは、 sTypoAscender, sTypoDescender の値は ideographic em-box の上辺 (top), 下辺 (bottom) を記述するものでなければなりません (required) 。 さもなくば縦書き時におかしくなります。 >>143

[266] vertTypoAscender と vertTypoDescender は、通常 $\frac{\text{<span><code><a class="sw-anchor" href="/n/head">head</a></code> の <span class=" sw-f"><code><a class="sw-anchor" href="/n/unitsPerEm">unitsPerEm</a></code></span></span>}}{\text{<span>2</span>}}$, −$\frac{\text{<span><code><a class="sw-anchor" href="/n/head">head</a></code> の <span class=" sw-f"><code><a class="sw-anchor" href="/n/unitsPerEm">unitsPerEm</a></code></span></span>}}{\text{<span>2</span>}}$ に設定します。 >>78

[205] 普通は基線の上方向に ascender が、 基線と等しいか下方向に descender があります。

[206] この「普通」と違う状態がどの程度許されるのかは定かではありません。

[207] descender が基線より上に来るケースがあり得ることは仕様書でも暗示的に言及されています。 その場合はグリフが通常存在する領域の外側に基線が来ることになります。 あまり一般的ではなさそうですが、おかしなことにはならなそうです。

[208] descender の方が ascender より上に来るようなケースはどうなのでしょう。

行高

[128] hhea には lineGap があり、 typographic line gap を表します。 Apple が使います。 >>124

[129] 負の値は、 0 として扱う legacy platform があります。 >>124

[137] OS/2 には sTypoLineGap があり、 typographic line gap をフォント設計単位で表します。 >>143 Windows が使います。 >>124

[138] 新たな text-layout 実装は OS/2 の方が推奨 (recommended) されます。 フォント開発者は一貫した配置 (consistent layout) のため対象の応用の動作を評価して双方を使うべきです (should) 。 >>124

[235] 可変フォントにおいては MVAR に hlgp があります。 >>143

[260] vhea の 1.0 版には lineGap がありますが、 予約 (reserved) とされ 0 に設定することになっています。 >>78

[267] vhea の 1.1 版には vertTypoLineGap があり、 フォントの vertical typograohic gap を表します。 >>78

[269] 可変フォントにおいては MVAR に lineGap, sTypoLineGap に対応する vlgp があります。 >>78

[210] line gap は負の値にできます。それが何を意味するか、 >>129 以外には明言がありません。 >>129 および他に説明がないことから常識的に類推すれば、正の値の時と反対方向の「gap」 が生じるか、 0 とみなすかのどちらかが認められる挙動であるものの、 0 とみなすのは好ましからざる古い挙動である、という感じでしょうか。

[182] sTypoAscender, sTypoDescender, sTypoLineGap は組み合わせて (横書き用の) default line spacing を決定するべきです (should) 。 >>143

[181] ascender / descender / lineGap, usWinAscent / usWinDescent は legacy platform 実装が platform-specific の挙動で使っていたために、 これらは後方互換性の要件に縛られており、 実装を超えた一貫した layout が実現できません。 一方 sTypoAscender, sTypoDescender, sTypoLineGap は応用が文書を typographically correct で可搬な形で配置できることを意図したものです。 >>143

[183] fsSelection の USE_TYPO_METRICS (第7ビット) は、 sTypo* と usWin* のどちらで default line metrics を決めるかを指定します。 >>143

[186] USE_TYPO_METRICS が設定されている場合、 応用は sTypoAscender - sTypoDescender + sTypoLineGap をフォントの default line spacing として使うことが強く推奨されます (strongly recommended) 。 >>143

[231] 可変フォントは USE_TYPO_METRICS を設定するべきです (should) 。 >>143

[196] sTypo* と usWin* のどちらで default line spacing を決めるか USE_TYPO_METRICS をみる応用があります。 この挙動は新しいフォントでより好ましく可搬な配置を実現しつつも古いフォントを使った遺物の文書との互換性を保つ有用な実装方法です。 >>143

[230] 可変フォントでは、 default line metrics は常に sTypo* で設定されるべきです (should) 。 >>143

[232] 可変フォントでは hhea の ascender / descender / lineGap, は sTypo* と同じ値に設定するべきです (should) 。 >>143

[209] default line spacing が負になってしまうような値の組み合わせだとどうなるのでしょう。 そのようなものが認められるとも認められないとも特に何も記述がありません。 実装は何か対処しておかないと行が上に進んでおかしな動作になりかねません。

[268] 応用は、 (vhea の 1.1 版の) OpenType フォントの single spaced vertical text の recommended line spacing を、 ideo embox width + vhea の vertTypoLineGap により決定できます。 >>78

フォント高

[187] OS/2 に usWinAscent, usWinDescent があります。 「Windows ascender」 metric, 「Windows descender」 metric をフォント設計単位で表します。 >>143

[238] 可変フォントにおいては MVAR に hcla, hcld があります。 >>143

[188] これらには clipping region の基線上の高さを指定するべきです (should) 。 >>143

[189] sTypoAscender / sTypoDescender, ascender / descender とよく似ていますが、大きな違いは描画の限界を示すことです。

[201] また、 sTypoDescender / descender は基線の上が正、下が負となるのに対し、 usWinDescent は基線の上が負、下が正となります。 >>143

[100] Windows では usWinAscent と usWinDescent を使って maximum black height を決定します。 Windows はこの両者の距離を Font Height といいます。 >>99

[190] Windows GDI 実装では、 usWinAscent と usWinDescent が TrueType rasterrizer の bitmap surface の size を決定するために使われます。 Windows GDI は TrueType glyph outline がこの範囲外にはみ出した時切り抜き (clip) します。 >>143

[191] 切り抜きが好ましからざるときは、 yMax 以上や yMin 以下に当たる値を指定するべきです (should) 。 >>143

[199] 古い版の OpenType 仕様書は、 usWinAscent と usWinDescent を Windows "ANSI" character set のすべての文字の yMax / yMin (の最大・最小?) に当たる値とすることを提案 (suggested) していました。 >>143

[200] 新しいフォントでは、 usWinAscent と usWinDescent は対応する主要な言語をもとに決定するべきであり、 長いグリフや mark positioning に必要になる追加分の高さも考慮するべきです。 >>143

[233] 可変フォントでは、 usWinAscent と usWinDescent は推奨 (recommended) される clipping rectangle を指定するために使うべきです (should) 。 >>143

[101] Windows は yMax と yMin の外側の pixel をくり抜きます。 TrueType instruction は actual scaled and rounded values と異なる Font Height を生じることがあって、 Font Height を厳密に yMax と yMin に置くと 「lost pixel」 が生じることになります。 >>99

[102] この grid fitting の lost pixel 問題を避けるために VDMX 表に修正した高さを記述できます。 >>99

[192] VDMX があって current device aspect ratio と rasterization size に対するデータが存在するとき、 VDMX のデータが usWinAscent と usWinDescent を上書きします。 >>143

[193] usWinAscent と usWinDescent の指定する範囲はグリフの既定の位置に対するものです。 GPOS や kern による配置が適用される前の状態を指します。 >>143

[195] 遺物の応用の中には、 usWinAscent と usWinDescent から default line spacing を決めるものがあります。これは強く非推奨 (strongly discouraged) です。 sTypo* から決めるべきです (should) 。 >>143

[197] sTypo* を使って default line spacing を決める応用であっても、 usWin* を使って clipping region の size を決定できます。 応用によっては clipping region を使って編集時に再描画するべき display surface の部分を決めたり、 text が選択されたときに選択矩形を描く大きさを決めたりします。 これらは usWin* の正統な用法です。 >>143

vertical-align

[83] CSS の vertical-align (baseline-shift) では、選ばれた基線を基準に、上方 (横書きの上) を正とする値を使います。

[84] その移動量は <length> か <percentage> で、後者のときは line-height に対する割合となります。

文字高

[203] OS/2 に sxHeight, sCapHeight があります。 >>143

[237] 可変フォントにおいては MVAR に xhgt, cpht があります。 >>143

[204] sxHeight は、基線と non-ascending な小文字の近似高 (approximate height) との距離をフォント設計単位で指定する metric です。 >>143

[216] sCapHeight は、基線と大文字の近似高 (approximate height) との距離をフォント設計単位で指定する metric です。 >>143

[211] sxHeight, sCapHeight は通常は書体 (type) 設計者が指定するものです。 >>143

[212] 遺物フォントの変換などでそれが叶わないときは、 U+0078 x, U+0048 H のグリフの unscaled で unhinted なグリフ bounding box の上辺 (top) と等しく設定することができます (may) 。 >>143

[213] U+0078, U+0048 のグリフがないときは、 0 とするべきです (should) 。 >>143

[219] 特に説明されていませんが、負にもなるようです。 普通はないのでしょうが、該当部分が基線の下に来るときは負の値を指定することになると思われます。

[220] 0 は該当部分がちょうど基線と一致する場合と適当な値がない場合 (>>213) があり得ます。前者になることはあまりないので、さほど問題にはならないのでしょう。

[214] sxHeight が指定されている場合は、フォント置換 (substitution) に使うことができます。 この値に基づき拡縮して、 他のフォントの見かけの大きさに近似できます。 >>143

[215] sCapHeight が指定されている場合は、 ミリメートル単位の大文字高で書体 (type) サイズを指定する系 (system) で使えます。 >>143

[217] sCapHeight は揃え用 (alignment) の metric としても使えます。 例えば drop capital の上辺 (top) を text の最初の行の sCapHeight metric に揃えることができます。 >>143

線

[162] OS/2 に yStrikeoutSize があります。 >>143

[163] yStrikeoutSize には打ち消し線 (strikeout stroke) の厚さ (thickness) をフォント設計単位で指定します。 >>143

[164] yStrikeoutSize の値は正とするべきです (should) 。 OS/2 プラットフォームでは符号付きの値として実装されていました (正の値が期待されるにも関わらず)。 >>143

[165] yStrikeoutSize の値は通常は em dash の厚さとするべきです (should) 。 >>143

[166] yStrikeoutSize は post の underline thickness と一致するべきです (should) 。 >>143

[167] OS/2 に yStrikeoutPosition があります。 >>143

[168] yStrikeoutPosition には基線に対する打ち消し線 (strikeout stroke) の上辺 (top) の位置 (strikeout position) をフォント設計単位で指定します。 正は基線の上、負は基線の下を表します。 >>143

[169] strikeout position は em dash と揃えることが提案されます (suggested) 。 >>143

[170] strikeout position は標準文字 (standard character) の認識と干渉するべきではなく (should not) 、 従って crossbar と揃えるべきではありません (should not) 。 >>143

[236] 可変フォントにおいては MVAR に strs, stro があります。 >>143

[176] post に underlinePosition があります。 >>174

[177] underlinePosition は、 下線の上辺 (top) の y 座標の提案 (suggested) です。 >>174

[178] post に underlineThickness があります。 >>174

[179] underlineThickness は、 下線の厚み (thickness) の提案 (suggested) 値です。 通常は U+005F _ の厚みと一致するべきで (should) 、 OS/2 の strikeout thickness とも一致するべきです。 >>174

[241] 可変フォントにおいては MVAR に undo, unds があります。 >>143

caret

[133] hhea, vhea に caretSlopeRise, caretSlopeRun があります。 >>124, >>78

[134] cursor >>124, caret >>78 の slope を $\frac{\text{<span>rise</span>}}{\text{<span>run</span>}}$ として表すとされます。 垂直のとき caretSlopeRise を 1 とし、 caretSlopeRun を 0 とします。 >>124, >>78 水平のとき caretSlopeRise を 0 とし、 caretSlopeRun を 1 とします。 >>78

[140] 可変フォントに於いては MVAR に hcrs / hcrn, vcrs / vcrn があります。 >>124, >>78

[264] 縦書きフォント (vertical font) では水平の caret が最善です。 >>78

[135] hhea, vhea に caretOffset があります。 グリフにおける slanted highlight >>124 (slanted glyph 上の highlight >>78) の見栄えが最も良くなる (best appearance) ためにずらす (shifted) べき量を表します。 非 slanted なフォントでは 0 とします。 >>124, >>78

[141] 可変フォントに於いては MVAR に hcof, vcof があります。 >>124, >>78