ah

OpenType の座標

[1] 文字文字列 (を表すグリフグリフの列) の座標空間は複雑です。

目次

  1. 基線
  2. OpenType の座標
    1. 横書き用座標値
    2. 縦書き用座標値
    3. グリフ位置決定
    4. 添付点
    5. 可変フォント
  3. グリフの大きさ
    1. 外接箱
    2. side bearing
    3. 前進
  4. 小書き (添字)
  5. SVG 字形配置
  6. 選択と hit testing
  7. ブロック軸方向の位置と大きさ
    1. 基線
    2. ascender と descender
    3. 行高
    4. フォント高
    5. vertical-align
    6. 文字高
  8. ブロック軸と成す角度
    1. caret
  9. フォントサイズ
  10. ヲコト点
  11. 関連
  12. メモ

基線#

基線

OpenType の座標#

[115] OpenTypeグリフは、 座標空間上の集合として記述されます。

[116] 1つのグリフデータは、 1つの座標空間上に配置されています。 このデータを適宜、文字レンダリングするべき位置に配置 (= 座標空間に変換) し、 次の文字の配置処理へと進んだり、前後の文字との関係を調整したりすることになります。

[4] フォント単位

[70] kern

[71] LTSH - Linear Threshold (OpenType 1.9) - Typography | Microsoft Docs, PeterCon, https://docs.microsoft.com/ja-jp/typography/opentype/spec/ltsh

[73] OS/2, post, sbix, STAT

横書き用座標値#

縦書き用座標値#

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

[274] OpenType vertical font は vheavmtx必須 (require) です。 >>103

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

[255] hhea / hmtx にはなぜかこれに相当する規定がありません。

[79] 縦書き用のフォントでは vhea を使うことになっていますが >>78WindowsChrome, Firefox とも vhea がないからといって縦書き表示に特別支障となることは無さそうです。

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

[273] vertical metrics coordinate system >>103

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

[276] 通常はグリフの上部のアキも含めた上端ということになります。

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

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

[280] 必須ではないのでフォントの設計者はこれを含めるか含めないかを決められますし、 実装者はどちらのケースも想定する必要があることになります。
[284] 正確性というのは丸め誤差などが想定されます。 >>281

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

[286] ORGdefaultVertOriginYvertOriginY では、 グリフ縦書き原点の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

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

[300] 同じく説明がありませんが、例示の図では side bearing のことを横書きでは (horiBearingX, horiBearingY), 縦書きでは (vertBearingX, vertBearingY) と呼んでいます。 >>3

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

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

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

[297] 配置を使って前のグリフと近づけたいとき左横書きではの値を指定することになり、 右横書きではの値を指定することになります。

[298] 前進を使って次のグリフと近づけたいとき書字方向に関わらずの値を指定することになります。

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

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

[305] なので仕様書に説明がないことは技術的には問題ないのですが、 読者の仕様書の読解と技術の理解のためにはよろしくありません。

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

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

[18] 機能1により X軸方向に3前進し、 機能2により Y軸方向に6前進し、 機能3により X軸方向に-2前進すると、 X軸方向には1前進し、 Y軸方向には6前進することになります。

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

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

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

[74] GPOSのCursive Attachment Positioningについて - にせねこメモ, 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 anchorexit 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_LEFT0 の場合、 2つ目のグリフを調整します。 RIGHT_TO_LEFT1 の場合、 1つ目のグリフを調整します。 >>3

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

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

[29] 名前に反して右横書きにはあまり関係ありません。 が巷のフォントでは lookupType と無関係に右横書き向けのグリフが収容された lookup にこのフラグが設定されていたりするようです。 (lookupType 3 以外では指定されていてもいなくても動作は変わりません。)
[30] entry pointexit point は、書字方向によって違う位置にしなければならないのが普通です。 1つの lookup で同じグリフに対して複数の書字方向用の anchor は記述できませんから、 書字方向ごとの lookup を用意しなければなりません。 (続け字で同じグリフで違う書字方向にそのまま適用できる例の方が稀かもしれませんが。)

