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

On Wednesday, November 23, 2011, 8:51:48 AM, Cameron wrote:

CM> Hi Sairus.

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

CM> Let's call it a document.

Okay (although, I am thinking on a better way to organise the svg here).

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

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

CM>    http://www.w3.org/TR/SVG/struct.html#Core.attrib
CM>    http://www.w3.org/TR/xml/#NT-Name

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

Yes. 

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

Its much easier to add an attribute, such as glyphID, whose type is not ID and thus does not need to match the name production.

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

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

CM> We should have a simple model where an element identified as being for
CM> glyph index n is rendered into a particular coordinate space (defined by
CM> the glyph metrics in the OT tables) as it normally would if referenced
CM> by a <use> element. 

This is what the current glyph element does.


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

CM> Yes.

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

That could also be dealt with by re-using the glyph element but disallowing those attributes.

Note that this also gives a y-up coordinate system, as expected, rather than the y-down coordinate system used in the rest of SVG (both of these were by design - SVG uses y-down to be compatible with CSS, while glyphs use y-up to be compatible with type1 and truetype glyph coordinate systems).






-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Wednesday, 23 November 2011 15:20:48 UTC