SVGOpenTypeFonts

Introduction

Use Cases

SVG Fonts address some kinds of use-cases which cannot be addressed using current OpenType-based solutions:

• Glyphs of arbitary SVG content (including animation)
  • 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
• Create and manipulate structured font data via script and/or text editor
  • Web-based font editors

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?

SVG OpenType Fonts

Brainstorming exercise: what if we defined an XML serialization of OpenType fonts? Like TTX except better:

• Use attributes instead of elements where possible.
• Where values have sensible defaults, allow them to be omitted.
• Where values are defined in the spec as being easily computable from other font data, compute them in the user-agent. Automatically computing bounds for glyphs would help a lot.

Then we could extend the format to allow arbitary SVG content for some or all of the glyphs. We would use OpenType to shape text and apply typographical features, then use SVG just to render the glyphs.

Compatibility With SVG 1.1 Fonts

We should design the serialization to be compatible with a subset of SVG 1.1 Fonts wherever it's easy to do so. If we do this, the proposal can be viewed as taking a subset of SVG 1.1 Fonts, redefining it to be based on OpenType (except for the actual glyph rendering), then adding in syntax for OpenType features such as complex shaping and whatever else is needed. It seems plausible that this would end up being compatible with most SVG 1.1 Fonts usage.

API

• Support referencing SVG Opentype Font elements from @font-face and the SVG 'font' attribute
• Add an API that takes a DOM reference to a font element and returns a Blob for a binary OpenType font (SVG glyphs will be discarded)
• Potentially we could also add an API to convert binary OpenType font data to a DOM subtree

Implementation

The simple way to do it would be to generate actual OpenType font data, excluding SVG glyph content, and pass that data to Harfbuzz for shaping. Then when drawing glyphs, call back to layout to draw glyphs that have SVG content. For bonus points, convert glyphs consisting of SVG paths into OpenType glyphs when possible, so we get subpixel rendering.

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.

A better design would be to specify new values for 'stroke', 'fill' and 'stroke-width' such as 'text-stroke', 'text-fill' and 'text-stroke-width' to be used in glyphs. These new values would automatically grab the stroke, fill and stroke-width from the text, rescaling them as necessary.

Where We Are At The Moment

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 graphics elements or container elements. glyphid is a number specifying which glyph ID is associated with this glyph.

glyphchar is a string of at most one character optionally followed by a unicode variation selector. The glyph ID to associate with the glyph is then resolved using the cmap table.

If two elements have the same glyph ID, then the first element in the document with that glyph ID is associated with it.

The 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.

There are two new paint values objectFill and objectStroke for use in SVG glyphs. These values inherit the paint from the outer object. We also plan on adding things like objectStrokeWidth, objectStrokeDasharray, 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.