xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: JSVGCanvas resizing transform
Date Thu, 11 May 2006 00:08:59 GMT
Hi André,

André Ávila <asantos@nextech.com.br> wrote on 05/10/2006 10:16:52 AM:

> > André Ávila <asantos@nextech.com.br> wrote on 05/09/2006 05:34:41 PM:
> >
> > > Now, my problem is that, when the JSVGCanvas gets resized, the 
document
> > > is transformed to fit in the entire new area. This means that, if 
the
> > > canvas' size is reduced, the document is scaled down, and so on. 
This is the
> > > default Batik behavior.
> >
> >    Ok, now I understand the issue.  You need to use the 'viewing 
transform'
> > (JSVGComponent.getViewingTransform()) the problem is that I'm not sure 
you
> > can hold the data in 'screen space' like you more or less currently 
are.
> > You will have to transform the drawing in screen space to the viewBox
> > (aka the SVG element's user space) in order for the drawing to stay
> > consistent (likely the cause of the 'drift' you mention below).
> 
> Here's what I'm doing. Everytime a shape is created, the current canvas'
> viewing transform is stored for future reference (let's call it the
> 'original viewing transform'). When the canvas is resized, I try to 
create a
> new transform that maps from the original viewing transform to the new 
one,
> and apply that transform to the Java2D objects.

   What you need to do in concatenate the inverse of the old viewing 
transform
and the new viewing transform, something like:

        AffineTransform oldVT, newVT; // come from somewhere.
        AffineTransform ptTrans = new AffineTransfomr(newVT);
        ptTrans.concatenate(oldVT.createInverse());   // catch 
non-invertable exception...

      // transform your shapes by ptTrans.

> >    This sort of underscores for me anyway that your overlay data 
should
> > probably just be made part of the SVG document

> You are most likely right, but I have some requirements that are much 
easier
> to accomplish by keeping the Java2D objects in memory, specially because 
I
> deal with very large, complex documents, and will not be using the DOM 
in
> the future (I still have plans to use the JGVTComponent to render the
> documents, completely disposing of the DOM afterwards). After creating 
the
> shapes, the user should be able to manipulate them (move, resize, etc), 
and
> I don't think I could do that with an SVG without manipulating the DOM. 
Am I
> right?

   In theory you can manipulate the GVT tree just the way the Bridge does
in response to DOM mutation events.  However, the main problem is that for
historical reasons all of the update support for the Canvas lives in the
JSVGComponent - meaning that while there isn't any large technical hurdle 
to having a Dynamic JGVTComponent currently you can't have the GVT 
component
automatically repaint (just modified regions) like the JSVGComponent does.


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