まだ作成中
ToC
WOFF関係のパートはいれた。Brotliの詳細、OFF以降はまだ
sfntコンテナ構造を利用しているFont face: 特定のデザインパラメータによるグリフデータの一つの集合で、メトリクス値、名前、などのメタデータが添付されていることがあるFont resource: フォントとして機能する(最小でも最低限の)必要なテーブルセットを含むOpenTypeデータFont family: 共通のフォント名を持つフォントのセット、同じ名前がname ID 16 (Typographics Family Name)かname ID 1に記載されるAxis of variation: 同じファミリーの中でvariationとして変化させている種類Variable font: 同じファミリーの複数フォントフェイスを持つフォントリソース、OpenType Font Variationsの機構を利用するGlyph design grid: グリフのアウトラインがデザインされている平面Design-variation space: variationの軸で構成されるフォントファミリー内での変化、fvarテーブルに定義される軸によるn次元空間Variation data: variationで設定される値に対応するフォントフェースを実現するためのデフォルト値からの差異もしくは変換値Variation tables: OpenType Font Variationsに直結するテーブルは以下のリストになる
avar: Axis variationscvar: CVT (control value table) variationsfvar: font variationsgvar: glyph variationsHVAR: horizontal metrics variationsMVAR: metrics variationsVVAR: vertical metrics variationsPoint: グリフデザイングリッド中の平面上の座標Variation instance: variationの値の組のそれぞれに対応するインスタンスNamed instance: variation instanceのうちのfvarテーブルで固有の名前が定義されているもの (UIのドロップダウンでフォント名として出てくるようなやつ)User coordinate scale: あるvariationの軸における特徴づけに利用されるスケール
fvarテーブルに軸の利用される最大・最小が記述されより制限されることもある。Normalized coordinate scale: variable fontのデータから特定の表示用にするさいに、正規化の中でnormalized scale (-1から1の間)を適用して各軸のユーザスケールでのデータをこの正規化されたデータに変換する
fvarテーブルに各軸のスケールの最小・規定・最大値を指定可能で、それらが正規化の際に(-1, 0, 1)にマップされるavarテーブルにそれ以外の値のマッピングが定義されていることもあるTuple / N-tuple: variationの空間の中における座標を定義するのに利用される順序付きの座標値
tupleではない (OpenTypeではtuple variation dataとなる)Region: あるvariationでの変換が適用される領域
Regionが定義可能Master: フォント開発フローの中で特定のフォントフェースについて揃ったアウトラインデータを含むソースDeltas / Adjustment deltas: variation空間の中やある軸の一部分といった部分領域に対するデータに加える補正データDelta set: あるRegionに関連するAdjustment deltasのセットScalars: 特定のvariationで必要となる補正値を生成するためにdeltasに掛ける補正係数Interpolation: 補正値を計算するプロセスcmapテーブルを利用して、入力された文字コードの列をグリフIDの列に変換するGSUBテーブルを利用して、グリフIDの列に対して、代替配置・縦書き、リガチャなどの変換を加えるGPOSテーブルを利用して配置場所を、BASEテーブルからベースラインを取得、グリフを配置するdesign coordinatesにおいてデバイス非依存の改行位置を判定 (デバイス非依存の改行???)JSTFテーブルを利用して、揃え処理を行うdesign coordinatesからグリフを出力先に合わせてdevice coordinatesに変換するfvar (font variations)テーブルを持ち、利用しているvariationの種類が記述されており、既定値も定義されている
STAT (Style attributes)を各variationについての詳細の為に含めることができ、単独軸のパラメータについてや複数軸を合わせての名前付けができUIで利用されるfvarの仕様が更新され、fmtxが利用されなくなったxMinに一致し、headテーブルのflagsのbit 1が立っている必要があるheadテーブルのflagsのbit 5が落ちてる必要があるGPOSでの配置位置など)ので、GSUBやGPOSなど各テーブルの機能ごとでの変更テーブルが利用される。
rvrn (Required Variation Alternates)機能も参照glyfはグリフの既定のアウトライン、gvar (glyph variations)は各variationでの変更を記述する、などfvarに定義されている全軸の既定値の状態に対応するデータが可変のためのテーブルがなくなっている場合に利用されるfvar仕様にaxis tagとして定義されている (weightとか)
User coordinateとNormalized coordinateの関係は、min/default/maxの３点をマップした変換空間の座標変換
avarテーブルで定義でき、追加点を含む複数制御点による折れ線の線形変換GSUBのFeatureVariationsテーブルとrvrnを組み合わせることが可能。glyfテーブルに対しては、gvarテーブルのvariationのデータは、適用対象のRegion用のdeltaの値となる
cvarテーブルに入るOS/2テーブルに対してはMVARテーブルを利用する
MVARテーブル自体は他のgasp, hhea, post, vheaテーブルなどに対しても適用できるCFF2テーブルにはその中に含めることができる (CFF 1.0では対応していない)
CFF2のみでは不可能なので、hmtx/vmtxに加えてHVAR/VVARが必須hmtxとvmtxテーブルに対しては、それぞれHVARとVVARテーブルが対応する
glyfテーブルのxMinなどから四隅を算出できるがコスト高いことから、これらのテーブルを含めることが推奨されるGDEF, GPOS, JSTFを必要に応じて追加。また、BASEにvariationのデータを追加する。ltrmを利用して処理を行うltraを利用してより精緻なグリフ選択を行うiがOMPL (OpenType Mirroring Pairs List; U+0028/U+0029など)でjにマップされ、cmap(j)が有値なら、文字iについてcmap(j)のグリフを利用するrtlmを利用して処理を行うrtlaを利用してより精緻なグリフ選択を行う(一部)
cmap: 文字とグリフのマッピングhead: フォントヘッダhhea: 水平方向ヘッダhmtx: 水平方向のメトリクスmaxp: 最大プロファイルname: 名前付け用テーブルOS/2: OS/2とWindows特有のメトリクスpost: PostScript情報cvt : (optional) 制御値fpgm: (optional) フォントプログラムglyf: グリフのデータloca: データ位置の列prep: (optional) CVTプログラムgasp: (optional) グリッド合わせ、スキャン変換CFF : CFF 1.0データCFF2: CFF 2.0データVORG: (optional) 垂直原点、縦書き対応のフォントでは持つことを強く推奨されているSVG : SVGテーブルEBDT: ビットマップデータEBLC: ビットマップデータへの位置情報EBSC: スケールデータCBDT: カラービットマップデータCBLC: カラービットマップデータへの位置情報sbix: 標準的なビットマップ画像GSUB: グリフ代用情報 - 1対1、リガチャなどの1対多・多対多、芸術的な代替、コンテキスト依存GPOS: グリフ位置補正のためのX/Y位置情報 - 単独、グリフペア、草書体、付属マーク、コンテキスト依存BASE: スクリプトごとのベースラインオフセット情報JSTF: 空白とKashidaを含む揃えの情報GDEF: フォント中の全個別グリフの情報 - タイプ(simple, ligature, combining mark)、追加の点 (あれば)、リガチャグリフの場合に分割点MATH: 数式用レイアウトavar: 軸情報cvar: CVTに対して (TrueType)fvar: フォントバリエーションgvar: グリフに対して (TrueType)HVAR: 水平メトリクスに対してMVAR: メトリクスに対してSTAT: スタイルに対してVVAR: 垂直メトリクスに対してCOLR: 色テーブルCPAL: 色パレットCBDT: 色付きビットマップCBLC: CBDT位置情報sbix: 標準ビットマップ画像出の表記SVG : SVGでの表記DSIG: デジタル署名hdmx: 水平デバイスメトリクスkern: カーニングLTSH: 線形スレッショルドデータMERG: マージ用meta: メタデータSTAT: スタイル属性PCLT: PCL 5のデータVDMX: 垂直デバイスメトリクスvhea: 垂直メトリクスのヘッダvmtx: 垂直メトリクスuint8, int8, uint16, int16, uint24, uint32, int32FWORD (int16), UFWORD (uint16)F2DOT14 (2.14とも記述される、小数点部14bitの符号付実数、int16として評価して14bit/16384で割った値)LONGDATETIME: 64bit符号付整数で表す、1904年1/1 12:00真夜中、からの経過秒数Tag: uint8を4つ、テーブル、variation軸、スクリプト、言語、機能、ベースライン、などを示すタグ (0x20-0x7Eの4文字分)Version16Dot16: 32bitにパッケージされたメジャー・マイナーバージョンの値Offset16, Offset32
データレコードは上位の構造の中ではそのまま連続して並べられる。
各テーブルや全体におけるバージョンについて。
uint16: 通例0から始まるバージョンの値uint16: major/minorの２つの値、通常1.0から始まるuint32での定義された列挙値uint32の数値、DSIGとmetaでのみ利用されるVersion16Dot16表記、maxp, post, vheaでのみ利用される (後方互換性)メジャーバージョンの変更は必ず検出しなければならず、未対応なら読まない。マイナーバージョンはテーブル形式の後方互換性を保った変更に限られる。
単一のuint16,uint32でのバージョン番号はマイナーバージョンである。
予約されたフィールドについては、未対応の処理ソフトは無視し、書きだす際には0で埋める。
トップレベルのテーブルで、単一フォントの場合は先頭、コレクションの場合はTTCHeaderに記述される場所の開始位置になる。
searchRange, entrySelector, rangeShiftは高速バイナリサーチ構築のための追加データで、16倍はtableRecordのサイズ。
ただし、間違った値を入れる攻撃の可能性があるので、これらの値に依存した処理は非推奨。
uint32 sfntVersion: 0x00010000 (TrueTypeの場合) もしくはOTTO (0x4F54544F; CFFの場合)uint16 numTables: 含まれるテーブル数uint16 searchRange: numTablesに一致か小さい最大の2のべき乗値に16を掛けた値uint16 entrySelector: numTablesに一致か小さい最大の2のべき乗値のべきの値unit16 rangeShift: numTables * 16 - searchRangetableRecord: numTablesの数分の配列
Tag tableTag: glyfなどのテーブルのタグuint32 checksumOffset32 offset: フォントファイル先頭からのオフセットuint32 length: テーブルの長さ全てのテーブルは4byteでアラインされる。テーブルについてのみで、サブテーブルなどはこの限りではない。
.ttc(TrueType)もしくは.otc(CFF,CFF2)を追加することで構成される。また、データのテーブルはフォント間で共用可能。
TTCHeaderは1.0と2.0がある。2.0ではデジタル署名の領域(DSIG)が追加されている。デジタル署名なしの場合は0埋め。
TAG ttcTag: ttcfuint16 majorVersion: 1 or 2uint16 minorVersion: 0uint32 numFonts: TTC内のフォント数Offset32 tableDirectoryOffsets: numFonts数分のオフセット値の配列uint32 dsigTag: DSIGuint32 dsigLength: 署名の長さ、付けなければ0uint32 dsigOffset: TTCファイル先頭からのオフセットapplication/font-xxxやapplication/x-font-xxxのようなMIME型でなく、font/xxxの提案とレジストリ。まだProposed Standardの状態。
どのような種類のフォント形式があるかの一覧には役立ちそう。
以下のリストでparameterは基本的にカンマ区切りのリストで、同じ名前は同じ内容となる(ので初出のみ詳述)。
font/snft: Generic SFNT font
TTF (TrueType), CFF (PostScript/CFF), SVG (SVF)OTL (OpenType text layout), AAT (Apple Advanced Typography), SIL (Graphite SIL)font/ttf: TTF font
font/otf: OpenType Layout font
font/collection: Collection font
font/woff: WOFF 1.0font/woff2: WOFF 2.0MTXでは以下のような処理を行っており、その中からピックアップされている。Data setへの分割は取り入れられなかった部分。
glyf (重複情報削除), loca (いれない、デコード時に再生成), cvt (より小さく格納), hdmx (bitエンコード), VDMX (bitエンコード)に変換を掛けた
glyfの変換はTriplet Encodingを含め、WOFF2の変換に持ち込まれているglyfのアウトラインデータとその他のテーブル全部、cvt , hdmx, VDMX, glyfを圧縮、その他は非圧縮glyfのpush dataを格納
概要
ファイルの構成ブロックは以下、リストの並び順にファイルの中に並ぶ
wOF2ttcfなどのフォントコレクションといったフォーマットの指定0glyfテーブルなどの記述によって展開後に異なる可能性があるので参照用のみ）0..5の6bitがテーブル定義(63以外は定義値、63は次の値を利用)、6..7の2bitがプリプロセスでのtransformationのバージョン番号0-3を示すflags=63の時のテーブル名４文字、後ろ空白パディングCollectionHeaderとCollectionFontEntryのリストで構成され、一つのCollectionHeaderの直後に定義された数のCollectionFontEntryが並ぶCollectionHeaderはテーブル数の定義
CollectionFontEntryは各フォントに対応するテーブルのピックアップ用のデータ
sfnt versionnumTables分の配列): TableDirectoryのエントリを0始まりで数えたときの利用するテーブルの番号の配列indexの中に同じ番号が出現してもよい（逆に同じテーブルデータを複数回含むことは禁止）
glyfとlocaのペアについて、片方のみを共有しているような設定は禁止checkSumの値が正しいものである必要がある（再計算必要）、また全体に対してcheckSumAdjustmentの値を再計算しheadテーブルを更新するglyf, loca, hmtxに適用される
glyf: アウトラインデータの保持loca: それぞれのグリフのデータがglyfのどこに保持されているかのオフセットデータhmtx: グリフの水平方向のメトリクスの保持DSIGテーブルは含めないheadテーブルのflagsのbit 11をたてないといけない（ロスレス変換を経たということの提示のため）テーブル・フォントデータの並び順について（以下の詳細はsection 5.5から）
ascending alphabetical orderとしているが、WOFFでは処理の高速化のために制限をつけているglyfとlocaは常にペアでこの順に配置されている必要がある。reverse transformがglyfに設定されている時にlocaが必要なため。glyfとlocaはWOFFが一つのフォントセットのみの場合は間に別なものが入っていいが、フォントコレクションの場合は必ず対応関係のglyfとlocaは連続しなければならない
cmap, glyf, hhea, hmtx, loca, maxpの並び順は可能cmap, glyf, loca, hhea, hmtx, glyf, loca, maxp, post のような並び順になる必要があるglyf3: null transform (unmodified)0: table transformation, 重複情報の削除と実際のグリフアウトラインに対する効率的なエンコード
origLengthとデコード後のサイズは一致しない可能性があるglyfテーブル内でのオフセットがlocaテーブルの値になるglyfテーブルのデータ構造locaテーブルのオフセットの形式、headテーブルのindexToLocFormatと一致nCounterストリームのバイト数nPointsストリームのバイト数flagストリームのバイト数glyphストリームのサイズ数compositeストリームのバイト数bboxデータのバイト数、bboxBitmapとbboxStreamの合計instructionストリームのサイズcounterの数の配列counterのアウトライン点の数の配列componentフラグの値と付属するcomposite glyphのデータの配列numGlyphs分の長さの配列
4 * floor((numGlyphs + 31) / 32) (4byteパッド)bboxStreamに対応するbboxが格納されていれば立てるcounterがゼロ個の場合はbboxがすべて0であることを確認し、違ったらエンコーダは入力フォントを無効として却下する、okならフラグを下すinstruction setの配列glyphStreamに格納されるデータは一つ前の点座標に対するdeltaで表記され、先頭は(0, 0)に対するdeltaである。
バイト列からのdelta値の再構成の対応表は5.2節 Triplet Encodingにあり、
先頭バイトがIndexでflagStreamからの1バイトを含み2-5バイトで表記される値(glyphStreamからは1-4バイト)で格納され、計算後は(flag, x, y)のセットとなる。
flagStreamからのflagは
glyphStreamからの値を評価するためのインデックス
glyphStreamからのデータをX/Yに対して割り振るビット長 (割り振る場合は先頭ビットからXに利用)nCounterStreamからInt16 1データを読み、glyfのnumberOfCountersの値とする
locaは一つ前のグリフと同じ値に設定するnPointsStreamからnumberOfCounters分の255UInt16データを取得、それぞれがcounter内のデータ点数となり、endPtsOfCounters[]へ格納 (数でなく終了位置とするので-1する)flagStreamから一つ前に計算した全ポイント数分のUInt8データを取得、これがデータ点のフラグの配列になるglyphStreamから読んでいき、各データから計算したdelta-x/yをglyfに格納していくglyphStreamから一つの255UInt16の値を取得、instructionの配列の長さ(instructionLength)となるinstructionLength分のデータをinstructionStreamから取得するcompositeStreamから一つのUInt16の値を取得、TrueTypeのcomponent flag wordのデータとするcomponent flag wordのデータに対応する長さの追加データをcompositeStreamから読みだし (4-14バイト)、glyfに格納する
glyph index, arg1, arg2, optional scale, affine matrixのデータcomponent flag wordのFLAG_MORE_COMPONENTS (bit 5)が立っていれば再度このステップを繰り返すcomponent flag wordのどれかにFLAG_WE_HAVE_INSTRUCTIONS (bit 8)が立っているものがあれば、instructionが存在するのでsimple glyphの4-5ステップ目を行うbboxBitmapでデータが格納されているグリフについて、bboxStreamから4つのInt16を取得しxMin/yMin/xMax/yMaxの値とする
loca独立してtransformationの設定の値を持つが、glyfのtransformationに依存するので現実にはglyfの値と同じとなる
3: null transform (unmodified)
0: table transformation
glyfのデコーダの処理の中でlocaテーブルが作成されるのでデータはないtransformLengthは必ず0origLengthはnumGlyphs+1にグリフごとのサイズを掛けたもの、glyfのindexFormatが0の場合2バイト、それ以外は4バイトhmtx0: null transform (unmodified)1: table transformationを行う、hmtxテーブルの冗長部分を削る
hmtxはMin側にプロポーショナル・モノスペースの２種のグリフに対応する２つの配列を持つが、通常はTrueTypeの推奨通り同じなので省けるhmtxテーブルのデータ構造フォントがglyfテーブルを持つなどのTrueType系列の場合にのみ適用可能である。
エンコーダは全グリフについてleftSideBearingがbbox xMinに一致するかを確認する必要があり、一致していればこのtransformを適用する必要がある。
なお、コレクション内でhmtxテーブルが共有されている場合は全ての対応先についてこの確認をする必要がある。
TableDirectoryで変換が指定されている場合、bit 0/1は立て、bit 2-7は予約(0)となる。なので必ず0xC0、そしてadvanceWidthのみ存在することになる。lsb[]が存在しない、glyfのxMinからleftSideBearing[]が存在しない、glyfのxMinからadvanceWidthの配列、hheaテーブルのnumOfHMetricsの個数分left side bearingの配列、hheaテーブルのnumOfHMetricsの個数分
Flagsのbit 0が設定されていない場合のみ存在するleft side bearingの配列、numGlyphs - numOfHMetricsの数分
Flagsのbit 1が設定されていない場合のみ存在するEvaluation reportではCSSによるunicode-rangeでのstatic subsetが導入された後のwebfontの問題点として
などが挙げられている。これに対応するためにprogressive subsetが提案され、一つ目については必要なコードポイントの部分のみのダウンロード、 二つ目については整合性のある大きいセットから必要部分だけを持ってくることでshaping/kerningを整合性をもって適用することが可能になる。
フォント全体を落としてくるという操作に対して、unicode rangeでの複数woff2ファイルへの分割、以外に、２種類の方式が追加で評価されている
評価はいくつかの言語グループを想定して行われている。それぞれ転送されるであろうバイト数、転送速度によるコスト評価が行われた。
評価での結論は、patch subsetもrange requestも高い効果をもたらしたとするが、 patch subsetはサーバの更新が必要だがrange requestは既存のフレームワーク内で処理可能とも指摘。 今後の作業として以下の点を挙げている:
2021/3/22版ではpatch subsetの方式(Patch Based Incremental Transfer)のデータ型定義の途中までしかない。 転送方式などについてはなにもまだ掛れていない。データのEncodingにはCBOR (RFC #8949)を利用する。