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 Thu, 09 Oct 2008 17:27:37 GMT
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: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
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" <michael.bishop.ctr@jfcom.mil> 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... 

Mime
View raw message