- 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>
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 desired). >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 viewbox? >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 :). Leonard
Received on Wednesday, 23 November 2011 18:44:00 UTC