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 Tue, 21 Apr 2009 15:45:31 GMT

Thanks a lot, Thomas. This problem is now solved!
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...
However, that fragment of code is an "historical" part of our application,
and that's why I didn't check it... We did it so as to be able to get the
bounding box of the svg root element. I have added a GVTTreeBuilderListener,
so that I can get that bbox in the gvtBuildCompleted method, and it works
fine.

As I wrote, the problem was located in an old fragment of the code. But we
started noticing the problem only after having modified the structure of the
SVG. Let's consider the SVG file used by the standalone test application :

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns:math="http://exslt.org/math"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2000/svg" contentScriptType="text/ecmascript"
zoomAndPan="magnify" contentStyleType="text/css" viewBox="0 0 1000 1000"
preserveAspectRatio="xMidYMid meet" version="1.1">
<style type="text/css" xml:space="preserve"><![CDATA[text {
font-family: LucidaSansTypewriter;
fill: black;
stroke: black;
stroke-width: 0.01;
text-anchor: middle;
}]]></style>
<rect fill="white" x="0" width="0" y="1000" height="1000" id="background"/>
<g id="VEG">
<g id="VEGSHAPE" transform="translate(100,100)">
<g id="VEGSHAPE1">
<rect fill="rgb(160,0,0)" x="0" width="200" height="200" y="0"
stroke="none"/>
<text style="text-anchor: middle; font-size: 50; fill: rgb(160,0,0)"
id="VEGSHAPE1TEXT" transform="translate(100,-20)">
<tspan dx="0" display="none">1.1</tspan>
<tspan dx="50" display="inline">0</tspan>
</text>
</g>
</g>
</g>
<defs>
<g id="SHAPE">
<desc>SHAPE</desc>
<rect x="0" y="0" fill="none" width="200" height="200" stroke="black"
stroke-width="10"/>
</g>
</defs>
<use x="100" y="100" xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="#SHAPE" xlink:type="simple" xlink:actuate="onLoad"
id="INSTANCE_SHAPE" xlink:show="embed"/>
</svg>

Before, the "VEG" group was located in the defs element and located through
a use element :

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns:math="http://exslt.org/math"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2000/svg" contentScriptType="text/ecmascript"
zoomAndPan="magnify" contentStyleType="text/css" viewBox="0 0 1000 1000"
preserveAspectRatio="xMidYMid meet" version="1.1">
<style type="text/css" xml:space="preserve"><![CDATA[text {
font-family: LucidaSansTypewriter;
fill: black;
stroke: black;
stroke-width: 0.01;
text-anchor: middle;
}]]></style>
<rect fill="white" x="0" width="0" y="1000" height="1000" id="background"/>
<defs>
<g id="SHAPE">
<desc>SHAPE</desc>
<rect x="0" y="0" fill="none" width="200" height="200" stroke="black"
stroke-width="10"/>
</g>
<g id="VEG">
<g id="VEGSHAPE" transform="translate(100,100)">
<g id="VEGSHAPE1">
<rect fill="rgb(160,0,0)" x="0" width="200" height="200" y="0"
stroke="none"/>
<text style="text-anchor: middle; font-size: 50; fill: rgb(160,0,0)"
id="VEGSHAPE1TEXT" transform="translate(100,-20)">
<tspan dx="0" display="none">1.1</tspan>
<tspan dx="50" display="inline">0</tspan>
</text>
</g>
</g>
</g>
</defs>
<use x="100" y="100" xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="#SHAPE" xlink:type="simple" xlink:actuate="onLoad"
id="INSTANCE_SHAPE" xlink:show="embed"/>
<use x="0" y="0" xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="#VEG" xlink:type="simple" xlink:actuate="onLoad"
id="INSTANCE_VEG" xlink:show="embed"/>
</svg>

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

One again, thanks for your help.

Regards.

Romain.



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