横書き用座標値

縦書き用座標値

[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] VORG の defaultVertOriginY や vertOriginY では、 グリフの縦書き原点のY座標をフォントの設計座標系design coordinate systemにおいて表します。 >>281

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

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

グリフ位置決定

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

[299] 仕様書には明確な説明がありませんが、例示の図では前進の値のことを横書きでは horiAdvance, 縦書きでは vertAdvance と呼んでいます。 >>3

[300] 同じく説明がありませんが、例示の図では side bearing のことを横書きでは (horiBearingX, horiBearingY), 縦書きでは (vertBearingX, vertBearingY) と呼んでいます。 >>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 分加算 (下移動) します。

[301] 仕様書では明確な説明がありませんが、例示の図では、

• [302] 横書きのとき pen position はアルファベット基線の左側に置かれ、 horiBearingY は基線から maxY まで、 horiBearingX は pen position から minX までの値となっています。 >>3
• [303] 横書きのとき pen position は左右中央を通る基線の上側に置かれ、 vertBearingX は基線から minX まで、 vertBearingY は pen position から maxY までの値となっています。 >>3

[304] とはいえ横書きの pen position の Y 座標と horiBearingY の値や、 縦書きの pen position の X 座標と vertBearingX の値は、 どこを選んでも得られる結果は変わらないので、 実装上都合がいい位置だとみなすことができます。

[316] 横書きでは、グリフの上下方向の配置は、 Y 座標の位置を揃えることによって行われます。 基本的には Y = 0 がアルファベット基線で、これに行が揃えられることになります。 なお前進高は関係しません。

[317] 縦書きでは、グリフの左右方向の配置は、左右中央に合わせることによって行われます。 グリフの左右中央の位置は、グリフの前進幅の半分の位置となります。 基本的にはグリフの左右中央を行の中央に揃えることになります。

[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

幅

[314] 文字幅も参照。

基線

基線

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 は、通常 head の unitsPerEm2, −head の unitsPerEm2 に設定します。 >>78

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

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

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

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

[306] Windows ascender / descender まで含めて3つの横書き ascender / descender が (座標軸の関係で正負の違いがあるのを除けば) 同じ値のフォントもあれば、 違う値のフォントもあります。

[307] Windows 以外の2つの ascender / descender は定義文を素直に読むと同じ値になりそうなものですが、 実際には微妙に違った値になっていることもあります。何かの互換性の問題でそうなっているのでしょうか。

[308] hhea のと Windows metrics が同じ値なのに typographic metrics だけが違う値になっていることがあります。 そのフォントの場合は typographic metrics が間違っているようでした。 USE_TYPO_METRICS が偽なのもあってかレンダリングには使われず制作者が気づいていないものと思われます。 この事例の場合はおそらくフォント制作ソフトウェアの既定値が設定された状態で、 フォント制作ソフトウェアで2つの metrics だけが変更され typographic metrics は変更されずに残ったのでしょう。

[309] こういう事案もあるので新しい実装は単純に typographic metrics だけを見るというわけにもいかないらしく悩ましいですね。

行高

[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

[311] Windows の Chrome で USE_TYPO_METRICS を設定しないと、 Windows descender から Windows ascender までが文字列の選択の対象範囲となります。 また、表示位置も (おそらく) その垂直中央で揃えられます。 行高はその高さになるわけではないようですが、 同じ文書の他のフォントの影響なのか、それとも他の ascender / descender の影響なのか調べていません。 2025-02-02T07:42:33.900Z

[312] >>311 設定するとこの奇妙な挙動はなくなり、 基線揃え(?)で適切な位置に字形が表示され、選択範囲も想定される行高 (typo ascender / descender の範囲?) になります。

[310] Font metrics settings for desktop and web fonts — TypeDrawers, 2025-02-02T07:29:13.000Z, 2025-02-02T07:39:15.828Z https://typedrawers.com/discussion/2805/font-metrics-settings-for-desktop-and-web-fonts

フォント高

[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 を riserun として表すとされます。 垂直のとき 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