Thanks for info. Surprise to me. I have always used local names with the second parameter, when scripting adobe plugin.
I just tested this with ASV3, and setting works. For my surprise, getting does not. image.setAttributeNS(xlinkNS, "xlink:href", "http://whatever";); image.getAttributeNS(xlinkNS, "xlink:href") is not there image.getAttributeNS(xlinkNS, "href") == "http://whatever";; Yet another bug in ASV3? I wonder then what's wrong then with the original script. In my experience, checking that no parameter is undefined has solved a lot of problems. Kari -----Original Message----- From: Vincent Hardy [mailto:[EMAIL PROTECTED] Sent: 10 July 2003 08:29 To: Batik Users Subject: Re: Loading images in ECMA scripts Actually, the second parameter on setAttributeNS takes a qualified name, so "xlink:href" is correct for the second attribute. There are examples using this syntax in the CVS repository (e.g., samples/tests/spec/scripting/use.svg). Vincent. Kari Hoijarvi wrote: >Try > > image.setAttributeNS(xlinkNS, "href", url); > >without the "xlink:" in the attribute name. The >namespace is identified by the namespace URI only. > >Kari > >-----Original Message----- >From: Jens Heidrich [mailto:[EMAIL PROTECTED] >Sent: 10 July 2003 04:05 >To: [EMAIL PROTECTED] >Subject: Loading images in ECMA scripts > > >Hello, > >we are using SVG in order to display charts, that use JavaScript to >support some simple interaction. We discovered a strange behavior when >trying to change the "href" attribute of an image by an ECMA script: > >function load_image(url) { > image = document.getElementById("image"); > image.setAttributeNS(xlinkNS, "xlink:href", url); >} > >Our aim was to change the image by clicking on a certain SVG element. >According to the squiggle DOM Viewer the DOM is adapted accordingly by >the script (that is, it includes an attribute "xlink:href" and the >corresponding, transmitted URL), but the displayed image is still the >same (and shows the image of the old URL). Other attribute changes (like >size or position) seem to work as expected. > >We discovered this while using Batik 1.5 beta4b and beta5. We are >running Batik under Windows 2000, JDK 1.4.1_01. > >Any help will be appreciated. > > >Regards, > >Jens > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
