xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Additional info: things I've tried to get batik to update but have not worked:
Date Fri, 11 Apr 2008 10:59:56 GMT
Hi Rob,

Rob Davis-5 <tech@robertjdavis.co.uk> wrote on 04/07/2008 05:11:35 AM:

> This is absolutely fine as far as I'm concerned. Batik is a great tool, 
> it is barely documented in this area. Using the Eclipse IDE debugger 
> helped! The other thing I would restate is that the batik css does not 
> to totally comply with the DOM CSS Java interface specification. Some of 
> batik CSS classes do not implement the DOM CSS interface. 

   Do you have specific examples?  Also it matters what version of the
spec.  Most of the classes you mentioned are deep internal implementation
classes.  The public DOM stuff is in the batik.dom(.svg) packages that
tend to wrap/extend the classes you listed.

   That said I'm not sure you could do what you are looking to do with
the standard CSS DOM interface.

> I'd still be interested to know how I could remove the elements while
> traversing the GVT tree, without getting a concurrent modification
> exception, and so that the resultant SVG XML output to a text file shows
> these removed.

   AFAIK, outside of the JSVGCanvas we don't have multiple threads. 
So multi-thread access shouldn't be a concern in your case.  That said
I'm not sure the tree walkers are 'modification safe'.  So if you are
trying to walk the tree while you are modifying the document it wouldn't
surprise me if you could easily get into trouble.

View raw message