W3C home > Mailing lists > Public > www-svg@w3.org > September 2009

Re: Rendering arbitrary SVG content in SVG font glyphs

From: Alex Danilo <alex@abbra.com>
Date: Mon, 14 Sep 2009 20:52:10 +1000
Message-Id: <YIJYPK.B5MFDI26OLEN@abbra.com>
To: robert@ocallahan.org
Cc: Jeff Schiller <codedread@gmail.com>, www-svg <www-svg@w3.org>

Hi Roc,

--Original Message--:
>On Sat, Sep 12, 2009 at 2:23 AM, Alex Danilo <alex@abbra.com> wrote:
><use> doesn't clone.
>The effect of a 'use' element is as if the contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the 'use' element as its parent and all of the 'use' element's ancestors as its higher-level ancestors.
>That means that in a situation where cloning is observable, e.g. a <use> referring to a <foreignObject> containing an <iframe>, the implementation must clone.
>Roc's original concern about indirecting into
>another namespace via foreignObject is indeed a
>valid concern and I think Erik pointed out this
>is already well constrained by the earlier DTD.
>In fact it is not.
>This thread seems to have been born from a reluctance to write
>code to do what the specification described and ASV has implemented
>from a number of years ago, not to mention other implementations.
>Did ASV implement the arbitrary-SVG-content-in-<glyph> feature? We've seen that it's pretty common for implementations to claim SVG Font support without doing that hard part...

Well I checked for you.

If you try the attached file (a horribly bashed version of one of the tiny tests) you'll
see that they support arbitrary content and that content can be animated too.
(The test just adds an animated transparent rectangle to one of the glyphs).

Whether they went as far as foreignObject is another question.

>In any case, an implementation in ASV and a full, interoperable, performant implementation in a complete Web browser are very different tasks.

Sure, I'll grant you that.

The cloning description in the spec. and how some implementations work is indeed
something that could cause grief to a lot of people!

>Also, in Gecko our style resolution and rendering code assumes there is some
>kind of explicit shadow DOM. Trying to render the "shadow structure" with
>style resolution inheriting different values at each usage site but without
>constructing actual shadow DOM elements for each site would be very
>difficult to do. I'd be interested in hearing other implementors' opinions
>on this.

You're right on with this one.

Our implementation applies the CSS styling as the referenced 'clones' are seen,
so yes you have to apply it for each shadow node and that would become

_But_ it is feasible to optimize this operation using redundancy detection
techniques, but how to do that is probably a bit beyond this discussion.


>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

(image/svg+xml attachment: hacked-animate-elem-03-t.svg)

Received on Monday, 14 September 2009 10:54:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:18 UTC