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: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Wed, 23 Nov 2011 10:47:22 -0500
To: Cameron McCormack <cam@mcc.id.au>, Sairus Patel <sppatel@adobe.com>
CC: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D1186E29119@wob-email-01.agfamonotype.org>
Combining responses to two emails from Cameron and Leonard:

On Wednesday, November 23, 2011 2:52 AM Cameron McCormack wrote:
> On 23/11/11 12:22 PM, Sairus Patel wrote:
> > 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:
>    http://www.w3.org/TR/SVG/struct.html#Core.attrib

>    http://www.w3.org/TR/xml/#NT-Name

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

I believe it would be a benefit to treat SVG document in OT as a standalone resource, and therefore, it needs to be compliant with XML spec. I think it can be easily done by introducing a new mapping table by which a glyphID is linked to an SVG element ID (I would rather keep element IDs as generic as possible).

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

I agree. The rendering mode depends on the target media (e.g. screen vs. paper), so the animation flag shouldn’t really be changed on a glyph by glyph basis. We also need to allow SVG documents to specify different content for animated / static glyphs. Considering the first frame of animated glyph as its static form may not always work as intended, e.g. if a glyph consists of multiple contours that are "assembled" together as a result of animation.

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

Besides the (x,y) positions for each glyph, we also need to make sure that they are scaled appropriately, so the target size should also be communicated for each glyph, I assume. And, if the coordinate spaces where the OT glyphs and SVG elements are defined can differ, we need to consider a mechanism to reconcile this.

On Wednesday, November 23, 2011 7:57 AM Leonard Rosenthol wrote:
> 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"?

It's definitely something we should keep in mind (like I said earlier, we need to consider how glyph coordinates and sizes are handled) but I am not sure if I'd want to allow clipping. It is conceivable that the designers' intent might be to have animated glyphs drown "all over the page" and this is okay if the end-result of the animation occupies the place inside the bounding box of a glyph. E.g., a bouncing ball animation where a glyph (like a smiley) is dropped into its place. For the same reasons, I think it’s a good idea to separate static and animated <g>.

Thank you and regards,

> 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
Received on Wednesday, 23 November 2011 15:47:58 UTC

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