W3C home > Mailing lists > Public > public-svgopentype@w3.org > November 2011

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

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 23 Nov 2011 18:51:48 +1100
Message-ID: <4ECCA614.8020908@mcc.id.au>
To: Sairus Patel <sppatel@adobe.com>
CC: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Hi Sairus.

On 23/11/11 12:22 PM, Sairus Patel 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.

Let's call it a document.

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

IDs in SVG must match the Name production in the XML spec:


so requiring the elements to be named "0", "1", etc. would result in a 
non-conforming SVG document.

Actually I'm not sure I like the idea of using specially formed IDs to 
indicate glyph IDs, since it takes away from the space of names that is 
currently entirely within the author's domain.  Can we introduce a new 
attribute here instead?  Or maybe repurpose glyphName="" to be available 
on every renderable element?

> 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 flag would be supplied at the time of initial document processing, I 
think, rather than for each glyph rendering, since whether animations 
are meant to run will need to be known up front by the SVG engine.

We should have a simple model where an element identified as being for 
glyph index n is rendered into a particular coordinate space (defined by 
the glyph metrics in the OT tables) as it normally would if referenced 
by a <use> element.  Thus <glyph> elements wouldn't render.  That will 
be simpler than defining that <glyph>s can also be used as actual 
glyphs, IMO.

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

Yes, that's fine, modulo my comments above about how glyph IDs are 
specified in the document.

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

I'm not sure I understand this.  Are you talking about an API for 
getting glyph outlines, like which have been discussed recently on 
www-svg?  Whether this API takes an existing <text> element (which is 
what my initial proposal has) or glyph IDs specifically probably doesn't 
affect the design decisions of SVG-in-OpenType fonts.


Received on Wednesday, 23 November 2011 07:52:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:45:50 UTC