xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject RE: textpath <path> clone affects text positioning?
Date Wed, 20 Aug 2008 10:21:32 GMT
Hi Nirmesh,

"Nirmesh Desai" <ndesai@autonomy.com> 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:helder.magalhaes@gmail.com] 
> Sent: Tuesday, August 19, 2008 7:15 AM
> To: batik-users@xmlgraphics.apache.org
> 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: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> 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