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

In term of indexing - so indexing will be by simple numeric index (aka
glyph ID/GID)?  Any/all mapping from GID->CID/Unicode will happen using
standard OT cmaps, yes?  So the SVG can't be processed standalone (aka
outside the OT wrapper)?   (not saying this is a bad thing, just trying to
understand).

As I certainly don't want to be drawing a glyph at (x,y) and have it
drawing all over my page...Who is responsible for ensuring that the SVG
"glyph" doesn't draw outside of the bounding box defined for it by the
hmtx?  Would you expect the OT engine to setup clipping?  Is the SVG code
required to "draw inside the lines"?

So what is the purpose of the boolean for animation?  Do you propose a
separate "static" <g> and an animated <g>?  Are you expecting support for
a scripting system in glyph processing?  (I am hoping not since there
should be no script execution in glyph rendering)

Those are my questions right now :).

Leonard  




On 11/22/11 8:22 PM, "Sairus Patel" <sppatel@adobe.com> wrote:

>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 12:58:00 UTC