SVG-in-OpenType

[11] OpenType ファイルには SVG 形式のグリフデータを格納できます。

仕様書

[13] SVG - Scalable vector graphics table (OpenType 1.9.1) - Typography | Microsoft Learn, PeterCon, 2024-05-31T17:42:32.000Z, 2024-11-17T08:54:20.185Z https://learn.microsoft.com/en-us/typography/opentype/spec/svg

`SVG` 表

[25] SVG 表では、グリフIDに対してSVG文書を対応付けることができます。 >>13

[107] グリフごとに異なるSVG文書とすることもできますし、複数のグリフで1つのSVG文書を共有することもできます。

[112] そのフォントのすべてのグリフIDに対して SVG文書を用意しなければならないことはありません。

[113] SVG のグリフ記述は、同じグリフIDの glyf, CFF , CFF2 のグリフの記述の代替となる記述を表します。両者は同じ抽象グリフの描写でなければなりません (must) 。 >>13

[125] OpenType の他の部分と同様に、エラー処理の規定はあまりありません。ただし SVG文書の処理については一部に規定があります。

SVG 形式のグリフの値

[38] SVG における SVG文書は、平文としてまたは gzip 符号化により記述できます。 >>13

[39] 実装はこの両方に対応しなければなりません (must) 。 >>13

[40] SVG の svgDocLength で指定するのは、符号化された状態のデータの長さであって、復号後の長さではありません。 >>13

[124] どちらであるかを明記する方法は用意されていません。先頭バイトで区別できます。

`SVG` における gzip

[35] RFC 1952 gzip 形式を使うことができます。 >>13

[36] gzip では RFC 1951 deflate 圧縮方式を使わなければなりません (must) 。 >>13

[37] 従って gzip を使う場合は先頭を 0x1F 0x8B 0x08 としなければなりません (must) 。 >>13

[123] 関連: SVGZ

SVG の要件

SVG の機能

[126] Web では普通は仕様書の最新版を使いますが、 OpenType における SVG は特定の版が参照されています。

[127] Webブラウザーではないフォントの実装も含めた相互運用性のための配慮なのでしょう。

[128] とはいえしかし機能を絞りながらも多くの機能が任意選択になっていて、実際にどの機能が使えるかは実装によってまったく違い、相互運用性は悲惨な状況です。

[129] 仕様書が緩いから相互運用性がなくなったというよりは、機能集合の合意形成に失敗したから仕様書がこの惨状なのでしょうが...

[26] SVG で使う SVG は、

Scalable Vector Graphics (SVG) 1.1 (Second Edition) specification at http://www.w3.org/TR/SVG11リンク.

であると定められています。 >>13

[27] 現時点でそのリンク先 http://www.w3.org/TR/SVG11 は、 >>28 にリダイレクトされ、 >>29 と同じものが表示されます。 2024-11-17T10:57:53.00Z

[130] SVG 1.1 第2版は W3C が SVG 1.2 の開発に失敗した後に SVG 1.1 に立ち返って不具合修正などを施したものです。それまでの版よりは幾分マシとはいえ、現在の水準から見ると曖昧で品質が低い仕様書です。また、古い時代の設計で、 HTML5 以後の新時代の設計に追いつこうと一部修正された SVG2 による変更 (例えば XLink からの脱却) が加わっていないものです。

[131] 開発タイミングの関係からこれを参照する以外に選択肢がなかったとはいえ、「最新版仕様」ではなく特定時点の仕様書を参照しているのに参照先がこれ、というのは不安があります。

[30] 以前の版では、

draft SVG 2リンク specification.

の context-fill とその他の context-* 特性値の利用が認められていました。 >>13

[33] ここでそのリンク先は https://www.w3.org/TR/SVG2/ >>31 で、現時点で >>32 と同じものが表示されます。「以前の版」がどの時点のものだったかは不明です。

[34] 現在の版ではこれら特性群の利用は非推奨 (deprecated) であります。適合実装は、これら特性群を対応しても構いませんが、対応することは必須 (required) でも推奨 (recommended) でもありません。フォントにおけるこれら特性群の利用は強く非推奨 (strongly discouraged) です。 >>13

[92] 適合する実装は、次のものをすべて対応しなければなりません (must) 。 >>13

[94] gradient (linearGradient 要素, radialGradient 要素)
[95] clipping path
[96] opacity 特性群
[93] 他に規定していないすべての SVG 1.1 の能力

[51] 適合する OpenType フォントは次の機能を使ってはなりません (must not) 。適合する応用は無視しなければなりません (must) 。 >>13

[52] text 要素, font 要素, およびそれらと関連付けられた要素
[53] foreignObject 要素
[54] switch 要素
[55] script 要素
[56] a 要素
[57] view 要素
[58] XSL
[59] 相対単位: em, ex
[60] imag 要素における SVG データ
[61] 色プロファイル: <icccolor> データ型, color-profile 要素, color-profile 特性, @color-profile
[62] contentStyleType 属性
[63] CSS2システム色キーワード

