Re: xlink:href Thanks but...
- --- In email@example.com, jstanley@e... wrote:
> Thanks very much, I kinda figured that xlink:href is in the SVG
> parser glad to hear it confirmed. So I guess that means that my
> tranformer can't define a competing xlink namespace in the sameSVG
> document. Therefore, I am screwed since I have to have a defined
> xlink namespace in my xsl file to get the xsl parser to parse the
> document...but the svg viewer has a globally defined xlink
> Will using the same uri (I am currently using
> xmlns:xlink="http://www.w3.org/TR/1999/WD-xptr-19991206 ") as the
> viewer can I avoid this problem? If so what is the uri for xlinkin
> the svg viewer?Declare xlink namespace as xmlns:xlink="http://www.w3.org/1999/xlink",
it should work in Adobe SVG 2.0 beta and in all later releases.
There was an error in the SVG spec draft, which version 1.0 picked
up, so it will not work in version 1.0 (it expects
http://www.w3.org/2000/xlink/namespace, I think).
> Thanks for your prompt reply. Looking for the day I can help
> else out.namespace
> --- In firstname.lastname@example.org, "Antoine Quint" <antoine@k...>
> > | > hence "xlink:href" IS SVG and does not require a namespace to
> > | be specified.
> > |
> > | No. However, if you use a DOCTYPE declaration, all the
> > | specification comes for free - so, you don't have to type itinto
> your SVGwas
> > | document.
> > Haha, thanks very much Chris. I didn't know the Xlink namespace
> > in the SVG doctype, now I *really* get it. I am using the doctype
> > but I didn't really know what was going on behind the scene.
> > antoine
- Back to the performance problem. If you recall, animated Objects tend to go
slower the farther apart they are. The two examples I posted previously
This is pretty well the opposite of what you would expect since the farther
apart they are, the less chance there is of a collision which would require
more processing. In fact, in the examples everything seems to go the fastest
when they do collide.
The problem I'll bet, is that the Adobe viewer takes any Object that has
changed each frame and then Invalidates a Rectangle that will fit their
maximum extents. If two small and very simple Objects change at opposite
corners of the display area, the entire display area will be recalculated. I
suspect the Viewer needs to be modified to calculate the bounding box of
animated objects independently.