As I pointed out in an earlier post on this thread, I was able to get
the geometry information I required from the SVG DOM, so I had no use
for GVT. However, your complaint that <symbol>s must get deep-copied
is mis-placed: since the <use> can modify the geometry, and can be
nested inside <g> and <svg> elements, each of which can also transform
the geometry in some way, the GVT does the *time-efficient* thing,
even at the cost of some extra space. My understanding of GVT is that
it is a tree representation of the basic (Java 2D) drawing primitives
needed to render the image, that is, a transformation, not simply
another representation of the SVG.
My experience of Batik is that there has never been any need to use
GVT, so I suggest you ask yourself whether you *really* need to use it
yourselves.
Martin
On 2 October 2011 01:12, Craig S. Kaplan <c...@uwaterloo.ca> wrote:
> 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 <z.alme...@gmail.com> 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 <jacobson.mar...@gmail.com> 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 <z.alme...@gmail.com> 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: batik-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
>>
>>
>>
>
>
> --
> 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: batik-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
>
>
--
>From my MacBook Pro
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
