- From: Chris Lilley <chris@w3.org>
- Date: Fri, 11 Sep 2009 15:06:52 +0200
- To: Jeff Schiller <codedread@gmail.com>
- CC: robert@ocallahan.org, www-svg <www-svg@w3.org>
On Friday, September 11, 2009, 1:28:39 AM, Jeff wrote: JS> I'm afraid I still didn't understand the use case for allowing TRULY JS> arbitrary SVG content as children of the <glyph> element. Same use case as allowing a <use> to point to arbitrary SVG content. Indeed, text in SVG can be seen as a way of generating a bunch of use elements laid out one next to another according to some rules (advance width, font size, kerning). In other words, whatever the content creator can draw, and might be tempted to draw as a 'picture of text' they can also do, as real text. JS> Can we just JS> limit the elements that can be included as children of a <glyph>? The trick is to find the set of things that are allowed. And the one that you don't allow, people will complain about and get around by making just pictures of text instead of text. JS> I JS> would say any <path>, <g> as well as any "basic shape" as defined JS> here: http://www.w3.org/TR/SVG11/intro.html#Terminology and that these JS> elements cannot reference any content outside the <glyph> (for JS> example, masks, etc). Which they stops you doing masks. or filters. oh .... you allowed g. well, most things can be inside a g. More useful, I think, is to clarify the consequences of the hidden deep clone that results from each glyph being instantiated. For example, no user events will be received on those instantiated trees. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Friday, 11 September 2009 13:07:03 UTC