Thanks Thomas. > 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).
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. 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. We shouldn't need to worry about the structure of the DOM tree when the GraphicsContext is written out. I can easily extend SVGGraphics2D for this purpose but I feel that this should be a common functionality in the base framework. (The same argument applies to the strange requirement for us to write our own ExtensionHandlers for java.awt.Linear/RadialGradientPaint) -Teck 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
