Hi Thomas, > 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. 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() - currentTransform.getTranslateX(); double ty = originalTransform.getTranslateX() - currentTransform.getTranslateX(); AffineTransform mappingTransform = AffineTransform.getTranslateInstance(tx, ty); 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 right? Again, many thanks for your help, André --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
