W3C

SVG Glyphs in OpenType Specification

Bringing Rich Graphic Expressivity to Fonts

Final Community Group Specification 09 October 2013

Latest version
http://example.org/foo
Alternative formats:
Microsoft Word Docx
Editors
Sairus Patel, Adobe
Cameron McCormack, Mozilla Corporation
Edwin Flores, Mozilla Corporation

Abstract

This specification defines the way for Open Font Format/OpenType fonts (CFF or TrueType) optionally to include glyphs defined as SVG. This allows for color, gradients, animation and other aspects of SVG’s rich graphics model. It has arisen primarily out of design discussions in the SVG Glyphs for Opentype Community Group, and out of the implementation by Mozilla Corporation in Firefox and Firefox OS. It is presented as a proposal to the Open Font Format and OpenType specifications.

Status of This Document

This specification was published by the SVG Glyphs for OpenType Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

Please send comments about this document to public-svgopentype@w3.org (public archive).

Table of Contents

1. Use cases and requirements

The primary use case for richly expressive glyphs is creative titling, drop-caps, and other display usage in digital publishing (e.g. HTML pages and e-magazines). Other use cases are e-learning materials, online advertisements, and Unicode emoticons for social media and text messaging.

A purely graphics-based solution for the above situations, e.g. a set of images that are to be manually arranged by the document author, is not acceptable since it would not allow for full semantic accessibility (e.g. searching, indexing), ease of user input, international text shaping, or font-specified kerning and other typographic features.

The proposed glyph description technology is SVG, a part of HTML5. Note that while the SVG 1.1 <font> element does allow for color and animation, its layout model is simple and lacks OpenType’s sophisticated international and typographic feature layout facilities. Nothing in the following proposal requires use of the SVG <font> element.

2. Specification proposal

At OT specification OT Tables, insert the following section just before the “Tables Related to Bitmap Glyphs” section. The OFF specification may insert it at the end of sec. 5 to avoid renumbering existing sections.

2.1 Tables Related to SVG Outlines

Tag

Name

SVG

SVG glyph descriptions

CPAL

Color Palette

TrueType or CFF OpenType fonts may contain an optional ‘SVG ’ table, which allows some or all glyphs in the font to be defined with color, gradients, or animation. It is not a requirement that an OT engine support this table.

Link the CPAL tag above to a separately provided CPAL proposal. Link the SVG tag above to a new table page, with the following content:

2.2 The SVG table

‘SVG ’ – SVG glyph descriptions table

This table contains SVG descriptions for some or all of the glyphs in the font. For every SVG glyph description, there must also exist a corresponding CFF or TT glyph description in the font.

2.2.1 Main header

Type

Name

Description

USHORT

version

Table version (starting at 0). Set to 0.

ULONG

offsetToSVGDocIndex

Offset (relative to the start of the SVG table) to the SVG Documents Index. Must be non-zero.

ULONG

reserved

Set to 0.

2.2.2 SVG Documents Index

The SVG Document Index is a set of SVG documents, each of which defines one or more glyph descriptions.

USHORT

numEntries

Number of SVG Document Index Entries. Must be non-zero.

SVG Document Index Entry

entries[numEntries]

Array of SVG Document Index Entries.

2.2.3 SVG Document Index Entry

Each SVG document index entry specifies a range [startGlyphID, endGlyphID], inclusive, of glyph IDs and the location of its associated SVG document in the SVG table.

USHORT

startGlyphID

The first glyph ID in the range described by this index entry.

USHORT

endGlyphID

The last glyph ID in the range described by this index entry. Must be >= startGlyphID.

ULONG

svgDocOffset

Offset from the beginning of the SVG Document Index to an SVG document. Must be non-zero.

ULONG

svgDocLength

Length of the SVG document. Must be non-zero.

Index entries must be arranged in order of increasing startGlyphID. The startGlyphID of an index entry must be greater than the endGlyphID of the previous index entry, if any.

For further details about the content of the SVG documents, see “Glyph identifiers” and the following sections below.

2.3 Color Palettes

The SVG glyph descriptions may contain color variables whose values are obtained either from one of the various color palettes in the Color Palette (CPAL) table or by other means, for example values specified by the user. The first color palette shall be the default one. It is strongly recommended that the default values for the color variables in the SVG documents be set to the same values as in the first color palette table, for implementations that may not support color palettes.

The variable names in SVG must be of the form “color<num>” where <num> is the parameter index in the range [0, numPaletteEntries–1], inclusive, expressed as a non–zero-padded decimal number. numPaletteEntries is defined in the CPAL table. See the “Glyph rendering” section below for how the values are to be passed to the SVG renderer.

2.4 Glyph identifiers

