Yes, it is working because I am using the DOM to delete the elements affected by the non-compliant CSS - from a list obtained by recursively searching the GVT tree - and then using the bridge context to get the equivalent affected DOM element each time to therefore build a list.
Even though I am using pure DOM to delete the elements, I rely upon the GVT and associated batik css engine classes to find the affected elements in order to build the DOM list of elements. For example, I'm using: import org.apache.batik.css.engine.CSSStyleSheetNode; import org.apache.batik.css.engine.Rule; import org.apache.batik.css.engine.SVGCSSEngine; import org.apache.batik.css.engine.StyleDeclaration; import org.apache.batik.css.engine.StyleRule; import org.apache.batik.css.engine.StyleSheet; import org.apache.batik.css.engine.sac.CSSConditionalSelector; This is absolutely fine as far as I'm concerned. Batik is a great tool, but it is barely documented in this area. Using the Eclipse IDE debugger really helped! The other thing I would restate is that the batik css does not seem to totally comply with the DOM CSS Java interface specification. Some of the batik CSS classes do not implement the DOM CSS 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. -- View this message in context: http://www.nabble.com/Modifying-internal-CSS-in-SVG-document---partial-solution---need-help-with-batik-re-draw-update-tp16275087p16536337.html Sent from the Batik - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
