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

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

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Wed, 23 Nov 2011 10:43:19 -0800
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, Cameron McCormack <cam@mcc.id.au>, Sairus Patel <sppatel@adobe.com>
CC: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Message-ID: <CAF2A6C9.11448%lrosenth@adobe.com>
On 11/23/11 10:47 AM, "Levantovsky, Vladimir"
<Vladimir.Levantovsky@MonotypeImaging.com> wrote:
>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.

And are they separate glyph definitions in the same SVG OR separate SVG
blocks in the OT?  The former would allow for <use> and other shared
elements, plus not requiring duplication of data if not all glyphs
animate.  However, the latter would make it easier on the OT engine and a
clear differentiation of static vs. animated, so that additional
restrictions (scripting, etc.) could be put on the static versions (if

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

That interesting.  Are you thinking that you might have a "media query" on
the element, so that it could adjust itself based on "target size"?  If
not, what would be the use case for needing that info?  Wouldn't the SVG
engine just do the same thing it would do when drawing into any other

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

Given the design that Sairus has put forth, I don't see how that could be
possible.  The SVG engine doesn't (necessarily) have access to the rest of
the page/document - it's just drawing some "bits" into an area given it by
the OT engine (which got it from the layout engine).  How would this work,
for example, in a future version of Microsoft Word, Open Office or Adobe
Reader?  The SVG engine wouldn't be able to access the content over which
is would be drawing in order to do proper compositing.  For that matter,
the layout engine might be doing this all offscreen or separate buffers
(for performance or caching considerations).

But clearly this is going to be something we'll need to discuss :).

Received on Wednesday, 23 November 2011 18:44:00 UTC

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