For each glyph ID in an SVG Document Index Entry’s [startGlyphID, endGlyphID] range, inclusive, the associated SVG document must contain an element with id “glyph<glyphID>”, where <glyphID> is the glyph ID expressed as a non–zero-padded decimal value. This element functions as the SVG glyph description for the glyph ID.

For example, say a font with maxp.numGlyphs=100 has SVG glyph definitions only for its last 5 glyphs. The last SVG glyph definition has its own SVG document, but the rest share an SVG document (say, to take advantage of shared graphical elements). There will be two index entries, the first with glyph ID range [95, 98] and the second with glyph ID range [99, 99]. The SVG document referenced by the first index entry will contain elements with id “glyph95”, “glyph96”, “glyph97”, and “glyph98”. The SVG document referenced by the second index entry will contain an element with id “glyph99”.

2.5 Glyph semantics and metrics

The glyph descriptions in the SVG documents are considered to be the SVG versions of the glyphs with the corresponding IDs in the CFF or glyf table. They are designed on an em specified in the head table’s unitsPerEm field, as with CFF and TrueType glyphs. SVG glyph definitions will be in SVG’s y-down coordinate system, with the default baseline at y=0. For example, the top of a capital letter may be at y=-800, and the bottom at y=0. This coordinate system will need to be translated appropriately to the coordinate system of the rest of the OT tables and the coordinate system of the graphics environment.

Glyph semantics are expressed in the usual OT way (cmap table followed by GSUB). Glyph metrics such as horizontal and vertical advances are specified in the usual OT tables (hmtx and vmtx), and glyph positioning adjustments by the GPOS or kern table.

As with CFF glyphs, no explicit glyph bounding boxes are recorded. The “ink” bounding box of the rendered SVG glyph should be used if a bounding box is desired; this box may be different for animated vs static renderings of the glyph.

Note that the glyph advances are static and not able to be made variable or animated.

2.6 Glyph rendering

The SVG glyph descriptions may be rendered statically or with animation enabled. Note that static rendering is done by not running any animations in the SVG document; this is different from running the document with animations running but at a snapshot time of zero seconds. Some clients may choose not to support – or may not be able to support – animation. Clients that support animation may still request, in certain cases, that the glyph be rendered statically, e.g. for printing to paper.

The following user agent style sheet must be applied to SVG documents processed from the SVG table:

:root {
  fill: context-fill;
  fill-opacity: context-fill-opacity;
  stroke: context-stroke;
  stroke-opacity: context-stroke-opacity;
  stroke-width: context-value;
  stroke-dasharray: context-value;
  stroke-dashoffset: context-value;
}

In addition, if the font engine supports color palettes, and color palette values are provided, the user agent style sheet must include CSS Custom Property declarations for the color variables. This is done by including ‘numPaletteEntries’ (defined in the CPAL table) declarations in the :root rule of the form:

var-color<num>: <color>;

where <num> is each of the values from zero to numPaletteEntries–1, inclusive, expressed as a non-zero-padded decimal number; and <color> is the <num> index within the desired Color Palette, expressed in SVG’s <color> format. An example entry in the style sheet is:

var-color0: rgba(255,0,0, 0.5);

and the corresponding usage in an SVG glyph description could be something like:

<path fill=var(color0) d="..."/>

Note that SVG’s context-fill value may be used in the glyph descriptions to denote the current text color.

2.6.1 Security

It is required that all rendering of SVG glyphs be done in the “secure animated mode” or “secure static mode” specified in the W3C document SVG Integration. These modes permit no script execution, external references, interactivity, or link traversal.

2.7 Text layout process

An implementation that supports the SVG table first does layout in the usual OT manner, using the cmap, GSUB, hmtx, and other OT layout tables. This results in a list of glyph IDs arranged at particular x,y positions on the surface (along with the appropriate scale/rotation matrices). At this point, for each such glyph ID, if an SVG glyph description is available for it, it is rendered (in static or animated mode, as appropriate and if supported by the engine); otherwise, the CFF or TT glyph description must be rendered. Since the glyph advances are the same in either case, and not allowed to be animated, switching between SVG and CFF/TT rendering, or between animated and static SVG, should not require re-layout of lines (unless line layout depends on ink bounding boxes).

3. Examples

Example fonts containing SVG tables are used in the pages:

colored emoji examples
http://people.mozilla.org/~jkew/opentype-svg/GeckoEmoji.html
(static color emoji)

bouncing ball snapshot
bouncing ball at different time
http://people.mozilla.org/~jkew/opentype-svg/soccer.html
(animated rotating ball)

The fonts are contained in the same directory as the html files above:
download GeckoEmoji ttf font
download GeckoEmoji woff font
download Soccer otf font

3. Changes

The following changes were made relative to the previous publication: