Sorry to keep posting, but I think I found the problem in my logging. For the SVGMatrix, I was outputting: A B C D E F where it should be: A C E B D F So the target's view box transform and the target screen CTM DO match. I just keep screwing up how matrices are represented. It was confusing because B and D are both zero so I thought the bottom row was just out of order. Visually, however, this is still off. The translation seems to be what's missing; again, the target document seems to ALWAYS be anchored to the upper left. I can use the ZOOM interactor on the source canvas (affecting the target canvas), then use the PAN interactor on the target canvas (not affecting the source) and get it close, if not exact given the granularity of the pan interactor keys. Michael
________________________________ From: Bishop, Michael W. CONTR J9C880 [mailto:[EMAIL PROTECTED] Sent: Tue 10/14/2008 3:40 PM To: batik-users@xmlgraphics.apache.org Subject: RE: Tracking changes to the rendering transform? I've done some more work with this. I've changed some of the code to simplify what's going on with these transforms: // Easier than applying the inverse, just set the viewing transform directly to the identity transform? targetCanvas.getCanvasGraphicsNode().setViewingTransform(new AffineTransform()); // Set the rendering transform to the magic transform. targetCanvas.setRenderingTransform(derivedTx); I *think* this is the same mathmatically. Similar results; it seems the first row is correct and the second row has numbers out of order. Visually, the result is better, the closer I have the zoom interactor to the top-left of the screen. If I drag a box near the top left of the source canvas, it's close. The further I get from the top-left, the more wrong it is. It seems translation doesn't get applied properly, the target canvas is always anchored to the upper-left of the document, regardless of the source canvas's view. The scaling is usually close. Michael ________________________________ From: Bishop, Michael W. CONTR J9C880 [mailto:[EMAIL PROTECTED] Sent: Tue 10/14/2008 10:32 AM To: batik-users@xmlgraphics.apache.org Subject: RE: Tracking changes to the rendering transform? Hi Thomas, Yes, my document has a width/height/viewBox of 640x480. I don't specify any sizes in my UI. When I add the canvases to the JFrame and call pack(), the canvases are both 200x200. I guess this is a default preferred size for the JSVGCanvas. setRenderingTransform() on the source canvas is not called by me. It's called automatically via the zoom and pan interactors. I did put the call to targetCanvas.setRenderingTransform() in the UpdateManager. Now I've switched my comparison code to compare the target's screenCTM with the target's viewbox transform. They're awfully close; two of the numbers are flip-flopped. The code is: protected void checkTarget() { final Node node = targetCanvas.getSVGDocument().getDocumentElement(); SVGMatrix matrix = ((SVGLocatable) node).getScreenCTM(); Object[] params = new Object[] { matrix.getA(), matrix.getB(), matrix.getC(), matrix.getD(), matrix.getE(), matrix.getF() }; logger.info("Target Screen CTM: " + MessageFormat.format( DemoCanvas.MATRIX_FORMAT, params)); logger.info("Target view box transform: " + targetCanvas.getViewBoxTransform()); } And this is the output: Target Screen CTM: [ 0.312 0 0 0.312 0 0.125 ] Target view box transform: AffineTransform[[0.3125, 0.0, 0.0], [0.0, 0.3125, 0.125]] For the SVGMatrix, I'm printing A, B, C, D, E, F and for the AffineTransform I'm just calling toString(). If I switch the numbers at D and E, the two matrices would be identical. I'm not sure what's happening there. I don't think I botched my logging code. Michael ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Mon 10/13/2008 6:47 AM To: batik-users@xmlgraphics.apache.org Cc: batik-users@xmlgraphics.apache.org Subject: RE: Tracking changes to the rendering transform? Hi Michael, "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on 10/09/2008 01:27:37 PM: > 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. Ok, the JSVGFrame (from squiggle) has a status bar that shows the cursor position in the viewBox coordinate system. I just tested and that matched your code exactly. > 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. Hmm, so your documents are 'landscape' (wider than tall). Are the areas they are displayed in Canvas's that are taller than wide (I think you said side by side at some point). If they are displayed in canvases that are taller than wide by default it will shrink the document to fit width wise and add padding at the top and bottom. It can be useful in cases like this to add a rectangle with a recognizable fill/stroke to know where the real document landed in the canvas. > 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. Actually you would check the canvas.getViewBoxTransform() against the SVGLocatible.getScreenCTM(). > 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: I'll try and take a look at this see if anything looks obviously wrong... > 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. If you are calling 'setRendering' transform on the canvas then then call should be made in the Swing thread. However since you are querying the SVG DOM that part should really be done in the UpdateManager thread. > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thu 10/9/2008 1:14 PM > To: batik-users@xmlgraphics.apache.org > Cc: batik-users@xmlgraphics.apache.org > 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... > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC] > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
