Hi Teck,
Teck Hua Lee <gteck...@gmail.com> wrote on 05/11/2010 11:45:49 AM:
> > The problem is that a single draw operation can generate several
> > elements. Some in the draw tree some in the 'defs' tree.
>
> I think most users are interested in the "target" SVG element (e.g.
> draw:<path>, drawString:<text>).
> The obvious use case is to attach JS code on the elements.
This could be useful in some cases however I've often found
that I want/need to add my JS code to a group containing elements
rather than many individual elements. So some mechanism for 'forcing'
the start of a new group (and a similar 'end' method) would I think
also be very useful.
> These "target" elements seem to be created by the SVGGraphics2D draw
> methods directly, so SVGGraphics2D should be able to maintain the
> reference to the last created target element. [...]
OK, that might work.
> (The same argument applies to the strange requirement for us to write
our own
> ExtensionHandlers for java.awt.Linear/RadialGradientPaint)
These were added in JDK 1.6, we target JDK 1.4. So any reference
to these would have to be optional (i.e. in a contrib directory or
something similar).
> I can easily extend SVGGraphics2D for this purpose but I feel that
> this should be a common functionality in the base framework.
Batik is an open source project so contributions are welcome.
---
> On Tue, May 11, 2010 at 5:37 AM, <thomas.dewe...@kodak.com> wrote:
> >
> > Hi Teck,
> >
> > Teck Hua Lee <gteck...@gmail.com> wrote on 05/10/2010 09:45:24 PM:
> >
> > > http://markmail.org/message/znky4hbn76ytrdr5
> > >
> > > Thomas DeWeese wrote:
> > >> At any point you can get the generated subtree by calling
> > >> 'svgg2d.getRoot(parent)'. So you can get the just generated
element.
> > >> You can also look at extending the SVGGeneratorContext (see the web
> > >> page for some examples).
> >
> > > Do I have to manually keep track of the "parent" element?
> >
> > The short answer is yes, but the question implies this represents
> > significant effort which it should not. In theory you could pass the
> > same element to 'getRoot' every time, this would make finding the new
> > element(s) a little tricky so instead you might have two one you use
> > to get the new elements and then a second that you 'transfer' those
> > new elements to for later use.
> >
> > > Do you think it would be helpful to include a getCurrentElement()
> > > API on SVGGraphics2D?
> >
> > The problem is that a single draw operation can generate several
> > elements. Some in the draw tree some in the 'defs' tree. So adding
> > the ability to call 'getCurrentElement' would significantly impact
> > the quality of the generated SVG content in the more normal case of
> > just drawing a bunch of stuff you want to save as SVG (every draw
> > operation would have to result in a 'stand-alone' subtree, which would
> > also probably mean needlessly introducing extra groups etc).
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
>
