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