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, 14 Apr 2009 15:03:09 GMT

Hi Thomas.

Thanks for your feedback. I indeed made a mistake to the extent that I did
not copy the content of the SVG backup file at the right moment. Sorry. Here
is the correct SVG fragment :

<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="inline">O</tspan>
</text>
</g>
</g>

I use the following code to save the SVGDocument instance :

/**
	 * \brief This method dumps a DOM document to a svg file.
	 * \param[in] 	doc	DOM document to save
	 * \param[in] 	filename	name of the backup file
	 */
	public void saveAsSVG(Document doc, String filename) {
		try
		{
			Source source = new DOMSource(doc);
			Result result = new StreamResult(filename);

			// Write the DOM document to the file
			Transformer xformer = TransformerFactory.newInstance()
			.newTransformer();
			xformer.setOutputProperty(OutputKeys.INDENT, "yes");
			xformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8");
			xformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "no");
			xformer.transform(source, result);
		} 
		catch (TransformerConfigurationException ex)
		{
		
LogManager.getInstance().log("Exporter>saveAsXML","TransformerConfigurationException",ex,LogLevel.ERROR);
		} 
		catch (TransformerException ex)
		{
		
LogManager.getInstance().log("Exporter>saveAsXML","TransformerException",ex,LogLevel.ERROR);
		}
	}

We get exactly the same reference object when clicking on the text
corresponding to the target view "O" or on the text corresponding to the
previous view "17.1 O"...

The behavior indeed gives the impression that we create multiple instances
of one text element, but I haven't managed to prove it so far. Moreover, one
thing is really strange. The problem can be noticed only only for new
elements created after SVGDocument loading, and not for elements that
already exists in the SVGDocument before it is loaded by the canvas... I use
exactly the same code to modify the SVGDocument before or after it is loaded
by the canvas. The only one difference is that it is modified in the Java
thread before loading and in update manager's thread after loading...
I will analyze my code once again and will post a test case if I do not
manage to find the problem by myself.
Another point needs to be brought into relief : I started noticing those
problems after changing the main structure of the SVG : at the beginning,
all modifications were performed inside a group located inside the defs
element. The content of that group was drawn by means of a use element :
...
<defs>
<g id="x">
...
</g>
</defs>
<use xlink:href="#X">
...
The content of the g group is now drawn directly (no more use element, not
located any longer inside defs...).

Best Regards.

Romain.


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---tp22987781p23041197.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