xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Several GraphicsNode instances per Element??
Date Wed, 22 Apr 2009 09:58:28 GMT
Hi Romain,

Romain CATTEAU <romain.catteau@gmail.com> wrote on 04/21/2009 11:45:31 AM:

> Thanks a lot, Thomas. This problem is now solved!

    Good.

> Well, it seems now obvious that this part of the code is a problem 
because
> CSS and SVG DOM interfaces initialization is already performed because 
the
> document is associated to a canvas...

   Right, both were created a text graphics node.

> And there was no problem when the "VEG" group was inside the defs 
elements.
> Do you know why?

  The way updates to used content are handled is different from normal
updates to the 'main line' SVG.  So I don't find this difference 
particularly
surprising.

> thomas.deweese wrote:
> > 
> > Hi Romain,
> > 
> > Romain CATTEAU <romain.catteau@gmail.com> wrote on 04/20/2009 11:24:19 
AM:
> > 
> >> Well, I haven't managed to find a solution to my problem. So, as you
> >> suggested, I've created a small standalone testcase application to 
> > exemplify
> >> the problem. Here is the zip file corresponding to the eclipse 
project,
> >> called GNPROBLEM (means Graphics Nodes Problem...) :
> >> 
> >> http://www.nabble.com/file/p23138884/GNPROBLEM.zip GNPROBLEM.zip 
> > 
> >    It would have been impossible to track the problem down without
> > this.  The problem is that you build a second GVT tree attached to
> > the document around line 168.  If you comment out that block 
> > everything works fine for your standalone application.
> > 
> >    If you need that for some reason in your main application then
> > you will need to find another way (probably by doing your work in
> > the "on load" event).
> > 
> >    I hope that helps.
> > 
> >> thomas.deweese wrote:
> >> > 
> >> > Hi Romain,
> >> > 
> >> > Romain CATTEAU <romain.catteau@gmail.com> wrote on 04/10/2009 
09:12:26 
> > AM:
> >> > 
> >> >> In that picture, you can notice a floodgate symbol in the 
background 
> > (it
> >> >> appears in black). We have added some SVG content to show that the


> >> > floodgate
> >> >> is opened. That additional content is made up of a :
> >> >> - a red triangle (path element),
> >> >> - a text : "17.1 0". That text is made up 2 text spans : "17.1" 
and 
> > "0".
> >> >> We then try to hide the text span "17.1" by setting the value of 
its 
> >> > display
> >> >> element to none. We also modify the dx attribute so as to center 
the 
> >> > text
> >> >> "0"
> >> > 
> >> >> As you can see, the behavior is a little bit strange. What we see 
is 
> > a
> >> >> combination of the target view "0" in the center and of the 
previous 
> >> > view
> >> >> ("17.1 O").
> >> > 
> >> >    I've never seen this sort of behavior before.
> >> > 
> >> >> However, the SVGDocument seems to be correct. We write the content

of 
> > 
> >> > the
> >> >> SVGDocument to a SVG file each time a modification is performed. 
Here 
> > is 
> >> > the
> >> >> corresponding part of the SVG file :
> >> > 
> >> >    There is something a little odd, both of the tspan's 
> >> > have display="none".  How are you saving your document?
> >> > 
> >> >> <g id="TMa255a744-0b63-42aa-abf9-4c6823ecc28a">
> >> >> <g id="TM59" transform="translate(427.53 ,208.3) rotate(0)">
> >> >> <path fill="rgb(160,0,0)" stroke-width="0.2" d="M-5.5,-3 L5.5,-3

> > L5.5,3 
> >> > z"
> >> >> stroke="rgb(160,0,0)"/>
> >> >> <text style="text-anchor: middle; font-size: 3.3; fill: 
rgb(160,0,0)"
> >> >> id="TMTEXT59" transform="translate(0,11.0) scale(1,-1)">
> >> >> <tspan display="none">17.1</tspan>
> >> >> <tspan dx="0" display="none">O</tspan>
> >> >> </text>
> >> >> </g>
> >> >> </g>
> >> >> 
> >> >> Moreover, everything's ok when we load the document in squiggle
> >> >> (SQUIGGLE_VIEW.png)
> >> >> http://www.nabble.com/file/p22987781/SQUIGGLE_VIEW.png 
> > SQUIGGLE_VIEW.png 
> >> > 
> >> > 
> >> >     This isn't necessarily a good test because improperly set 
> > attributes
> >> > can be 'fixed' by round tripping through a file (particularly 
> > namespace
> >> > issues).
> >> > 
> >> >> Everything happens as if there were several GraphicsNode instances


> > for 
> >> > the
> >> >> text Element the id of which id "TMTEXT59"
> >> >> In fact, we can detect events for each element. We can click on 
the 
> > text
> >> >> element corresponding to the "previous view" ("17.1 O") and we can


> > also
> >> >> click on the text element corresponding to the target view ("0"). 
In 
> >> > both
> >> >> cases, the id of the Element is the same : "TMTEXT59".
> >> > 
> >> >    Is the Element the same?  I.E. if you print the Object you get 
is 
> > the
> >> > object 'pointer' the same in both cases?
> >> > 
> >> >> Has somebody ever met such a strange situation? 
> >> > 
> >> >    My suspicion is that your update code is somehow creating 
multiple 
> >> > instances of the text element.  Can you create a standalone test 
case?
> >> > 
> >> 
> >> -- 
> >> View this message in context: http://www.nabble.com/Several-
> >> GraphicsNode-instances-per-Element---tp22987781p23138884.html
> >> Sent from the Batik - Users mailing list archive at Nabble.com.
> >> 
> >> 
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: 
batik-users-unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail: 
batik-users-help@xmlgraphics.apache.org
> >> 
> > 
> > 
> 
> -- 
> View this message in context: http://www.nabble.com/Several-
> GraphicsNode-instances-per-Element---tp22987781p23159005.html
> Sent from the Batik - Users mailing list archive 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