[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

[33] lookup の機能的に求められる基底グリフ合字グリフマークグリフといったグリフ級と、 実際に lookup に記述されたグリフに割り当てられたグリフ級は、 一致しないこともデータ構造上はあり得ます。 そのような場合にどうするべきかは言及もされていません。 素直に考えると、これらの lookupグリフ級によって使う、 使わないがまず判断されるのですから、 グリフ級が一致しないデータが混じっていても単に無視されるだけなのが好ましい実装でしょうか。

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

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

[40] こちらの場合は基底グリフマークグリフの単体の組み合わせも意味があるのですから、 マークグリフマークグリフanchor との衝突は lookup の設計の誤りではなく、 優先度が仕様上明確でないことの問題です。

[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 pointoff-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

[48] 制御点により定義される外接箱outlineを含むことが保証されます。 outline に接するとは限りません。 >>44
[56] 外接箱外接矩形の2種類の語が使われていますが、表記揺れで同じ概念と思われます。
[112] contour のない、つまり空白グリフでは定義されません。 各定義により 0 などの値になります。

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

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

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

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

[277] フォント内で明示された外接箱の情報と実際のグリフデータから算出される外接箱の情報が相違するとき、 どうなるのかは OpenType 仕様書上必ずしも明確になっていません。 これらの情報は主に性能を目的として重複して含まれていると考えられるので、 実装は処理の最適化のために使っているでしょうから、 情報が矛盾していると誤ったレンダリングになる可能性がありそうです。 また、実装戦略に関わりますから、相互運用性に問題が生じる可能性がありそうです。 場合によってはバッファー溢れなどセキュリティーに悪影響を及ぼしそうですから、 実装者は注意が必要です。
[285] 外接箱を使って計算する縦書き原点については、 VORG (>>279) として明示することができます。 外接箱の計算に関する丸め誤差などが正確性や互換性の問題を起こし得ることが OpenType 仕様書にも明記されています。

side bearing#

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

[109] contour のない、つまり空白グリフでは定義されません。 各定義により 0 などの値になります。

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

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

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

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

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

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

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

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

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

[253] 仕様書の意図が不明瞭なのですが、 CFF CFF2 の場合でも lsb を使ってグリフを配置してもいいし、 使わないでグリフ局所座標系をそのまま使って配置してもよく、 どちらかといえば後者が推奨されるのであり、 フォントはそれを前提にするのがいいということでしょうか。 ただ CFF2可変フォントについては前者の挙動が求められています (>>245)。

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

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

[245] 可変フォントnon-default instanceside bearingdefault instance と異なることがあります。 gvar を使って interpolate された phantom point 座標から得るか、 または default instance の値に HVAR の variation data を適用して得ることができます。 >>43 CFF2 outlinevariable fontleft side bearingnon-default instance では hmtxHVAR を総合して得るべきです (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

rsb = aw - (lsb + xMax - xMin)

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

pp1 = xMin - lsb

pp2 = pp1 + aw

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

[66] グリフcontour を持たないとき、 xMin, xMax は定義されません。 hmtxleft side bearing0 とするべきです (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 bearingvmtxtop side bearing は一貫していなければなりません (must) >>78

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

前進#

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

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

[119] 実際には基線の関係で y 方向はもう少し複雑です。

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

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

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

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

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

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

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

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

[113] Font Collection は、 同じ CFF であっても異なる hmtx によって異なる前進幅グリフに設定できます。 >>43

[59] CFF2 outlineadvance width を持ちません。 >>43

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

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

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

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

[291] vkrn などによって調整されます。

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

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

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

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

#

[142] OS/2xAvgCharWidth があります。 グリフの平均幅を表します。 >>143

[151]0 から 2 までは、仕様書が Basic Latin文字に偏向していて、 その前提で xAvgCharWidth の値をの平均長の推測に使えると考えられていました。 >>143

[152] a から z までと間隔に対して重みが定義されており、 そのグリフの幅に重みを掛けた総和を 1000 で割ったものが xAvgCharWidth とされていました。 >>143

[153] おそらく英語小文字の出現頻度から決めた重みと思われます。

[144]3 以後、 xAvgCharWidth は、 フォント中の零幅ではないグリフescapement = 文字送り ( (width) ) の算術平均で、単位フォント設計単位です。 >>143

[146] しかしこの計算方法に従っていないフォントがあります。 >>143

[147] OS/20 から 2 のときに作られ、 その後新しい版に変更したものの値はそのままというケースがあります。 >>143

[148] versioningの失敗案件ですね。

[149] CJKフォントで、 xAvgCharWidth が定義上の計算値の半分くらいになっているものがあります。 >>143

[150] 事情がよくわからないのですが、半角の平均幅を設定するものとの認識があった (もしかしたらその前提の実装もあった) ということでしょうね。

[145] 実装者は、配置 (layout) の計算においてこの値に依存しないよう強く推奨 (strongly recommended) されています。 応用は、 xAvgCharWidth を実際のグリフ前進幅の決定に使うべきではありません (should not) >>143

小書き (添字)#

[154] OS/2 には ySubscriptXSize, ySubscriptYSize, ySuperscriptXSize, ySuperscriptYSize があります。 >>143

[155] 小書き (subscript / superscript) におけるフォント開発者によって推奨 (recommended) される水平 (X) / 垂直 (Y) サイズをフォント設計単位で表します。 >>143

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

[157] 推奨されるサイズが numerics とその他など2つあるときは、 numeric size とするべきです (should) >>143

[158] OS/2 には ySubscriptXOffset, ySubscriptYOffset, ySuperscriptXOffset, ySuperscriptYOffset があります。 >>143

[160] 小書きにおけるフォント開発者によって推奨 (recommended) される水平 (X) / 垂直 (Y) の offset をフォント設計単位で表します。 >>143

[161] X は、 正立 (upright) グリフでは通常 0 です。 傾き (italicslant) のあるフォントグリフでは、 傾きの角度を考慮した調整量を指定します。 >>143

[159] フォント応用の必要とするすべての小書きグリフを持ち合わせていないとき、 応用フォントグリフ縮小や、 他のフォントグリフで代用によって小書きグリフを代替できるのですが、 size の値が代替グリフ推奨 (recommended) 公称幅 (nominal width) となります。 size の値が小書きに使うフォントem サイズに写像されます。 offset の値が小書きの直前のグリフの glyph escapement point からの小書きグリフ原点 / 基線推奨 (recommended) される位置を表します。 >>143

[239] 可変フォントにおいては MVARsbxo, sbxs, sbyo, sbys, spxo, spxs, spyo, spys があります。 >>143

SVG 字形配置#

[86] SVG グリフは、 SVG文書内の座標系によって配置された図形を文字列 (のグリフ列) の座標空間に配置することになります。

[87] SVG文書の default units は、フォントフォント設計単位等しい (equivalent) です。 >>85

[272] OpenType ではフォント設計単位の値のほとんどは整数型で、 フォント設計単位の粒度が設計上の最小粒度になります。 SVG 側では小数を扱うことができ、 SVG に於いても特に制約がないので、 OpenType のこの制限を超えて細かい指定ができることになります。

[88] SVG原点 (0, 0) は、フォント側の design grid の原点に揃えます。 y = 0 は、 text layout に使う既定の水平基線です。 >>85

[89] フォント側では y 軸は下方向がとなりますが、 SVG座標系では y 軸は上方向がとなります。 >>85 従って SVG文書単体で表示するのと上下逆転することになります。

[93] このため字形の大部分は xy象限に配置されることがあります。 一般的な図形編集では xy象限に配置するので、 例えば svg 要素viewBox 属性0 1000 1000 1000 のように設定して、 SVG 座標系y 軸方向に 1000 ずらしておく技法があります。 あるいは対象となる要素transform="translate(0,-1000)" と指定することでずらす技法があります。 フォント開発工具は、 設計環境からフォント内の形式へと適切に移すことが期待されています。 >>85 (Note, 例示)

[90] SVG文書の initial viewport の size は、 em square です。 すなわち、 高さ = = headunitsPerEm です。 >>85

[91] svg 要素viewBox 属性高さが指定されていて >>90 と異なるときは、 SVG 利用者座標系の scale transformation の効果を持つことになります。 svg 要素height 属性width 属性が指定されているときは、 やはり座標系の scale transformation の効果を持つことになります。 >>85

[92] initial viewport の size は em square ですが、 viewportclip してはなりません (must not) svg 要素clip 特性の値が autooverflow 特性の値が visible があるものとみなします。 svg 要素clip 特性overflow 特性の違う値が指定されていても、無視しなければなりません (must) フォントsvg 要素clip 特性overflow 特性を指定するべきではありません (should not) >>85

[94] グリフadvance widthhmtx の、 advance heightvmtx の指定によります。 >>85

[95] つまり他の形式のグリフの場合と共通です。

[96] SVGアニメーションCSSアニメーションに対応している場合でも、 グリフの advance はアニメーションで変化してはなりません (must not) >>85

[98] グリフbounding boxフォント内に明示的には記述されません。 bounding box が必要なときはレンダリングしたグリフの “ink” bounding box を使うべきです (should) 。 これは animated rendering と static rendering で違うかもしれません。 >>85

[97] hmtxleft side bearing, vmtxtop side bearing, headflags の第1ビットは、 SVG グリフでは使いません。 >>85

選択と hit testing#

[81] 少なくても WindowsChrome では、 OS/2usWinAscentusWinDescent行箱の上下の決定に寄与しているように見えます。

[82] 縦書きの左右位置にも影響しているのかいないのか。 基線

ブロック軸方向の位置と大きさ#

基線#

基線

ascender と descender#

[127] hhea には ascenderdescender があり、それぞれフォントtypographic ascenttypographic 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] 可変フォントにおいては MVARsTypo* に対応する hasc, hdsc があります。 >>143

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

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

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

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

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

[266] vertTypoAscendervertTypoDescender は、通常 headunitsPerEm2, −headunitsPerEm2 に設定します。 >>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] 可変フォントにおいては MVARhlgp があります。 >>143

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

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

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

[270] 予約されている lineGap と対応関係にあるこの値をどのように使えるのかは定かではありませんが。

[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] fsSelectionUSE_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] 可変フォントでは hheaascender / descender / lineGap, は sTypo* と同じ値に設定するべきです (should) >>143

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

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

フォント高#

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

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

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

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

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

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

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

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

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

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

[202] >>193 の通り既定の位置を基に切り抜きの範囲は決まりますから、 切り抜きに関して言えばマークが上下に追加されることは特別な配慮は不要です。 しかし >>197 のような行とみなされる範囲にマークが含まれることは好ましいでしょうから、 その意味での配慮はやはり必要です。

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

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

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

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

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

[194] WindowsGDI の実装の挙動として説明されているということは、 他の実装はこれに従う必要はないということでしょうか。

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

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

[198] ということは clipping してレンダリングされてしまうことを防ぐために余裕を持たせてあまりに大きな値を usWin* に指定してしまうと、上下のを隠すように選択矩形が描画されてしまうリスクがあるということです。 再描画範囲の決定にしても、上下のと被ってしまうと、上下のの再描画まで必要だと応用は判断しないといけないはずですが、この >>197 のような仕様書の書き方だとそこまで考えないで実装してしまいそうです。。。 従って安全のため usWin*default line spacing とそうかわらないように指定するべきということになりそうです。

vertical-align #

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

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

文字高#

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

[237] 可変フォントにおいては MVARxhgt, 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

[218] 説明から明らかなように、 ラテン文字に特化した機能です。 ラテン文字と似た構造を持つギリシャ文字キリル文字などの多くのアルファベット文字体系でも有用と考えられます。 (しかし他の多くの文字体系では必ずしも有意義でないことには注意が必要です。)

#

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

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

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

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

[166] yStrikeoutSizepost の underline thickness と一致するべきです (should) >>143

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

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

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

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

[171] crossbar について特に説明はありませんが、一般的解釈によれば etA のような字形内の横線のことをいいます。 標準文字というのもよくわかりませんが、 em dash のような記号、句読点類を除いた一般的な letter などを指すのでしょうか。

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


[176] postunderlinePosition があります。 >>174

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

[178] postunderlineThickness があります。 >>174

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

[180] 従って _em dash下線打ち消し線が同じ太さになるべき、 ということです。

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

ブロック軸と成す角度#

[172] 斜体を考慮した配置: >>161

[173] postitalicAngle があります。 >>174

[175] italicAngle は、 italic 角度を表します。 垂直からの度数反時計回りで表します。 0正立であり、 に傾くととなります。 >>174

[242] 可変フォントにおいてはこれに直接対応するものがありません。 variation instance でこれに相当する値は、 variation instance を選択するのに使った slnt user coordinates から得られます。 >>174

caret#

[133] hhea, vheacaretSlopeRise, caretSlopeRun があります。 >>124, >>78

[134] cursor >>124, caret >>78sloperiserun として表すとされます。 垂直のとき caretSlopeRise1 とし、 caretSlopeRun0 とします。 >>124, >>78 水平のとき caretSlopeRise0 とし、 caretSlopeRun1 とします。 >>78

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

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

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

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

フォントサイズ#

[248] headlowestRecPPEM があります。 >>52

[249] 最小可読サイズを画素 (pixel) 単位で表します。 >>52

[271] 欄名から推察するに 1 em の長さを pixel 単位で表したものなのでしょう。

[221] OS/2 には usLowerOpticalPointSize, usUpperOpticalPointSize があります。 >>143

[222] 複数の optical style があるフォントで使います。 >>143

[223] usLowerOpticalPointSize は、フォントが設計されている size の範囲の下端値 (lower value) です。 指定された値は範囲に含まれます>>143

[228] usUpperOpticalPointSize は、フォントが設計されている size の範囲の上端値 (upper value) です。 指定された値は範囲に含まれません>>143

[226] usLowerOpticalPointSize < usUpperOpticalPointSize でなければなりません (must) usUpperOpticalPointSize の最小値は 2 です。 usLowerOpticalPointSize の最大値は 0xFFFE, usUpperOpticalPointSize の最大値は 0xFFFF です。 0xFFFFを意味します。 >>143

[225] 同じ typographic family における他の optical size variant のフォントで上端値が下端値となっていることが期待されます。 一連の optical size variant フォント群のうち optical size が最小のフォントusLowerOpticalPointSize0 とするべきで (should) 、各フォントの範囲に隙間や重複はないべきです (should)

[227] 複数の optical size variants で設計されていないフォントでは usLowerOpticalPointSize0, usUpperOpticalPointSize0xFFFF とするべきです (should) >>143

[224] 単位TWIPs で、 1 Twip = 120 ポイント = 11440 インチです。 >>143

[229] これらの欄は STAT によって上書き (superseded) されました。 >>143

[240] 可変フォントにおいて直接対応するものはありません。 異なる size を対象とする variation は、 opsz variation axis で実装することになっています。 可変フォントopsz variation axis に対応するときは、 これらの欄は opsz 軸の fvar 表の minValuemaxValue と同じ値にすることができます (can) >>143 (Note)

ヲコト点#

[2] ヲコト点座標

関連#

[72] Adobe Font Metrics File Format

メモ#