RE: FW: [OpenType] Update on color/animation in OT via SVG; new W3C Community Group

Regarding item #3 below, my current thinking is to go with a variant of (c): one SVG document (document fragment? I'm not sure of the correct terminology) that would simply contain elements with id's ranging from 0 to numGlyphs-1.

We won't mandate the document fragment be organized in any particular way. It can use g elements, or it can even use SVG fonts. It simply has to have element id's from 0 to numGlyphs-1, where numGlyphs is taken from the usual place in OT: the 'maxp' table.

This way, the OT engine's interface with its SVG rasterizer is simple: Display element id N at (x,y), with an additional boolean that indicates whether animation is OK (e.g. we want to disable animation when printing to paper). The display must be done in "secure animated mode."

The OT engine does this at the end of its text layout process (in which is uses the 'cmap', 'hmtx', 'GSUB', 'GPOS' and other OT tables), when all it has is a list of glyph IDs and (x,y) positions for each of the glyph IDs, and it is ready to display something.

This way, the SVG document fragment within the OT 'SVG ' table is pretty much a black box to the OT spec and thus the OT engine. Whether a font vendor uses an SVG font or not would depend on whether the target rasterizer supports SVG fonts, among other things.

The concern that SVG fonts contain their own concept of Unicode values, withs, and ligatures which could thus be in conflict with the OT 'cmap', 'hmtx' and 'GSUB' equivalents is rendered moot by the interface above, which doesn't allow the SVG rasterizer to make any text-related decisions. It simply has to display an element ID at a particular position.

Thoughts?

(And yes, another interface would involve "getting outlines" -- in case the designer wants to apply special effects on the outlines -- and that too would be keyed only by element ID.)

Sairus




----
From: Sairus Patel <sppatel@adobe.com>
Date: Fri, 28 Oct 2011 08:25:41 -0700
To: "public-svgopentype@w3.org" <public-svgopentype@w3.org>

[...]
3. *** Options for the format of the 'SVG ' table: ***

a. An entire SVG <font> element, with <glyph> elements in it

b. A separate <svg> element for each glyph, accessed by an offset and length in the 'SVG ' table (Adobe Draft 1 posted to this list).

c. A single <svg> element container with clearly identified elements, e.g. <g> elements with unique id's corresponding to each glyph, but no <font> or <glyph> element present.

d. A "shared" chunk at the beginning, followed by a separate chunk for each glyph.

We don't want (a) since it involves SVG <font>s, a facility that has severely limited notions of encoding and glyph substitution/positioning, and a facility that seems to be on its way out in the spec world. We also don't like the fact that it involves data duplicated in other OT tables e.g. glyph widths or encodings.

Option (b) wouldn't allow glyphs to share data, and we'd have to mandate that the timeline be the same for each <svg> element, but the advantage of it is that each glyph would be treated as a stand-alone entity, which could avoid loading in all glyphs into memory.

Option (c) is attractive since it allows sharing between glyphs, but may mean that all glyphs would need to be loaded into the DOM at the same time.

We also discussed how we could allow static and animated versions of a glyph in one single element rather than specifying separate elements.
[...]

Received on Wednesday, 23 November 2011 01:22:53 UTC