xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain CATTEAU <romain.catt...@gmail.com>
Subject Re: Several GraphicsNode instances per Element??
Date Mon, 20 Apr 2009 15:24:19 GMT

Hi Thomas,

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 is a small Swing application, based upon the CanvasFrame frame class.
That frame contains a SVGPanel instance, that includes :
- a SVG canvas. That canvas displays SVG data from the file "TEST.svg". Data
is loaded by means of the SVGLoader class. TEST.svg file is a simple SVG
file, that contains only a rectangle wrapped in a group the id of which is
"SHAPE". That group is in the defs elements and is located by means of a use
- 2 buttons. The first button is called "Add action". When pushing that
button, the application adds the "VEGSHAPE" group inside the "VEG" group.
"VEGSHAPE" group contains a red rectangle and a text made up of a number
"1.1" and a mnemonic "0". The "Show/hide number" button is available only
when the "add action" button has been pushed once (the "add action" button
then becomes disabled so that a single action can be added to the SVG). When
pushing the "show/hide" number button, the problem can be easily noticed :
we get the target view "0" as well as the previous view "1.1".... 

The content of the SVGDocument is saved as the output.svg SVG file (class
Exporter) when "add action" or "show/hide number" button is pushed. We can
notice that it contains a single instance of the "VEGSHAPE" group.
In the SVGPanel source code, I also get the graphics node corresponding to
the VEG group :


When running the application in debug mode, we can watch two graphics node
instances for the "VEGSHAPE" element.

Well, I hope that standalone testcase application will help you understand
my problem. Thanks for your help.

Best Regards.


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
>> 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 raw message