[97] 適合する OpenType フォントは次の機能を使ってはなりません (must not) 。 >>13

[98] rgba()

[64] SVG文書は次の機能を含めて構いませんが (may) 、実装は無視します。 >>13

[68] 次の機能は適合実装において必須 (required) の能力ではありませんが、応用によっては対応しているかもしれません (may) 。フォント開発者は想定対象環境で利用できるか評価するべきです (should) 。広範囲の環境での相互運用性のため利用を避けるべきです (should) 。 >>13

[69] style 要素
[70] style="" 属性
[71] CSS変数 (カスタム特性) >>91
[72] 媒体クエリー
[73] calc()
[74] CSSアニメーション >>119
[75] SVGアニメーション >>119
[76] SVG 子要素 (SVG child elements)
[77] filter 要素と関係する属性 (enableBackground を含む。)
[78] pattern 要素
[79] mask 要素
[80] marker 要素
[81] symbol 要素
[82] XML実体
[83] image 要素における JPEG と PNG 以外の画像形式
[84] 対話的能力 (イベント属性, zoomAndPan 属性, cursor 特性, cursor 要素)

[85] 「SVG 子要素」って何のこと?

[86] イベント要素ってイベントハンドラー属性のこと? script は禁止なのに on* 属性は禁止ではないの?

[87] XML実体が禁止というのは (宣言だけしても特に何も起こらないので当たり障りないはずなので) 実体参照が使わないべきということ? だとすると実装は XML の完全実装も要求されていない?

[88] 広く使われる想定のフォントには CSS によるスタイル付けよりも広く対応が見込まれる XML presentation attribute による指定が推奨 (recommended) されます。 >>13 (Note)

[119] CSSアニメーション, SVGアニメーションは広範囲の配布を想定したフォントでは推奨されません (not recommended) 。 >>13

[89] 媒体クエリーによる環境変化への対応は、対応している応用に於いても推奨されません (not recommended) 。 (他の OpenType の仕組みとの相互作用が可能であるので) 上位層表現フレームワーク (higher-level presentation framework) に於いて環境変化を扱うべきです (should) 。 >>13 (Note)

[90] 具体的に言えばフォント内部で媒体クエリーで条件分岐するよりもフォントを呼び出す CSS で @media を使って GSUB その他を使うなりするのが適切ということでしょう。

[100] color 特性は currentColor の値を上書きしますが、その他に使い道はないので、 color 値を設定するのは避けるべき (should) です。 >>13 (Note)

SVG 文書

[41] SVG文書の文字符号化は、 UTF-8 でなければなりません (must) 。 >>13

[42] SVG文書は XML文書であることも HTML構文で記述されることもありますが、 OpenType フォントの SVG文書は XML文書でなければなりません (must) 。 SVG の SVG文書に対応する応用は XML文書に対応しなければなりません (must) 。 HTML構文にも対応した SVG 構文解析ライブラリーを使っても構いません (may) 。 >>13

[43] SVG の応用は XML名前空間に完全に対応する必要はありません (not required) 。 >>13

[44] SVG文書の根要素は SVG を既定名前空間 http://www.w3.org/2000/svg として宣言しなければなりません (must) 。 >>13

[45] 本文で明言はされていませんが、示された実例では根要素の要素名は既定名前空間を使っています。 >>13 XML名前空間への対応を必須としない趣旨からすれば、これも要件と考えるべきなのでしょうが、なぜ規定がないのかは不明です。

[46] xlink:href 属性を使うときは、根要素で xmlns:xlink="http://www.w3.org/1999/xlink" としなければなりません (must) 。 >>13

[47] 他の XLink の属性を文書中で使ってはいけません (No ... may) 。 >>13

[48] 他の機構 (mechanisms) を文書中で使ってはいけません (No ... may) 。他の名前空間宣言を要素に使うべきではありません (no ... should) 。 >>13

[49] 仕様書では「No other XLink attributes or other mechanisms」を使ってはいけないとしています。 XLink がどこに掛かっているのかやや不明瞭ですが、「other ... or other ...」となっているので属性だけに XLink が掛かっていると考えるのが妥当でしょう。 XLink の機能もすべて属性で、他の機構はありません。しかしそうすると「他の機構」とは何かがよくわかりません。文脈を汲むなら SVG 本体機能でも XLink でもないもの全般でしょうか。続けて他の名前空間宣言もあるべきではないとしています。他のすべての機能が認められないのだとしたら、自動的に名前空間宣言も認められなくなるはずで、意図がわかりません。宣言だけなら機構に入らないという解釈なのでしょうか。機構の利用が禁止 (no ... may) なのに宣言は非推奨 (no ... should) と強さが違うのはよくわかりません。

[50] 後段はあるいは SVG や XLink のその他の形の宣言を禁じる意図もありそうですが。

SVG 文書におけるグリフ定義

[108] SVG においてグリフID g が参照する SVG文書は、 glyphg というIDを持つ要素を含まなければなりません (must) 。ここで g は零埋めしない10進数です。 >>13

