Hi Thomas, Well, the Y coordinates look questionable. The document's viewBox is 0 0 640 480 and the width is 640 and the height is 480. If I use the default zoom interactor and zoom in, it reports some of the Y (document) coordinates as negative numbers. That would indicate that the window is showing an area that's partially off the document, but that's not the case. The zoom box I use with the interactor was totally inside the document. I'm not sure what you mean by the status bar. My JSVGCanvas is just a JSVGCanvas...no status bar. I create a JFrame and add two JSVGCanvases to it. I also use the same code to map mouse coordinates to local coordinates for my whiteboard, so I'm pretty confident it works. When I override setRenderingTransform, I call super.setRenderingTransform first before deriving the window and document coordinates. I'm assuming that the completed call to setRenderingTransform is all I have to wait for. So you're saying after I set the rendering transform on the target canvas, I should check its rendering transform against its screenCTM (derived from the coordinate system of its document root)? I'll try that. I've got everything crunched down to a single class that I'll attach for the sake of having all the relevant code available. It loads an "example.svg" from the classpath root which can be any SVG. The potential points of failure are: deriveTransform getWindowPoints getDocumentPoints setRenderingTransform Now I'm going to try checking the screenCTM and see what happens. Another question just came to mind. I'm not manipulating the DOM, but should these transform changes be made on the UpdateManager? That might explain why the window doesn't update sometimes. Michael
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thu 10/9/2008 1:14 PM To: [email protected] Cc: [email protected] Subject: RE: Tracking changes to the rendering transform? Hi Michael, "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on 10/09/2008 11:17:56 AM: > The code never crashes, it just doesn't look right. I log the > coordinates and sometimes they look questionable. What coordinates look questionable? The 'derivedUpperLeft' Point below? Any idea how it's off? Is it a simple translate or scale? > Maybe I'm mapping window points to document coordinates wrong? > > final Node node = this.getSVGDocument().getDocumentElement(); > SVGMatrix matrix = ((SVGLocatable) node).getScreenCTM(); > matrix = matrix.inverse(); > final SVGOMPoint upperLeft = new SVGOMPoint(0, 0); // Window coordinate. > SVGPoint derivedUpperLeft = upperLeft.matrixTransform(matrix); // Document > coordinate. In general does derivedUpperLeft match what the canvas displays in the status bar (at the bottom of the window)? The above is the same code I often use to map mouse events to local coordinates (same problem). > OK, so I confirmed the window coordinates and looked at how to > properly apply the transform. Everything looks right in code, but > the results on the screen are unpredictable. One of three things > seem to happen: It's possible that I had something wrong in my code to calculate the modified rendering transform. You might have 'check' code that checks if getScreenCTM matches the 'desired' transform after you have set the rendering transform...
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
