How to svg font spec quirks and implementation reference
- Step 1Read the structure — <defs><font id="..."><font-face .../><glyph unicode="A" d="..."/>...</font></defs>. The font element is in defs (referenced by font-family in user CSS). Each glyph carries unicode + path data + horiz-adv-x.
- Step 2Understand coordinate flip — OpenType uses Y-up (origin bottom-left); SVG uses Y-down (origin top-left). The JAD tool extracts paths in OpenType space and emits them with the SVG-Y convention. Some legacy implementations got this wrong and rendered fonts upside-down.
- Step 3Check kerning encoding — <hkern u1="A" u2="V" k="50"/> — pair-based kerning. Many SVG Font consumers ignore hkern entirely. The OpenType GPOS table is far richer; SVG Font's hkern was always a poor approximation.
Frequently asked questions
Why was kerning so badly supported?+
hkern was a simple pair-only model that couldn't express OpenType's class-based and contextual kerning. Implementing it properly meant building two parallel kerning systems; most browsers shipped neither or both badly.
Does the SVG Font support OpenType features?+
Barely. SVG Font has primitive <missing-glyph> and <vkern> support but no equivalent for GSUB layout features (ligatures, contextual alternates). Modern OpenType features are simply not expressible in SVG Font.
Why is units-per-em important?+
It defines the coordinate space for path data. Standard OpenType uses 1000 (CFF) or 2048 (TTF). The font-face element's units-per-em attribute tells consumers how to scale glyphs. Mismatched units between font-face and glyph data is a common source of rendering bugs.
Privacy first
Every JAD Font tool runs entirely in your browser using opentype.js and the wawoff2 WASM Brotli encoder. Your fonts never leave your device — verified by zero outbound network requests during processing.