SVGOpenTypeFonts

Introduction

Use Cases

SVG Fonts address some use-cases which cannot be addressed using current OpenType-based solutions. For example:

• Editable text where the glyphs display a "shiver" effect
• Draw freehand graphics with self-intersecting curves and use them as glyphs for a font
• Japanese "emoji" with colored glyphs

Limitations Of SVG 1.1 Fonts

Internationalization

SVG Fonts have very weak shaping support, which makes them unusable with Indic and other languages. Therefore we need a solution to address the above use-cases that also handles complex shaping. OpenType already supports shaping for most of the world's languages and because of the large ongoing investment in OpenType fonts and processing engines, will broaden its support over time. So, can we leverage OpenType to handle the above use-cases?

Advanced Font Features

SVG Fonts lack support for features such as stylistic alternates.

Style Inheritance

The way SVG font glyphs inherit style from the text is both broken for authors and difficult to implement.

An example of how it's broken for authors: if the author specifies 'stroke-width:2' on a piece of text where some characters are rendered with system font F and other characters are rendered with SVG font S, and the glyphs of S contain simple path shapes, then the glyphs of F get a stroke width of 2 user-space units, but the glyphs of S get a stroke width of 2 glyph-space units, which will typically be invisible.

It's difficult to implement because Gecko (and Webkit, and probably other engines) keep persistent computed style data attached to DOM nodes, so having the style inherit differently depending on how the nodes are being used is inefficient and intrusive.

SVG OpenType Fonts

Idea: embed SVG glyph data in OpenType fonts, and draw glyphs by rendering that SVG. Use OpenType data for everything else (measurement, shaping, etc).

Prototype Implementation

This work is going on in bug 719286.

The SVG table

We define a new optional OpenType table 'SVG '. This table contains a UTF-8 encoded SVG document.

Structure of the SVG Document

Two additional attributes are supported in this SVG document: glyphid and glyphchar, which may be used on any SVG graphic element or container element.

glyphid is a number specifying a glyph ID. That glyph ID is rendered using that element.

glyphchar is a string of one character optionally followed by a Unicode Variation Selector. The glyph ID to associate with the glyph is then resolved using the cmap table. That glyph ID is rendered using that element.

If a glyph ID could be rendered by more than one element, then the first element in the document for that glyph ID wins.

SVG Glyphs

The glyphs themselves have an em-height of 1000 units (although maybe worth changing to 2048 to match TrueType convention) with the baseline at y=0. The width:height ratio of the glyph is to be the same as in the TrueType font.

Two new paint server values are defined for use in SVG glyphs: objectFill and objectStroke. These values specify the fill or stroke applied to the text in the document that uses this font. Unlike SVG 1.1's style inheritance approach, they automatically take account of the change in coordinate systems from the document containing the text to the glyph document. We also plan to add additional values objectFillOpacity, objectStrokeOpacity, and objectValue (for stroke-width, stroke-dash-array, etc).

Adobe's Proposal

Adobe are keen on a similar idea, an early proposal of which can be found here.

The main differences I can see are that each glyph definition has a whole SVG document. Also, they have two glyph definitions per actual glyph -- one static, one animated. I think we should just allow the author to specify a specific frame to use when not animating; I can't really think of any use case where the static version wouldn't be a frame of the animated one.