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: Rendering transform on refresh?
Date Thu, 20 Nov 2008 16:08:49 GMT
Hi Thomas,
 
Is there a way to leverage the JSVGCanvas to do the work regarding the viewBox?  It sounds
like I'm replicating work to discover the viewport because the JSVGCanvas has already done
it.  I just want the document corners in the window's coordinate system.
 
> So you basically adjust the window's corner points so they at 
> don't extend beyond the corners/edges of the document.
 
Mostly, yes.  I do take translation into account.  If the document is panned, so there's 2
units of space between the left edge of the document and the left edge of the window and 4
units of space between the right edge of the document and the right edge of the window, I
will only adjust the horizontal dimension by 2 units.  If the document is panned partially
off the edge of the window, no adjustment in that dimension will occur.  I guess it could
be called "uniform clipping" to ensure that what is shown in the center of the window does
not change.  Left/right adjustments are the same, as are top/bottom.
 
> ...Also you need to be careful if you allow for non-uniform scaling.
 
I don't.  You're right, that would be too complicated and couldn't be determined.
 
> ...What you want to do is form a new line that has a 
> new length but is centered on the old line.
 
This makes sense.  I didn't think about it that way; I was preoccupied with the line's slope
and adjusting.  So the new length would be the old length plus two times the insets determined
for aspect ratio.  This saves the trouble of unrotating, adjusting for aspect ratio, and rerotating.
 I'm going to try and work this in; it's definitely simpler.
 
Thanks,
 
Michael

________________________________

From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
Sent: Thu 11/20/2008 5:45 AM
To: batik-users@xmlgraphics.apache.org
Cc: batik-users@xmlgraphics.apache.org
Subject: RE: Rendering transform on refresh?



Hi Micahel,

"Bishop, Michael W. CONTR J9C880" <michael.bishop.ctr@jfcom.mil> wrote on 11/18/2008
03:07:44 PM:

> Well, I never found an elegant way to do this, but I ended up 
> settling for the following:
>  
> - Use the viewBox attribute of the root svg element if one is present.
> - If not, use the width and height attribute of the root svg element.
> - If not, I can't do it.
>  
> I seem to recall JSVGCanvas requiring either a viewBox or a 
> width/height to properly display an SVG document, so I think this is
> reasonable.  I'm just sure there's a way to ask the JSVGCanvas what 
> it's showing, as opposed to going to the SVGDocument myself.

   In SVG (not just Batik) if the document has no viewBox or Width 
and Height the initial viewport is established at the size of the 
'containing element' (in our case the window) what ever that may be. 
For the Rasterizer we always use 400x400.   

> I've also solved the problem of keeping two JSVGCanvases in sync, 
> regarding their rendering transforms. 

> - "Source" compares the corners of its window to the corners of the 
> document (in window coordinates) it's displaying.  The necessary 
> adjustments are made to the window coordinates to remove 
> "insignificant" [1] space.

   So you basically adjust the window's corner points so they at 
don't extend beyond the corners/edges of the document. 

> - "Target" receives those coordinates and determines the rotation 
> angle.  "Target" temporarily negates the rotation angle of the 
> received coordinates[2].
> - "Target" adjusts the aspect ratio of the received coordinates to 
> match its window's aspect ratio.
> - "Target" reapplies the rotation angle to the received coordinates.

> [2] - Given the upper-left, upper-right, and lower-left corners of a
> parallelogram is it possible to correctly adjust width and height 
> based on aspect ratio? 

   Yes, you can adjust the three points without removing the rotation. 

   Also you need to be careful if you allow for non-uniform scaling (which 
can happen in the root element of the document if it has 
'perserveAspectRatio="none"').  You can't determine the source canvas's 
aspect ratio. 

>  If so, the rotation may be unnecessary.  
> Take the line formed by upper-left and upper-right.  We can find the
> length of the line.  We can find the slope of the line.  What I 
> don't know how to do is "lengthen" the line by X units along the 
> slope (X determined by aspect ratio).

   It's a little tricky, but if you only pay attention to the horizontal 
