You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Philip Wilder <ph...@gmail.com> on 2006/05/10 19:59:35 UTC

SVGGraphics2D and id

Hello all,

I have recently been working with an application that uses SVGGraphics2D to
take information from a canvas and save it to an SVG file. The complication
comes from the fact that I wish to use the id tag associated with a number
of basic shape elements to embed extra information that can be read in by a
different application. In looking over the email archives I was able to find
this message (
http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200603.mbox/%3cOF2D77ECA4.37243DE6-ON85257135.0004AC31-85257135.0004F802@knotes.kodak.com%3e)
which sort of deals with my issue and I confess that I found the response a
little disappointing.

My basic solution looks something like this (I did not compile this code
snippet so apologies if there are minor typos):

...
        svgGenerator.draw(new Rectangle2D.Double(10, 10, 20, 20));
        Node elem = svgGenerator.getRoot();
        while (elem.getLastChild() != null) {
            elem = elem.getLastChild();
        }
        Element lastElement = (Element)elem;
        lastElement.setAttribute("id", "foo");
...

This is not particularly efficient or elegant but I am hoping that it works.
My primary question to the newsgroup is, is this method safe? Can I
guarantee that this solution will always return the last element drawn?

My secondary question is has anyone ever considered tweaking the API to
include methods to access the last element drawn (or filled, etc.)?
Having the 'public void draw(Shape s)' changed to 'public Element draw(Shape
s)' would be very useful to me in this instance and it would not be hard to
envision others. At least I can't see the harm of adding a completely new
method ('public Element drawReturn(Shape)' or something) that emulates the
same functionality.

Philip Wilder

Re: SVGGraphics2D and id

Posted by Philip Wilder <ph...@gmail.com>.
thomas.deweese@kodak.com wrote:

<Snip>
>> My secondary question is has anyone ever considered tweaking the API to 
>> include methods to access the last element drawn (or filled, etc.)? 
>> Having the 'public void draw(Shape s)' changed to 'public Element 
>>     
> draw(Shape 
>   
>> s)' would be very useful to me in this instance and it would not be hard 
>>     
> to 
>   
>> envision others. At least I can't see the harm of adding a completely 
>>     
> new 
>   
>> method ('public Element drawReturn(Shape)' or something) that emulates 
>>     
> the 
>   
>> same functionality.
>>     
>
>    This might be interesting but would be totally out of the scope of
> the SVGGraphics2D, who's job it is to implement the Graphics2D interface.
> you also have issues like - how does it return a single element when you
> have a complex fill in effect (gradients), or if clipping needs to be
> applied.
>
>    Also you might be interested in using some of the internal classes
> like batik.svggen.SVGShape - that has a method:
>         public Element toSVG(Shape s)
>
>    Look familiar ;)
Indeed it does Thomas. It does leave me with the new problem of adding 
the element to the internal Tree but it is a consideration.

Thanks,

Philip

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Re: SVGGraphics2D and id

Posted by th...@kodak.com.
Hi Philip,

"Philip Wilder" <ph...@gmail.com> wrote on 05/10/2006 01:59:35 PM:

> I have recently been working with an application that uses SVGGraphics2D 
to 
> take information from a canvas and save it to an SVG file. The 
complication 
> comes from the fact that I wish to use the id tag associated with a 
number of 
> basic shape elements to embed extra information that can be read in by a 

> different application. In looking over the email archives I was able to 
find 
> this message 
(http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-
> users/200603.mbox/%3cOF2D77ECA4.37243DE6-ON85257135.0004AC31-85257135.
> 0004F802@knotes.kodak.com%3e ) which sort of deals with my issue and I 
confess
> that I found the response a little disappointing.

   As do I, but unless and until someone gets around to serious 
modifications
to the SVGGraphics2D it is the answer.

> My basic solution looks something like this (I did not compile this code 

> snippet so apologies if there are minor typos):

    This looks pretty good.

> This is not particularly efficient or elegant but I am hoping that it 
works. 
> My primary question to the newsgroup is, is this method safe? Can I 
guarantee 
> that this solution will always return the last element drawn?

   No you can't be _sure_ that it will always return the last element 
drawn, but
you can be fairly certain that if the SVGGraphics2D is modified so that it
isn't there will be better interfaces for doing this sort of work.
 
> My secondary question is has anyone ever considered tweaking the API to 
> include methods to access the last element drawn (or filled, etc.)? 
> Having the 'public void draw(Shape s)' changed to 'public Element 
draw(Shape 
> s)' would be very useful to me in this instance and it would not be hard 
to 
> envision others. At least I can't see the harm of adding a completely 
new 
> method ('public Element drawReturn(Shape)' or something) that emulates 
the 
> same functionality.

   This might be interesting but would be totally out of the scope of
the SVGGraphics2D, who's job it is to implement the Graphics2D interface.
you also have issues like - how does it return a single element when you
have a complex fill in effect (gradients), or if clipping needs to be
applied.

   Also you might be interested in using some of the internal classes
like batik.svggen.SVGShape - that has a method:
        public Element toSVG(Shape s)

   Look familiar ;)


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org