Hi Romain, Romain CATTEAU <[email protected]> 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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] >
