Re: foreignObject questions

Leonard,
Many of the issues relating to extensibility in general are being left
unspecified for SVG 1.0 because of the many inherent complex issues, most
of which affect many different W3C specifications, including DOM, CSS, XSL,
SVG, MathML and HTML, to just name a few.

For SVG 1.0, the goal with extensibility is very unambitious. The idea is
to put in enough hooks that implementers can add private extensions in a
private way, but to achieve the following bits of good behavior:

1) The extensions use XML namespaces properly to express their elements and
attributes
2) The extension define a URL which is the test string for the
'requiredExtensions' attribute
3) We recommend that extensions be wrapped inside a 'switch' with
fallback/alternative rendering when the document is viewed by a different
implementation that doesn't support the given extension. Something like:

<switch>
   <foreignObject  x= y= width= height= 

requiredExtensions="http://example.org/MyExtension/1.0">
      <z:wrappingText xmlns:z="http://example.org/WrappingText">
          <!-- Other elements with the 'z:' prefix -->
      </z:wrappingText>
   </foreignObject>
   <!-- If the extension is not supported, then a raster is displayed -->
   <image xlink:href="..." x= y= width= height= />
</switch>

Lots of the people in the SVG working group want to be more ambitious
regarding extensibility in future versions of SVG.

Regarding your specific questions below:

At 11:49 AM 8/2/00 -0400, Leonard Rosenthol wrote:
>In my SVG tools, I am looking at implementing foreignObject to 
>support text wrapping (as per the recommendations of the 20000629 
>spec).  However, in doing so, come up with a number of unanswered 
>questions, that I hope someone can answer for me.
>
>First, a hopefully simple one.  Are coordinates (and transforms) 
>inside of a foreignObject relative a new "origin" just for that 
>object, or absolute on the entire SVG document?

The current spec says in section 7.9
(http://www.w3.org/TR/SVG/coords.html#EstablishingANewViewport) that a
'foreignObject' creates a new viewport, and that by doing so, there is a
new coordinate system which has its origin at the top/left of that viewport.

>
>Second, the specs (20000629) state that items inside of a 
>foreignObject are "(subject to SVG transformations and compositing)", 
>yet I don't see how that information would either be passed along to 
>the "object renderer" OR how the "object renderer" is to return 
>information that can then be transformed/composited.

This is one of the areas that we are leaving unspecified for SVG 1.0 and
hope to address in future versions of SVG. This is particularly tricky from
a standards perspective as you might have two different plugins needing to
talk to each other. As of today, the W3C hasn't figured out how to define
standards to support such a facility, and the SVG group didn't feel it
could tackle this problem with SVG 1.0 with all of the other work on our
plate.

If an implementer, such as Adobe or IBM or CSIRO or Jackaroo implemented
the extension, then of course we could pull this off pretty easily as
everything would be in a single code base.

>
>And third, following up on that, are the transforms that are "in 
>place" (currently on the "state stack") at the time the foreignObject 
>is to be rendered applied AFTER the entire object is rendered OR it 
>to be used as a starting transform for the object contents?

I'm not sure I understand the distinction.

The model in my mind is that the foreign object returns the equivalent of
an SVG display list (potentially as trivial as a raster image) to the SVG
processor, and then the SVG processor renders that display list after
applying any transformations, opacity settings or filters that might be
applied to the foreign object due to its being embedded inside of other SVG.

Jon

Received on Wednesday, 2 August 2000 13:25:12 UTC