Hervé Girod wrote:

I'm using Batik to convert other (older or proprietary) vector graphic format in SVG. I'm using the svggen package for that, because then I only need to now the format => Java conversion, and by creating a new transcoder, this is made very simple with Batik.
My problem is that it is not possible to control the SVG Tree by using SVGGraphics2D. I am now able to do it, but in order to do it, I had to create a new SVGGraphics2D class, rather than subclassing it, because of some private fields and methods.
Would it be possible to make some of these methods and fields protected, it would ease the process of controlling the generated SVG Tree.
What would be necessary is :


    in org.apache.batik.svggen: SVGGraphics2D
       - make domGroupManager, domTreeManager, and generatorCtx
    protected, or provide setters for them

I would actually prefer to make protected 'createXXX' methods for these so your subclass can override and construct your version of them. This prevents issues with swapping the various managers in the middle of a document.

in org.apache.batik.svggen: DOMGroupManager
- make currentGroup and domTreeManager protected instead of private
- make setTransform protected instead of private
in org.apache.batik.svggen: DOMTreeManager
- make groupManagers and topLevelGroup protected instead of private


I think these modifications would be sufficiant to be able to be able to control the SVG Tree building without creating an entirely new class.

Why don't you make the changes and check? Then if it works well you could submit the changes as a patch ;)

Another enhancement in svggen would be great too :

in org.apache.batik.svggen: SVGGraphics2D
- allow to set a custom XMLWriter (in some cases I encountered with
exotic Unicode Strings, the actual failed to provide a proper
conversion)
in org.apache.batik.svggen: XMLWriter
- make this class protected in order to be able to extend it

Well since currently the code references XmlWriter statically, I'm not sure how much this would help for extension. We are likely to move to using dom.util.DOMUtilities for output. For users to extend output (which I think makes sense) this would have to become instance based.

And it would be great too if the SVGShape class could manage Java arcs without automatically converting them to Curves. It could be done by providing a new SVGArc class...

This might be nice as well. You should feel free to make bugzilla entries for any or all of these so they don't get forgotten. We really do look at bugzilla.

Thanks for reading, (and thanks for this great API !!)

You are welcome and I'm glad you have found it useful.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to