Hi Michael, "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on 10/14/2008 03:40:05 PM:
> 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. So does your window -> viewBox mapping code give the same results on the destination canvas as it did on the source canvas after you have set the renderingTransform? My guess is not which means that the rendering transform wasn't properly calculated some how. BTW given that your canvas is 200x200 and the document is 640x480 it is expected that window 0,0 could map to a negative Y value (480*200/640 give a scaled height of only 150 for the document which means that there will be 25 pixels on the top and bottom which are 'outside' of the document viewBox). > 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]] These transforms look a lot like the default scaling transform 200/640 = .3125 So I'm surprised that they are your source canvas's transform after using the zoom interactor. BTW your code never made it as an attachment. > 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] > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC] > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
