A few questions

[Guillaume Pothier <gp...@free.fr>]

Hi!

I am using Batik for sometime now and appreciate it a lot (I am 
developping a SVG graphic editor). I have a a few questions:

* There is a problem in batik when a document contains an image whose 
size is 0x0: nothing gets rendered at all.
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22074)
Does anyone from the dev team plans to fix this one?

* While the GVT tree is not built, many DOM operations are not possible, 
particularly those that deal with lengths, as they try to find a unit 
manager through the GVT subsystem. Would it be possible to fix that?

* What is the design rationale for having three layers (DOM elements, 
GVT nodes, and bridges)? Well, I mean why the Bridge layer?

* Why is it necessary to use a bridge context to retrieve an element 
from a GVT node? I understand that an element can spawn various GVT node 
in the case of <define>/<use>, but I thought a GVT node could only refer 
to one element. (cf BridgeContext.getElement (GraphicsNode)


Thanks
Guillaume


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: A few questions

[Thomas DeWeese <Th...@Kodak.com>]

Guillaume Pothier wrote:
> Hi!
> 
> I am using Batik for sometime now and appreciate it a lot (I am 
> developping a SVG graphic editor). I have a a few questions:
> 
> * There is a problem in batik when a document contains an image whose 
> size is 0x0: nothing gets rendered at all.
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22074)
> Does anyone from the dev team plans to fix this one?

   I'll take a look at it (it's a little odd - no error message or
anything).

> * While the GVT tree is not built, many DOM operations are not possible, 
> particularly those that deal with lengths, as they try to find a unit 
> manager through the GVT subsystem. Would it be possible to fix that?

   No, the GVT tree is where all the geometry information is calculated.

> * What is the design rationale for having three layers (DOM elements, 
> GVT nodes, and bridges)? Well, I mean why the Bridge layer?

   The GVT layer is independent of the SVG DOM and the SVG DOM is
independent of the GVT tree.  All the cross package dependencies are
handled in the Bridge Package.

> * Why is it necessary to use a bridge context to retrieve an element 
> from a GVT node? I understand that an element can spawn various GVT node 
> in the case of <define>/<use>, but I thought a GVT node could only refer 
> to one element. (cf BridgeContext.getElement (GraphicsNode)

   As I say above the GVT layer is independent of the SVG layer
(it in fact has no dependency on XML).  You can, at least in
theory, create a GVT tree and totally dispose of the source XML
document.  Also the batik.dom package is independent of GVT
it simply defines interfaces that the Bridge implements.

   This makes it very clean from an architectural point of view,
however it does make it more complex to work with.  Also part of
the initial rational was that the GVT tree may be used outside the
context of SVG - as a generic 'retained store' graphics framework.

> 
> 
> Thanks
> Guillaume
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: A few questions

[Thomas DeWeese <Th...@Kodak.com>]

Thierry Kormann wrote:
>>* There is a problem in batik when a document contains an image whose 
>>size is 0x0: nothing gets rendered at all.
>>(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22074)
>>Does anyone from the dev team plans to fix this one?
> 
> 
> According to '5.7 The 'image' element', a value of zero for the attributes
> 'width' or 'height' disables the rendering of the <image> element. I guess
> this is why the bridge stays silent here.

Hi Thierry,

    Yes, this is why the bridge stays silent, the real problem was that it
generated a degenerate Affine matrix - which throws a monkey wrench in
the bounds calculation.  I have this fixed in my build and will deliver
this shortly.

    I should mention that if you are using the zero w/h thing
to control visibility you should really look into using visibility="hidden"
instead - this will be _much_ more efficent.



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

RE: A few questions

[Thierry Kormann <tk...@ilog.fr>]

> * There is a problem in batik when a document contains an image whose 
> size is 0x0: nothing gets rendered at all.
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22074)
> Does anyone from the dev team plans to fix this one?

According to '5.7 The 'image' element', a value of zero for the attributes
'width' or 'height' disables the rendering of the <image> element. I guess
this is why the bridge stays silent here.

Thierry.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org