[prev in list] [next in list] [prev in thread] [next in thread]
List: batik-users
Subject: Re: Dynamic manipulation SVG content using java2d
From: thomas.deweese () kodak ! com
Date: 2010-05-13 10:08:24
Message-ID: OFDA4CE8E8.33CA330D-ON85257722.003540F4-85257722.0037B365 () knotes ! kodak ! com
[Download RAW message or body]
--=_alternative 0037B36285257722_=
Content-Type: text/plain; charset="US-ASCII"
Hi Teck,
Teck Hua Lee <gteckhua@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.deweese@kodak.com> wrote:
> >
> > Hi Teck,
> >
> > Teck Hua Lee <gteckhua@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
--=_alternative 0037B36285257722_=
Content-Type: text/html; charset="US-ASCII"
<tt><font size=2>Hi Teck,</font></tt>
<br>
<br><tt><font size=2>Teck Hua Lee <gteckhua@gmail.com> wrote on 05/11/2010
11:45:49 AM:<br>
<br>
> > The problem is that a single draw operation can
generate several<br>
> > elements. Some in the draw tree some in the 'defs' tree.<br>
> <br>
> I think most users are interested in the "target" SVG element
(e.g.<br>
> draw:<path>, drawString:<text>).<br>
> The obvious use case is to attach JS code on the elements.<br>
</font></tt>
<br><tt><font size=2> This could be
useful in some cases however I've often found</font></tt>
<br><tt><font size=2>that I want/need to add my JS code to a group containing
elements</font></tt>
<br><tt><font size=2>rather than many individual elements. So some mechanism
for 'forcing'</font></tt>
<br><tt><font size=2>the start of a new group (and a similar 'end' method)
would I think </font></tt>
<br><tt><font size=2>also be very useful.</font></tt>
<br>
<br><tt><font size=2>> These "target" elements seem to be
created by the SVGGraphics2D draw<br>
> methods directly, so SVGGraphics2D should be able to maintain the<br>
> reference to the last created target element. [...]<br>
</font></tt>
<br><tt><font size=2> OK, that might
work.</font></tt>
<br>
<br><tt><font size=2>> (The same argument applies to the strange requirement
for us to write our own<br>
> ExtensionHandlers for java.awt.Linear/RadialGradientPaint)<br>
</font></tt>
<br><tt><font size=2> These were added in JDK 1.6, we target
JDK 1.4. So any reference</font></tt>
<br><tt><font size=2>to these would have to be optional (i.e. in a contrib
directory or </font></tt>
<br><tt><font size=2>something similar).</font></tt>
<br>
<br><tt><font size=2>> I can easily extend SVGGraphics2D for this purpose
but I feel that<br>
> this should be a common functionality in the base framework.</font></tt>
<br>
<br><tt><font size=2> Batik is an open
source project so contributions are welcome.</font></tt>
<br>
<br><tt><font size=2>---</font></tt>
<br>
<br><tt><font size=2>> On Tue, May 11, 2010 at 5:37 AM, \
<thomas.deweese@kodak.com> wrote:<br>
> ><br>
> > Hi Teck,<br>
> ><br>
> > Teck Hua Lee <gteckhua@gmail.com> wrote on 05/10/2010 09:45:24
PM:<br>
> ><br>
> > > </font></tt><a \
href=http://markmail.org/message/znky4hbn76ytrdr5><tt><font \
size=2>http://markmail.org/message/znky4hbn76ytrdr5</font></tt></a><tt><font \
size=2><br> > > ><br>
> > > Thomas DeWeese wrote:<br>
> > >> At any point you can get the generated subtree by calling<br>
> > >> 'svgg2d.getRoot(parent)'. So you can get the just generated
element.<br>
> > >> You can also look at extending the SVGGeneratorContext
(see the web<br>
> > >> page for some examples).<br>
> ><br>
> > > Do I have to manually keep track of the "parent"
element?<br>
> ><br>
> > The short answer is yes, but the question implies
this represents<br>
> > significant effort which it should not. In theory you could
pass the<br>
> > same element to 'getRoot' every time, this would make finding
the new<br>
> > element(s) a little tricky so instead you might have two one
you use<br>
> > to get the new elements and then a second that you 'transfer'
those<br>
> > new elements to for later use.<br>
> ><br>
> > > Do you think it would be helpful to include a getCurrentElement()<br>
> > > API on SVGGraphics2D?<br>
> ><br>
> > The problem is that a single draw operation can
generate several<br>
> > elements. Some in the draw tree some in the 'defs' tree.
So adding<br>
> > the ability to call 'getCurrentElement' would significantly impact<br>
> > the quality of the generated SVG content in the more normal case
of<br>
> > just drawing a bunch of stuff you want to save as SVG (every
draw<br>
> > operation would have to result in a 'stand-alone' subtree, which
would<br>
> > also probably mean needlessly introducing extra groups etc).<br>
> ><br>
> <br>
> ---------------------------------------------------------------------<br>
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org<br>
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org<br>
> <br>
</font></tt><font size=2 face="sans-serif"><br>
</font>
--=_alternative 0037B36285257722_=--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic