Hi Thomas, Wow, just one line of code. It certainly works and fixes the problem, but I don't understand *why* it fixes the problem: - The C++ code's multiply function seems to be concatenation, not preconcatenation. - If I supplied source points to the derived transform, I got destination points. That tells me it works. Oddly enough, when I switch the line to do preconcatenation, it still works. I guess that wasn't a valid unit test. Yeah, I set the viewing transform to the identity transform to simplify possible matrix calculation errors. It didn't change anything, but in production code, I'd certainly apply the inverse of the viewing transform. Either way, it certainly works. I guess I had more confidence in my derived transform (and applicable code) than I should've. Thanks a bunch, this works great. Michael
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wed 10/15/2008 10:05 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/15/2008 11:16:54 AM: > I believe that the window -> viewBox code gives nearly the same > results. For some reason, the target document is always anchored at > the upper left of the document. It seems to be overriding or > ignoring translation. > I also posted it to > http://www.mindspring.com/~bishopmw/DemoCanvas.java The problem was in the calculation of the derived transform. You should use preConcatenate instead of concatenate in public static AffineTransform deriveTransform( Point2D[] srcPoints, Point2D[] destPoints); Replace: returnTransform.concatenate(destTransform); With: returnTransform.preConcatenate(destTransform); > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wed 10/15/2008 6:29 AM > To: 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/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'stransform > after using the zoom interactor. > > BTW your code never made it as an attachment. > [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]
