Using JSVGCompnent with SVGGraphics2D

[Thomas E Deweese <th...@kodak.com>]

Hi all,

   This is a development focused look at the Batik-users question on
problems with SVGGraphics2D.  Basically he wants to 

   In trying to figure out how he can do what he wants I ran up
against 2 problems:

   1) We don't give direct access to the root GraphicsNode from the
      JGVTComponent (base class for JSVGComponent).  Currently we have
      set methods but no get.

   2) The Paint method on GraphicsNode takes the
      "GraphicsNodeRenderContext".  This isn't a trivial object to
      construct, and has important implications to the rendering, so I
      don't feel comfortable forcing people that just want a rendering
      to figure out how to construct a good one.
   
To solve these issues I have proposed changes:

   1) Add a getGraphicsNode to JGVTComponent.  This is just on the
      basic grounds that if you have a set you should have a get.

   2) Add a getRenderer call to JGVTComponent.

   3) Add a GraphicsRenderer interface with a 'draw(Graphics2D )'
      method that is defined to actually draw the SVG tree into the
      given Graphics2D.

   Note that given #2 & #3 you don't really need #1 (but I still think
it should have been there from the start).

   These changes still have the issue that people who subclass
JGVTComponent to add additional graphics to the normal output of the
paint method of JGVTComponent, or folks that want an SVG 'snapshot' of
a window in there application can't easily get it.

   Another alternative (or addition) would be to add a 'direct draw'
parameter to JGVTComponent, which would cause it to bypass the image
caching stuff in it's paint method (perhaps even being nice enough to
turn off double buffering in the swing component).

   A final option, provide a 'directPaint' or 'draw' method which
bypasses the image caching.

   As Bill points out in another message, both of these last options
may also be very useful for implementing printing.

   Opinions, better ideas?

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

Re: Using JSVGCompnent with SVGGraphics2D

[Vincent Hardy <vh...@eng.sun.com>]

Thomas E Deweese wrote:
> 
> ...
> 
>    As Bill points out in another message, both of these last options
> may also be very useful for implementing printing.
> 

Not a conflict in any way, but note that printing is done by building
a GVT tree and calling the paint method with the Graphics2D directly
on the root not. This does not go through the component.

V.

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

Re: Using JSVGCompnent with SVGGraphics2D

[Thomas E Deweese <th...@kodak.com>]

>>>>> "TK" == Thierry Kormann <tk...@sophia.inria.fr> writes:

>> To solve these issues I have proposed changes:
>> 
>> 1) Add a getGraphicsNode to JGVTComponent.  This is just on the
>> basic grounds that if you have a set you should have a get.

TK> That's fine to me. BTW, we have recently added a getSVGDocument on
TK> the JSVGComponent :)

    Stephane already did this, thanks!

>> 2) Add a getRenderer call to JGVTComponent.

TK> I don't see the benefit of this one (see bellow) but if it is
TK> needed, it is fime with me.

    It just saves the user from having to construct there own Renderer
and possibly getting different results (not a big deal, and there are
good arguments either way on this one).

>> 3) Add a GraphicsRenderer interface with a 'draw(Graphics2D )'
>> method that is defined to actually draw the SVG tree into the given
>> Graphics2D.

TK> To me, it's the renderer that should provide a convenient way to
TK> draw a GVT tree (without caching...) May be a new Renderer?. 

    Ok, I'll add a new renderer (or at least an interface that
StaticRenderer may implement).

TK> I think people want to draw a GVT tree (and not necessarly use the
TK> JGVTComponent or any of our swing component).

    Unfortunately this isn't the case (at least not always).  In the
particular case of Peter he has many JSVGComponents scattered around
inside his Component (fancy icons or something?).  So it would require
him to reimplement all the paint code in java.awt.Component to handle
drawing his JSVGComponents with something other than 'paint' (doable
but ugly).

TK> My preference is to include the Renderer API as an alternative of
TK> a high-level feature of Batik.

TK> So, what about adding a direct draw method on the renderer? 

    This is fine, but it doesn't address JSVGComponents used as part
of a larger Component that people want to persist using SVG.

    I tend to agree that this is a bit ugly, but I think it will be a
reasonably common use of the JSVGComponent.  There are two ways I
can see to approach this:

1) If double buffer is off for the component then call the new
   directDraw method on the renderer.

2) In paint check the type of the Graphics2D if it's a Printer
   Graphics2D (Check associated GraphicsDevice) or an SVGGraphics2D
   then call the directDraw method on the renderer.

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

Re: Using JSVGCompnent with SVGGraphics2D

[Thierry Kormann <tk...@sophia.inria.fr>]

> To solve these issues I have proposed changes:
>
>    1) Add a getGraphicsNode to JGVTComponent.  This is just on the
>       basic grounds that if you have a set you should have a get.

That's fine to me. BTW, we have recently added a getSVGDocument on the 
JSVGComponent :)


>    2) Add a getRenderer call to JGVTComponent.

I don't see the benefit of this one (see bellow) but if it is needed, it is 
fime with me.

>    3) Add a GraphicsRenderer interface with a 'draw(Graphics2D )'
>       method that is defined to actually draw the SVG tree into the
>       given Graphics2D.

To me, it's the renderer that should provide a convenient way to draw a GVT 
tree (without caching...) May be a new Renderer?. I think people want to draw 
a GVT tree (and not necessarly use the JGVTComponent or any of our swing 
component).

My preference is to include the Renderer API as an alternative of a 
high-level feature of Batik. 

So, what about adding a direct draw method on the renderer? People that want 
to apply zoom or pan, could use the setTransform method of the Renderer (the 
one actually called by the JGVTComponent at this time).


Any comments?

Thierry.


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