line for a minute.  What you want to do is form a new line that has a 
new length but is centered on the old line.  So given: 
         float x0, y0, x1, y1, x2, y2;  // src canvas pts. 
    float newLen; 

        float midX = (x0+x1)/2;  // midpoints 
        float midY = (y0+y1)/2; 
    
    float dx = x1-x0; 
    float dy = y1-y0; 
    float oldLen = sqrt(dx*dx + dy*dy); 

    if (oldLen == 0) throw new DegeneratePoints(); 

    dx = dx*newLen/oldLen;  // Scale dx,dy to new length. 
    dy = dy*newLen/oldLen; 
    
    float newX0 = midX - dx/2;  // calculate new end pts of line 
    float newY0 = midY - dy/2; 

    float newX1 = midX + dx/2; 
    float newY1 = midY + dy/2; 

    float newX2 = x2 + (newX0 - x0); // offset pt2 the same as pt 0 
    float newY2 = y2 + (newY0 - y0); 

> OK, not so much a nutshell, but this took awhile to solve.  If this 
> is of any use to anyone, I can go into more detail and possibly 
> provide examples.  My DemoCanvas class is out of control!
>  
> Michael Bishop
> 
> ________________________________
> 
> From: Bishop, Michael W. CONTR J9C880 [mailto:michael.bishop.ctr@jfcom.mil]
> Sent: Thu 11/13/2008 1:10 PM
> To: batik-users@xmlgraphics.apache.org
> Subject: RE: Rendering transform on refresh?
> 
> 
> Yeah, I'm still working on this problem.  Amazingly enough, I think 
> I have it working for the most part.  I'm trying to solve a 
> different problem, but it's for the same purpose.
>  
> Document Space:  Coordinates I define as the coordinates dictated by
> the SVG document.
> Window Space:  Coordinates I define as the coordinates dictated by 
> the JSVGCanvas.
>  
> What I'm trying to do is find the corners of the document in window 
> space.  I'm getting results that make sense, but they're not the 
> results I want.
>  
> SVGLocatable locatable = (SVGLocatable) svgDocument.getDocumentElement();
> SVGRect boundingBox = locatable.getBox();
> // Now I derive SVGPoints based on x, y, w, h of the boundingBox.
>  
> SVGMatrix matrix = locatable.getScreenCTM();
> // I should be able to push those SVGPoints through this matrix to 
> get their window coordinates.
>  
> The problem is, I don't believe the viewBox is being taken into 
> effect which makes sense because I'm not using it.  The size of the 
> "background" rectangle is messing everything up and the size of the 
> window versus the size of the document is not being taken into effect.
> Here's a snippet SVG:
>  
> <svg contentScriptType="text/ecmascript" zoomAndPan="magnify" xmlns:xlink="
> http://www.w3.org/1999/xlink <http://www.w3.org/1999/xlink> " 
> contentStyleType="text/css" version="1.0" width="640" fill="none" 
> preserveAspectRatio="xMidYMid meet" viewBox="0 0 640 480" height="480" xmlns="
> http://www.w3.org/2000/svg <http://www.w3.org/2000/svg> "><rect 
> <http://><rect/>  x="-1000%" y="-1000%" fill="white" width="3000%" 
> height="3000%"/></svg>
>  
> INFO: Upper Left: -6400.0, -4800.0
> INFO: Upper Right: 12800.0, -4800.0
> INFO: Lower Right: 12800.0, 9600.0
> INFO: Lower Left: -6400.0, 9600.0
>  
> Pushing those through the screenCTM matrix doesn't give me the 
> proper window coordinates where I "see" the document on the canvas. 
> I want the coordinates of the document in window space.  What am I 
> missing?  I believe I can't go straight through the screenCTM; I 
> have to incorporate the rendering or viewbox transform, but I'm not 
> sure how to proceed.
>  
> Michael Bishop
> 
> 
> ________________________________
> 
> From: Bishop, Michael W. CONTR J9C880 [mailto:michael.bishop.ctr@jfcom.mil]
> Sent: Thu 10/30/2008 2:16 PM
> To: batik-users@xmlgraphics.apache.org
> Subject: RE: Rendering transform on refresh?
> 
> 
> OK, I think I have the aspect ratio thing fixed, but it stll breaks 
> on rotation.  Here's the changed code.
> src[0] is upper-left, src[1] is upper-right, and src[2] is lower-left.
>  
>         final double srcWidth = src[0].distance(src[1]);
>         final double srcHeight = src[0].distance(src[2]);
>         final double destWidth = dest[0].distance(dest[1]);
>         final double destHeight = dest[0].distance(dest[2]);
>         final double srcRatio = srcWidth / srcHeight;
>         final double destRatio = destWidth / destHeight;
>         
>         double hInset = 0;
>         double vInset = 0;
>         
>         // Destination window is wider.
>         if (destRatio > srcRatio) {
>             double scaledSrcWidth = destRatio * srcHeight;
>             hInset = (scaledSrcWidth - srcWidth) / 2.0d;
>             
>         }
>         
>         // Destination window is smaller.
>         else if (srcRatio > destRatio) {
>             double scaledSrcHeight = srcWidth / destRatio;
>             vInset = (scaledSrcHeight - srcHeight) / 2.0d;
>         }
>         
>         src[0].setLocation(src[0].getX() - hInset, src[0].getY() - vInset);
>         src[1].setLocation(src[1].getX() + hInset, src[1].getY() - vInset);
>         src[2].setLocation(src[2].getX() - hInset, src[2].getY() + vInset);
>  
> Based on what you told me, this should work with rotation, but I'm 
> not sure why.  Are we talking about the same rotation?  I'm using 
> the interactor with JSVGCanvas to rotate the rendering transform.  
> I'm not applying a rotation to the actual document.  Does that 
> matter?  Adjusting the points by the derived insets shouldn't work 
> when the source points are rotated...should they?  Once you pull the
> source coordinates into document space, you're not adjusting on the 
> X/Y axis anymore, you're adjusting at some arbitrary angle.
>  
> Michael
> 
> ________________________________
> 
> From: Bishop, Michael W. CONTR J9C880 [mailto:michael.bishop.ctr@jfcom.mil]
> Sent: Thu 10/30/2008 1:31 PM
> To: batik-users@xmlgraphics.apache.org
> Subject: RE: Rendering transform on refresh?
> 
> 
> Hi Thomas,
>  
> Yeah, the more I think about it, the more I think you're right.  I 
> know that rotation worked before I started correcting for aspect 
> ratio, but it should work with aspect ratio correction.  Well, now 
> I've put a lot of effort into getting the rotation angle sorted out 
> and I didn't even need it it appears.
>  
> "srcWidth/Height is always the src canvas Width and Height which 
> doesn't depend on rotation."
>  
> Assuming that the destination canvas is across the network, I don't 
> have access to the source canvas.  All I get on the destination side
> of things is the three points.  I think this would work though:
>  
> double srcWidth = point00.distance(point10);
> double srcHeight = point00.distance(point01);
>  
> Of course, these source points are in document/user space, not 
> window/ui space.  Does that matter?  The aspect ratio would be the same.
>  
> "First there is no garuntee that the 'extra' area in B are blank..."
>  
> I left out the idea that Canvas A starts by showing the entire 
> document in its window.  Without any changes, Canvas B would 
> letterbox, then Canvas A would pillarbox, basically showing the 
> entire document in less and less space as time went on.  But you're 
> right, I need to think about zooming/panning because I don't want to
> lose areas of interest.
>  
> "So there is an opportunity to restrict the document points the the 
> 'bounding box' of the document (this is a bit tricky for rotation). 
> But you need to understand that this is a special case condition and
> the 'reletter boxing' problem will be an issue unless you want to 
> accept the possability that sometimes one window won't see what 
> another adjusted the view to see (which will be a problem to a 
> certain extent anyway since without moving the window the reciever 
> will often be able to see content that the sender can't)."
> 
>  
> The "ultimate" goal is to have the center of A match the center of 
> B.  I don't want to lose significant information, but I don't want 
> to gain insignificant information.  In the example, A's 
> communication to B is correct.  If B communicates back to A, I don't
> want the letterboxing there.
>  
> In short, if A sends to B with no change, B adjusts.  If B sends 
> back to A with no change, no adjustment should be needed on A.
>  
> What I *think* I'm saying is that if the entire document is 
> contained in the canvas on all sides, then I want to send the 
> document corners in document space, not the window corners in 
> document space.  I have no idea how this will work with rotation involved.
>  
> Also, do you see a bug in your AR code?  Something's not coming out 
> right on the UI, but I can't see what's wrong.  Still looking into 
> that, getting it working without worrying about rotation, etc.
>  
> Michael
> 
> ________________________________
> 
> From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> Sent: Thu 10/30/2008 12:53 PM
> To: batik-users@xmlgraphics.apache.org
> Cc: batik-users@xmlgraphics.apache.org
> Subject: RE: Rendering transform on refresh?
> 
> 
> 
> Hi Michael,
> 
> "Bishop, Michael W. CONTR J9C880" <michael.bishop.ctr@jfcom.mil> 
> wrote on 10/30/2008 11:16:01 AM:
> 
> > Your aspect ratio correction is about the same as what I have so 
> > far, although yours is more elegant.  There are further issues that 
> > this kind of algorithm doesn't cover:
> 
>    No, I think it covers all of the cases.  The src canvas mapped 
> it's corner points to the document space (which might include 
> rotation etc).  What we are doing is picking the tree points in 
> the dst canvas that we want mapped to those three points from the 
> src canvas. 
> 
>    You normally map the three src points to the corners of the 
> dst canvas, but what I did was map the three src points to points 
> centered in the dst canvas with the same aspect ratio as the src 
> canvas. 
> 
> 
> > Rotation.  When the parallelogram isn't at 0 degrees, width, height,
> > horizontal, and vertical are harder to calculate and adjust.  This 
> > is what I did:
> 
>    srcWidth/Height is always the src canvas Width and Height which 
> doesn't depend on rotation. 
> 
> > - Find the center point of the parallelogram.
> [...]  
> > Amazingly (you'd hate to see my math), this works.
> 
>    This sounds very complicated, and I don't think it's needed... 
> 
> > The second problem is harder to solve.  Imagine a case where canvas 
> > A is "wide" (400x200) and canvas B is square (200x200).
> 
>    Right I under stand this case and it's what I wrote for. 
> 
> > - Canvas A communicates its points to Canvas B.
> > - Canvas B essentially "letterboxes" Canvas A's coordinates into its
> > window.  Like a widescreen movie, Canvas B has blank non-document 
> > area on the top and bottom with the "widescreen" data in the middle.
> > - Canvas B now makes an adjustment and communicates its points to Canvas A.
> >  
> > This is where the problem occurs.  The window points of Canvas B 
> > INCLUDE that non-document blank area.  Now I'm sending both the 
> > document AND the padded area around it back to Canvas A.
> 
>    First there is no garuntee that the 'extra' area in B are blank 
> they may well contain document content (if the document was zoomed in 
> for example). So the adjustment to B may have been to put an object of 
> interest right at the top of it's viewable area.  If A doesn't reletter 
> box the content it won't be able to see that important element. 
> 
> > In short, (I think) if a canvas window is BOTH wider AND taller than
> > the document its trying to show, the points have to be adjusted to 
> > remove what I consider insignificant space.
> 
>    So there is an opportunity to restrict the document points the 
> the 'bounding box' of the document (this is a bit tricky for rotation). 
> But you need to understand that this is a special case condition 
> and the 'reletter boxing' problem will be an issue unless you want 
> to accept the possability that sometimes one window won't see what 
> another adjusted the view to see (which will be a problem to a 
> certain extent anyway since without moving the window the reciever 
> will often be able to see content that the sender can't). 
> 
> > From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> > Sent: Thu 10/30/2008 8:25 AM
> > To: batik-users@xmlgraphics.apache.org
> > Cc: batik-users@xmlgraphics.apache.org
> > Subject: RE: Rendering transform on refresh?
> > 
> > 
> > 
> > Hi Micahel,
> > 
> > "Bishop, Michael W. CONTR J9C880" <michael.bishop.ctr@jfcom.mil> 
> > wrote on 10/29/2008 03:12:17 PM:
> > 
> > > In short, my event comes before that happens and I don't know why.  
> > > Of course, eliminating calls to setDocument and replacing them to 
> > > setRenderingTransform(identity) might fix the problem entirely.
> > 
> >    BTW this is effectively what resetRenderingTransform does. 
> > It sets the renderingTransform to 'initalTransform' which is 
> > currently always the identity transform. 
> > 
> > > Long shot, but do you (or anyone) have resources or links for 
> > > correcting aspect ratios?  I've got a miscalculation somewhere.  I 
> > > want to take the parallelogram in document/user space (represented 
> > > by three points; upper-left, upper-right, and lower-left) and 
> > > calculate how to properly fit them into the target window, 
> > 
> >    To do this properly you need to know what aspect ratio in the 
> > source canvas the three points represent.  This can be a single 
> > float or two 'rational' integers (width and height). 
> > 
> > float srcAR = srcWidth/srcHeight; 
> > float dstAR = dstWidth/dstHeight; 
> > 
> > int hInset = 0, vInset = 0; 
> > if (dstAR > srcAR)  // new window is 'wider' than old 
> > {                   // so calculate how big the bars on either side 
> > should be. 
> >    int scaledSrcW = srcAR*dstHeight. 
> >    hInset = (dstWidth-scaledSrcW)/2 
> > } 
> > else  // new window is taller than old so calculate 
> > {     // the size of the bars on top and bottom. 
> >    int scaleSrcH  = dstWidth/srcAR; 
> >    vInset = (dstHeight-scaledSrcH); 
> > } 
> > 
> > Point2D p00 = new Point(hInset, vInset); 
> > Point2D p10 = new Point(dstWidth-hInset, vInset); 
> > Point2D P01 = new Point(hInset, dstHeight-vInset); 
> > 
> > 
> > > regardless of size and aspect-ratio.  This is kind of outside the 
> > > realm of Batik, but I can't even find any resources that remotely 
> > > cover this topic.  Once I fix the bug with "refresh" (more like 
> > > reset as you've pointed out), I'm going to be tackling fixing that.
> > >  
> > > Michael
> > > 
> > > ________________________________
> > > 
> > > From: Dan Slater [mailto:dslater@simulsoft.com]
> > > Sent: Wed 10/29/2008 11:24 AM
> > > To: batik-users@xmlgraphics.apache.org
> > > Subject: RE: Rendering transform on refresh?
> > > 
> > > 
> > > Hi, Michael,
> > > 
> > > I don't think setting the rendering transform refreshes the 
> > > document, it only changes the screen position.
> > > 
> > > Assuming you knew your points in screen space, couldn't you use 
> > > getScreenCTM() to translate to common 'document' coords?  (I think 
> > > your document coords are what I call user coords,  after all SVG 
> > > attribute transforms leading to the root are applied to the local 
> > > element's x,y)?   You and Thomas might have covered this in your 
> > > recent exchanges, I didn't completely follow it.
> > > 
> > > If I understand you correcly, I would register GVT event listeners 
> > > and check for transforms at various steps (maybe you've done this). 
> > > It sounds like you need to communicate a transform after some 
> > > rendering step is completed.  You can use the method I mentioned to 
> > > set/get transforms after any point.
> > > 
> > > For example, I use a GVT listener to set the viewbox to always be 
> > > 10% larger in each dimension than the doc's bounding box, available 
> > > via a GVTTreeBuilderListener, GVTBuildStarted.
> > > 
> > > Hopefully I'm not leading you astray...
> > > 
> > > Dan
> > > 
> > > PS On my next refactor I'm probably going to overload setDocument to
> > > include a transform parameter, eliminating the need for a separate 
> > > call to setLastRender.
> > > 
> > > Also, more errata below: I don't override the listener, I register it. 
> > > 
> > > 
> > > 
> > >    -------- Original Message --------
> > >    Subject: RE: Rendering transform on refresh?
> > >    From: "Bishop, Michael W. CONTR J9C880" <michael.bishop.ctr@jfcom.mil>
> > >    Date: Wed, October 29, 2008 8:21 am
> > >    To: <batik-users@xmlgraphics.apache.org>
> > >    
> > >    Hi Dan,
> > >    
> > >    I think you indirectly answered my question and also gave me an 
> > > idea to keep in mind. I never thought about preserving the "last" 
> > > render/transform. What I want to do with setDocument() is have it 
> > > communicate the "default" transform.
> > >    
> > >    For some reason, if I call setDocument(), then fire my event, I'm
> > > still getting the "old" transform. I want what I think you described
> > > as the identity transform.
> > >    
> > >    I need to communicate three points in my event; the upper-left, 
> > > upper-right, and lower-left of the JSVGCanvas window *in document 
> > > coordinates* after the "refresh" has occurred.
> > >    
> > >    You're describing preserving changes BEFORE setDocument(), I'm 
> > > trying to capture the state AFTER setDocument() and can't figure out
> > > what I need to wait for to get points after the document has refreshed.
> > >    
> > >    It sounds like I *could* eliminate the call to setDocument() 
> > > entirely and simply set the rendering transform to the identity 
> > > transform (thus refreshing the document), then fire my event?
> > >    
> > >    Michael
> > >    
> > >    ________________________________
> > >    
> > >    From: Dan Slater [mailto:dslater@simulsoft.com <http://email.
> > > secureserver.net/pcompose.php#Compose> ]
> > >    Sent: Tue 10/28/2008 6:32 PM
> > >    To: batik-users@xmlgraphics.apache.org
> > >    Subject: RE: Rendering transform on refresh?
> > >    
> > >    
> > >    
> > >    Please forgive the multiple posts...for some reason a follow-up posted
> > >    before this original (now w/minor edit), and I haven't yet received the
> > >    original :( . I think with plain text I'll have better success...
> > >    
> > >    Hi, Michael,
> > >    
> > >    I think I might have the answer. I use a crude undo function to reset
> > >    the document, but found the render to reset each time. Here's what
> > >    worked for me:
> > >    
> > >    In your extended JSVGCanvas, place an instance field to store the last
> > >    render transform, and create getter/setter. In the constructor, set the
> > >    identity transform since this is the default when the canvas is first
> > >    booted. Then override svgLoadEventDispatchCompleted with a call to
> > >    setRenderingTransform, which in turn you've already overridden per
> > >    recent threads.
> > >    
> > >    When this is all prepared, call
> > >    svgCanvas.setLastRender(svgcanvas.getrenderingtransform) (or use
> > >    whatever transform you wish) and the canvas render should automatically
> > >    reset after you call setSVGDocument.
> > >    
> > >    I can't tell you how much time it took to test the rendering transform
> > >    in all the event listeners...it's instructive but it would have been
> > >    extremely helpful to have a concise reference for the complete
> > >    JSVGCanvas event sequence. Hope this helps some others out there...if
> > >    anybody knows how to set a listener on the canvas for when 
> the rendering
> > >    transform changes (I tried and gave up), or has a better way, I'd love
> > >    to hear about it.
> > >    
> > >    public class JSVGCanvasX extends JSVGCanvas {
> > >    private AffineTransform lastRender = new AffineTransform();
> > >    public JSVGCanvasX() {
> > >    lastRender.setToIdentity();
> > >    this.addSVGLoadEventDispatcherListener(new
> > >    SVGLoadEventDispatcherAdapter() {
> > >    
> > >    public void
> > >    svgLoadEventDispatchCompleted(SVGLoadEventDispatcherEvent e){
> > >    //set the rendering transform here, after
> > >    SVGDocument is loaded but before rendering occurs
> > >    //canvas transform resets to identity before this
> > >    event is fired
> > >    setRenderingTransform(getLastRender());
> > >    }
> > >    }
> > >    ...etc.
> > >    }
> > >    
> > >    Dan Slater
> > >    
> > >    -------- Original Message --------
> > >    Subject: Rendering transform on refresh?
> > >    From: "Bishop, Michael W. CONTR J9C880" <michael.bishop.ctr@jfcom.mil>
> > >    Date: Tue, October 28, 2008 3:41 pm
> > >    To: <batik-users@xmlgraphics.apache.org>
> > >    
> > >    I have a refresh function in my application that simply calls
> > >    setDocument() on the JSVGCanvas with the document already there,
> > >    basically causing it to reset to its default state without
> > >    zoom/pan/rotate.
> > >    
> > >    I'm also tracking changes to my rendering transform, but keying off
> > >    setRenderingTransform() doesn't seem to work; it seems to be called
> > >    before the "final" transform is achieved.
> > >    
> > >    What can I wait for to determine when the rendering transformis "done"
> > >    and ready to be communicated? Maybe computeRenderingTransform? I've
> > >    tried waiting for the GVT tree to render and for the SVG 
> "onLoad" event,
> > >    but both seem to be too early and not communicating any change.
> > >    
> > >    Michael
> > >    
> > >    ---------------------------------------------------------------------
> > >    To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > >    For additional commands, e-mail: batik-users-
> help@xmlgraphics.apache.org
> > >    
> > >    
> > >    ---------------------------------------------------------------------
> > >    To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > >    For additional commands, e-mail: batik-users-
> help@xmlgraphics.apache.org
> > >    
> > >    
> > >    
> > >    
> > > ________________________________
> > > 
> > >    ---------------------------------------------------------------------
> > >    To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > >    For additional commands, e-mail: batik-users-
> help@xmlgraphics.apache.org 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.
> > > org For additional commands, e-mail: batik-users-help@xmlgraphics.
> > apache.org 
> > > [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
> > [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
> [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

Mime
View raw message