xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bishop, Michael W. CONTR J9C880" <michael.bishop....@jfcom.mil>
Subject RE: Tracking changes to the rendering transform?
Date Tue, 21 Oct 2008 19:10:24 GMT
Hi Thomas,
Well, everything works mostly great.  I even worked out code to correct for aspect ratio and
was in the process of testing that.  So far, so good.
The problem?  Using the rotate interactor.  Rotating with aspect ratio correction causes problems.
 Do you have a resource or an outline on how to tackle this problem?  I'm imagining a solution
like this:
Receive 3 points (source) from a remote source.
Supply 3 points (target) from the local canvas.
Derive the transform.
Remove and store the rotation angle.
Correct the source points for aspect ratio.
Derive the transform.
Reapply the rotation angle.
Is this anywhere near correct?  Or should aspect ratio code somehow account for this rotation


From: Bishop, Michael W. CONTR J9C880 [mailto:michael.bishop.ctr@jfcom.mil]
Sent: Thu 10/16/2008 1:13 PM
To: batik-users@xmlgraphics.apache.org
Subject: RE: Tracking changes to the rendering transform?

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.


From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
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" <michael.bishop.ctr@jfcom.mil> 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); 



> From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> 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" <michael.bishop.ctr@jfcom.mil> 
> 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: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message