[1] 文字や文字列 (を表すグリフやグリフの列) の座標空間は複雑です。
[42]
hdmx 表はグリフの advance width
を各フォントサイズにおける画素単位の整数に変換した値を格納しています。
>>41
[71] LTSH - Linear Threshold (OpenType 1.9) - Typography | Microsoft Docs, PeterCon, https://docs.microsoft.com/ja-jp/typography/opentype/spec/ltsh
[53]
head 表は、
xMin,
yMin,
xMax,
yMax
の4つの int16 値を持ちます。
>>52
[45]
glyf 表の TrueType outline グリフデータは、
xMin,
yMin,
xMax,
yMax
の4つの int16 値を持ちます。
>>44
[54] グリフの外接箱は、 グリフのすべての制御点を含む最小の矩形です。 >>52
[55]
head 表のこの4値は、
フォント中のすべてのグリフを含む外接箱を表します。
contour なきグリフは無視します。
>>52
[47] TrueType outline グリフのこの4値はグリフの点 (on-curve point も off-curve point も) の座標データから直接得ます。 rasterrizer が計算した phantom point は算入しません。 >>44
[46]
TrueType outline グリフの外接矩形は、
左下 (xMin, yMin)、
右上 (xMax, yMax)
の方形です。
>>44
[58]
CFF (CFF 1) outline は advance width を持ちます。
PostScript processor はこれを使います。
OpenType はこれを使いません。
>>43
[59]
CFF2 outline は advance width を持ちません。
>>43
[60]
CFF や CFF2 のグリフデータには
xMin = lsb, xMax を明示的には含みません。
side bearing は CharString データに暗示的に含まれていて、
CFF / CFF2 rasterizer から得られます。
>>43
[51]
variable font の場合は記述された外接箱が得られたグリフのものを表すとは限りません
>>44, >>52。
必要なら得られたグリフの制御点等から計算する必要があります。
side bearing は
phantom point
を使って、あるいは HVAR のデータから計算できます
>>43。
CFF2 outline の variable font の
left side bearing と advance width
は
non-default instance
では
hmtx と HVAR
を総合して得るべきです。
>>43
[49]
xMin が lsb と等しくなるようにグリフ座標を取ると
scaler には都合がいいです。
>>44
すべてのフォントがそうである場合には
head 表のその旨のフラグを設定できます
>>52。
TrueType outline を持つ variable font ではこのフラグを設定しなければなりませんし、
グリフをそのように設計しなければなりません。
>>52
[61]
フォント生成ツールは、
layout engine によっては hmtx の left side bearing
を使うかも知れませんから、
left side bearing
と
CFF / CFF2 outline の
CharString が暗示する xMin が一致するようにするべきです。
>>43
[57]
グリフの left side bearing と advance width は
hmtx 表に格納できます。
>>43
[50] right side bearing は left side bearing と advance width から求められます。 bottom side bearing は top side bearing と advance height から求められます。 >>44
[62]
TrueType outline のグリフの xMin と xMax は、
glyf 表のグリフデータによります。
>>43
[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
pp1 = xMin - lsb
pp2 = pp1 + aw
[66]
グリフが contour を持たないとき、 xMin, xMax
は定義されません。
hmtx の left side bearing は 0 とするべきです。
>>43
[77]
横書き用の座標値を格納する hhea, hmtx に対して、
縦書き用の vhea と vmtx があります。
[79]
縦書き用のフォントでは vhea を使うことになっていますが >>78、
Windows の Chrome, Firefox とも vhea
がないからといって縦書き表示に特別支障となることは無さそうです。
[80]
vhea には vmtx 用のグリフ数の欄がありますが、
Chrome, Firefox とも vmtx が存在しなくてもエラーにはならないようです。
(一方 hmtx がないとエラーになります。)
[5] TrueType では、 グリフの位置は基準となる pen point (pen position) からの配置と前進の2値で決まります。 すなわち、 現在の pen point からテキストの線に対して、 配置量だけ移動したところにグリフを置きます。 そして次のグリフの pen point を前進量だけ移動したところに置きます。 >>3
[8] TrueType における配置と前進は、 横書きではX軸, 縦書きではY軸の1次元値です。 >>3
horiBearingX)
となります。
前進量は advance width (horiAdvance)
となります。
>>3
グリフは最初の pen point から右へ右へと並べられていきます。vertBearingY
となります。
前進量は vertAdvance
となります。
>>3
グリフは最初の pen point から下へ下へと並べられていきます。[10]
TrueType では、
kern 表を使って2つのグリフの間の空間の増減を指定できます。
>>3
前のグリフの前進量に kern による調整量を足し合わせることで適切なスペースに調整できます。
[11]
OpenType では、
GPOS 表を使って配置と前進を
X軸,
Y軸の2次元で指定できます。
値はフォント単位によります。
>>3
[12]
GPOS 表では更に装置依存の調整もできます。
>>3
[17]
GPOS による位置調整は、 lookup によって一致条件と一致した場合の挙動が記述されますが
GPOS lookupType 1 では、
単一のグリフに対して、
X軸とY軸の配置と前進 (のそれぞれの加算量)
を指定できます。
>>3GPOS lookupType 2 では、
2つのグリフの組におけるそれぞれのグリフに対して、
X軸とY軸の配置と前進 (のそれぞれの加算量)
を指定できます。
>>3[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
[6]
OpenType では、
GPOS 表を使ってグリフ添付点によるグリフ間の位置調整も可能です。
>>3
[16] 添付点は基底グリフとダイアクリティカルマークの位置調整のために、 あるいは続け字における前後のグリフの位置調整のために使えます。 >>3
[15] OpenType ではグリフは0個以上の添付点を持つことが出来ます。 >>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
のグリフ位置調整にだけ作用します。
lookupType
と無関係に右横書き向けのグリフが収容された
lookup
にこのフラグが設定されていたりするようです。
(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組だけ指定できます。 合字グリフは見かけ上複数の構成部品があるかもしれないので、 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
として別に記述できます。
[86]
SVG
のグリフは、
SVG文書内の座標系によって配置された図形を文字列 (のグリフ列)
の座標空間に配置することになります。
[87] SVG文書の default units は、フォントの font design units と等しいです。 >>85
[88] SVG の原点 (0, 0) は、フォント側の design grid の原点に揃えます。 y = 0 は、 text layout に使う既定の水平基線です。 >>85
[89] フォント側では y 軸は下方向が正となりますが、 SVG の座標系では y 軸は上方向が正となります。 >>85 従って SVG文書単体で表示するのと上下逆転することになります。
[93]
このため字形の大部分は x が正、y が負の象限に配置されることがあります。
一般的な図形編集では x が正、y が正の象限に配置するので、
例えば svg 要素の viewBox 属性を
0 1000 1000 1000
のように設定して、 SVG 座標系を y 軸方向に
1000
ずらしておく技法があります。
あるいは対象となる要素に
transform="translate(0,-1000)"
と指定することでずらす技法があります。
フォント開発工具は、
設計環境からフォント内の形式へと適切に移すことが期待されています。
>>85 (Note, 例示)
[90]
SVG文書の initial viewport の size は、 em square です。
すなわち、 高さ = 幅 = head の unitsPerEm
です。
>>85
[91]
svg 要素の viewBox
属性で幅と高さが指定されていて >>90 と異なるときは、
SVG 利用者座標系の scale transformation の効果を持つことになります。
svg 要素の height 属性や width 属性が指定されているときは、
やはり座標系の scale transformation の効果を持つことになります。
>>85
[92]
initial viewport の size は em square ですが、
viewport を clip してはなりません。
svg 要素は clip 特性の値が auto、
overflow 特性の値が visible
があるものとみなします。
svg 要素に clip 特性や overflow
特性の違う値が指定されていても、無視しなければなりません。
フォントは svg 要素に
clip 特性や overflow 特性を指定するべきではありません。
>>85
[94]
グリフの advance width は hmtx の、
advance height は vmtx の指定によります。
>>85
[96] SVGアニメーションやCSSアニメーションに対応している場合でも、 グリフの advance はアニメーションで変化してはなりません。 >>85
[98] グリフの bounding box はフォント内に明示的には記述されません。 bounding box が必要なときはレンダリングしたグリフの “ink” bounding box を使うべきです。 これは animated rendering と static rendering で違うかもしれません。 >>85
[97]
hmtx の left side bearing,
vmtx の top side bearing,
head の flags の第1ビットは、
SVG グリフでは使いません。
>>85
[81]
少なくても Windows の Chrome では、 OS/2 の
usWinAscent
と
usWinDescent
の行箱の上下の決定に寄与しているように見えます。
vertical-align [83] CSS の vertical-align (baseline-shift)
では、選ばれた基線を基準に、上方 (横書きの上) を正とする値を使います。
[84] その移動量は <length> か <percentage> で、後者のときは
line-height に対する割合となります。