[109] font engine は、当該要素が defs 要素の子供であり、 use 要素でその ID を参照したかのようにグリフをレンダリングしなければなりません (must) 。 >>13

[110] 仕様書で明文規定されているのはこれだけなのでやや曖昧ですが、例示を見ると当該要素から参照されている可能性がある、当該要素の兄弟の defs は含め、当該要素以外のグリフの要素は含まない、ということになっています。しかし当該要素以外のグリフの要素の子孫への参照が含まれるという可能性も排除されていません。結局 SVG文書の全体が必要になりそうに思われます。

[111] 従って

svg
- defs
  - 元の svg の子供すべて
- use

をレンダリングするのと同等、と考えるべきでしょうか。

[116] 仕様書には svg 要素に ID を付与した例文もいくつかあります。その場合は >>111 でもうまくいきません。 >>109 >>110 >>111 あたりはあくまで説明の便宜でそう書いていただけなのでしょう...

[118] svg 要素の属性も使われますし。文字列座標

メモ

[132] SVG の処理にはいくつかの異なる方式がありますが (スクリプトを実行するかなど)、ここで定められているのはそのいずれとも異なります。

[133] 従って通常の SVG の処理と共通化できるところも多いとはいえ、どの機能を有効にするかなどに多くの条件分岐が必要となります。

色の参照

[91] 実装のCSS変数への対応は任意選択です (>>68) が、 var() と CPAL 表の色を参照する色変数に対応することは強く推奨 (strongly recommended) されます。フォントは SVG文書内で独自の変数を定義するべきではありません (should not) 。 var() は色値を受け付ける属性や特性でのみ使うべき (should) で、値の最初の項目としてのみ出現するべき (should) です。 >>13

[101] CPAL パレットに対応しない実装でも、 var() には対応し、第2引数のフォールバック値を使うことが強く推奨 (strongly recommended) されます。広範囲の配布を想定するフォントはこの方法によって CPAL 未対応の応用でもフォールバック値を使えます。 >>13 (Note)

[102] text-layout engine や応用は、各パレット entry に対してカスタム特性を定義して色値を割り当てます。カスタム色特性は CPAL 表を含むフォントのみ定義するべきです (should) 。応用はカスタム特性の値を一般的には CPAL のパレット entry を使って設定するべきです (should) が、利用者入力その他の方法で値を割り当てることもできます。 CPAL のパレットの entry から値を割り当てるときは、通常は最初のパレットを使うべき (should) ですが、 USABLE_WITH_LIGHT_BACKGROUND や USABLE_WITH_DARK_BACKGROUND のフラグが付いたパレットがフォントに含まれるときは、そのいずれかを既定値として使えます。 >>13

[103] いずれにせよカスタム特性の名前は --colorn の形式で、 n は0埋めしない10進数で、 --color0, --color1, ... と numPaletteEntries より 1 小さな値までとしなければなりません (must) 。 >>13

[104] CPAL 色 entry が shape element の特性 fill や stroke, gradient stop element の stop-color, feFlood filter element の flood-color 特性に適用されるときは、 α値は [ 0, 1 ] の範囲に変換し、同じ要素の対応する特性 fill-opacity, stroke-opacity, stop-opacity, flood-opacity に乗じなければなりません (must) 。 >>13
[105] 実装がフィルター feDiffuseLighting や feSpecularLighting に対応する場合でパレット entry が lighting-color 特性に適用される場合は、 α値は無視されます。 >>13
[106] これらの形で要素の opacity 特性にα値が適用されるときでも、子要素に継承されるのは元々の特性値です。もっとも色の特性値を構成するα値もその特性に於いて継承されます。 >>13

[99] currentColor の初期値は、 text-layout engine や応用環境によって設定しなければなりません (must) 。応用に於いて最適なものを設定できます。一般には当該文章 (text) の連なりに適用される文章前景色とすることが推奨 (recommended) されます。 >>13

レンダリング

[114] まず通常の方法で text layout を行ってグリフIDの列と x, y 位置 (と scale や rotation の行列) を得ます。次に SVG のグリフ記述があれば、それを通常のグリフ記述のかわりに使います。 >>13

[115] glyph ink bounding box には多少変化もあるかもしれませんが、 advance width や advance height は変化しません。 line layout が bounding box に依存する場合を除き、行の再度の layout は必須とならないはずです (should not require) 。 >>13

[117] 座標については文字列座標系を参照。

[120] SVGアニメーション, CSSアニメーションに対応した応用は、場合によっては (例えば印刷時)、静的なレンダリングを必須 (required) とするかもしれません (may) 。静的なレンダリングは、 SVG文書中のアニメーションを無視して実行させないことで得ることにご注意 (アニメーションを実行して時刻 0 の初期フレームを撮影するのではありません)。 >>13

[121] advance width, advance height はアニメーションで変化させられません。 bounding box はアニメーションで変化することがあります。文字列座標系 bounding box が変化するとしても、再配置は起きないので、他の text element との衝突を防ぐために advance width / advance height とフォントの default line metrics の中にとどまるべきです (should) 。 >>13