Thanks Thomas,
That worked perfectly. I had tried NS methods, but must have been careless somewhere. This is great group for a cool tech..! BR, Nirmesh ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2008 3:22 AM To: [email protected] Cc: [email protected] Subject: RE: textpath <path> clone affects text positioning? Hi Nirmesh, "Nirmesh Desai" <[EMAIL PROTECTED]> wrote on 08/19/2008 02:06:47 PM: > //use textpath found through new id > itemLabelTextPath.setAttribute('xlink:href','#'+textPathDefId); This isn't correct. You must use the namespace aware version of the DOM API's: itemLabelTextPath.setAttributeNS ("http://www.w3.org/1999/xlink";, 'xlink:href','#'+textPathDefId); > textpathDef.setAttribute('id',textPathDefId); > textpathDef.setAttribute('d',new_textpath); Technically all your other setAttribute calls should look like textpathDef.setAttributeNS(null, 'id',textPathDefId); textpathDef.setAttributeNS(null, 'd',new_textpath); I should also caution that if you try to create element's yourself rather than cloning them you must use the createElementNS methods rather than createElement. > -----Original Message----- > From: Helder Magalhães [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 19, 2008 7:15 AM > To: [email protected] > Subject: Re: textpath <path> clone affects text positioning? > > > FireFox and Renesis player seem to put the text in correct place, however > > batik svg viewer seems to somehow also use the 'd' defined in the template > > from where I clone the <path> element so the text keeps changing whenever I > > change the 'd' value in the 'template' <path>. > > > > I need to try to make the svg behave same in applet and the browsers. > > As always, creating and attaching a reduced test case [1] to the > message may help receiving more and more valuable feedback. (For this > case, apparently a single SVG file containing a script snippet and > target path elements will do the trick.) > > Just a though: are you deep cloning the element (i.e., > "cloneNode(true)" [2])?. If not, then it is Firefox and Renesis who > may be suffering from issues, as non-deep copies of DOM subtrees > should act as "use" elements, that is, when you manipulate a non-deep > cloned element, the referenced element is the one who is actually > changed. > > Hope this helps, > > Helder Magalhães > > [1] http://webkit.org/quality/reduction.html > [2] http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-3A0ED0A4 > > --------------------------------------------------------------------- > 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] >
