xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: RFE in svggen
Date Sun, 29 Aug 2004 17:19:21 GMT
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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org


Mime
View raw message