xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Drake <st...@drakenz.com>
Subject Change to image/@xlink:href not seen by AnimatedAttributeListener
Date Mon, 04 Sep 2006 04:39:39 GMT

Hi,

I am trying to change an image in an svg document that is displayed using
JSVGComponent.  I am using the nightly build available at
http://arc.mcc.id.au/batik-nightly/batik-nightly-2006-08-26.zip

I perform the following steps:
1.  Load an svg document from a file.
2.  Add some <image> elements into the dom at marked positions.
3.  Set the images to an initial value using
setAttributeNS(XMLConstants.XLINK_NAMESPACE_URI,
XMLConstants.XLINK_HREF_ATTRIBUTE, uri);
4.  Create a gui using new JSVGComponent(null, true, false),
setDocumentState(ALWAYS_DYNAMIC) and setSVGDocument - so far so good.
5.  In response to a mouse event, change the image's uri using
setAttributeNS again (using the same method that sets the initial value).
The displayed image does not change!

I tested that the event was being properly dispatched by adding an event
listener for DOMAttrModified events to the document and verified that it was
notified.  I then found that in change 426986, SVGImageElementBridge
switched from handling DOMAttrModified events to handling updates of an
AnimatedLiveAttributeValue, so I added a test AnimatedAttributeListener to
the document, which was not notified.  Further, trying to get the value with
SVGOMElement.getLiveAttributeValue() returns null -
org.apache.batik.dom.svg.AbstractElement.attrModified() tries to update the
object returned by that method when the attribute is changed.

My application actually creates several pages using this process, and most
of the time it is only the first page/JSVGComponent created that exhibits
this behaviour, although switching to another page quickly, before the first
page is rendered, can cause other pages to be affected.

A workaround is to call SVGURIReference.getHref() on the image element,
which forces the animated value to be initialised.  Updates to the returned
SVGAnimatedString using setBaseVal(), or setting the uri in the normal
setAttributeNS() manner are then handled as expected.

That's as far as I have got - I don't really know whether I am doing
something wrong or if the recent changes introduced a bug, so I will try to
post back later with a concise test case, but I would greatly appreciate any
suggestions.

Regards,

Steve Drake

-- 
View this message in context: http://www.nabble.com/Change-to-image-%40xlink%3Ahref-not-seen-by-AnimatedAttributeListener-tf2213238.html#a6129818
Sent from the Batik - Users forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Mime
View raw message