Let me expand on Zainab's question, since we both feel like it reveals a deficiency in Batik's GVT library, and we'd like to know if we're missing something before we attempt to modify Batik's internals. (For the record, she and I are working together.)
From what we can tell, GVT is responsible for digesting the raw XML of an SVG file and representing it in a natural tree-based way using core Java data structures. That's perfect for our needs -- we want that first class representation in order to analyze and render the geometry in the file. The problem is that GVT doesn't maintain any information about symbols and embedded uses of them. It appears that when GVT encounters a <use> node, it locates the <symbol> that the <use> references, and makes a fresh deep copy of the symbol's contents at the current point in the GVT. The indirection provided by <use> is obliterated, and there's no way to recover it from within GVT. There are obvious reasons why this is bad. If you have an SVG file with a large, complex symbol that's used many times, you pay a heavy price in memory usage to deep-copy that symbol each time. It seems as if all the <use> nodes could share references to the same underlying symbol in the GVT, but this isn't done. For our purposes, there's a more specific problem. We really do need to keep track of which symbol each individual piece of geometry came from. That is, if we've got a file made up of circles, squares and stars, we'd like to know which of the three each path is an instance of. Deducing that from the geometry itself is complicated, and annoying if the original DOM contained that information explicitly. It seems as if the correct remedy is to introduce Symbol and Use nodes to the GVT library, but other suggestions are welcome. Thanks. > My question may be better stated "Whether there is a way to transfer tag > information like <use> and <symbol> from the DOM into a GVT tree?" > > Zainab > > On Sun, Sep 25, 2011 at 7:15 PM, Zainab AlMeraj <[email protected]> wrote: > Thanks Martin for your idea. > I don't think that's enough in my case. > > What if the symbols were made up of multiple objects? > I want to be able to recognize later on after processing the GVT whether the > element was called through a <use> so as to keep the geometric representation > of the objects rather than just the raw data I would get reading the DOM. > I would also use this information to re-write a manipulated result containing > the elements to a .svg similar to the input .svg. > > I hope this helps, > Zainab > > > On Sun, Sep 25, 2011 at 10:39 AM, Martin J <[email protected]> wrote: > Hi Zainab, > > I'm guessing that you want to do what I needed to do: find the > bounding box of each symbol as rendered. My code traversed the DOM, > and when it found an element that was a <use>, it stored the bounding > box, as follows: > > Element el; > // ... > String elementTag = el.getNodeName(); > SVGRect bb = null; > if (elementTag.equals("use")) > { > bb = ((SVGOMUseElement) el).getBBox(); > // ... > } > > Does this help? > > Martin > > On 25 September 2011 16:33, Zainab AlMeraj <[email protected]> wrote: > > Hi, > > > > I am a newbie to Batik. I came to it with an task in mind and thought it > > would solve my problems. But it turns out it might be more complicated to do > > than I expect. > > > > I want to read in a .svg that extensively uses <symbol> and <use> tags. > > This information is fairly accessible from the DOM but I loose all the > > geometry > > that exists. > > Using GVT on the other hand gives me all the geometry but without the > > original > > tag information. > > > > So it goes one step too far for what I am in need off. > > > > > > My pitch is to ask whether anyone has worked on this before, or suggested > > that > > it be implemented but wasn't. > > In the archives I have not come across any as of yet (still looking through > > them). > > > > If there is no way to grab this info I may be willing to code it and submit > > my > > stuff. > > > > Any guidance or help is appreciated. > > > > Also forgive me for being too explicit or not explicit enough. > > > > Thanks, > > > > Zainab > > > > > > -- > >From my MacBook Pro > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- Craig S. Kaplan University of Waterloo http://www.cgl.uwaterloo.ca/~csk/ "If civilization is to survive, it must live on the interest, not the capital, of nature." -- Ronald Wright --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
