Hi André,
André Ávila <[EMAIL PROTECTED]> wrote on 05/10/2006 10:16:52 AM:
> > André Ávila <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
