xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Ávila <asan...@nextech.com.br>
Subject Re: JSVGCanvas resizing transform
Date Wed, 10 May 2006 14:16:52 GMT
Hi Thomas,

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

This works fine for translation. Some of the documents I display are
vertically oriented, so there's no rescaling when the canvas is resized, and
applying a translation solves the problem. Basically this comes down to:

double tx = originalTransform.getTranslateX() -
double ty = originalTransform.getTranslateX() -

AffineTransform mappingTransform = AffineTransform.getTranslateInstance(tx,

Shape s = mappingTransform.createTransformedShape(originalShape);

However, most documents are horizontally oriented, and get rescaled.
Probably because of my lack of intimacy with the AffineTransform, I was not
able to find the correct scale mapping. I tried the same approach above but
could not obtain the correct scaling factor. I've tried applying some
corrections, but I still get a small displacement no matter what.

I know I crossed the Batik line here, but I was hoping you could maybe tell
me what's wrong with this approach.

>    This sort of underscores for me anyway that your overlay data should
> probably just be made part of the SVG document (at least once the
> interactive
> drawing part is done) that way you wouldn't have to worry about _any_ of
> this
> nonsense.

You are most likely right, but I have some requirements that are much easier
to accomplish by keeping the Java2D objects in memory, specially beacuse 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

Again, many thanks for your help,


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

View raw message