Hi Cameron,
I would actually lean towards simply moving these animation
interfaces into the
batik.dom package. I wouldn't object to simply putting them in
batik.dom.svg
One might consider putting them in a new package batik.dom.smil.
For everyone's convenience I would even lean towards just adding the
new package to the list of packages included in batik-svg-dom.jar during
the jar file build. If someone requests that we decouple the animation
engine
completely we can do that later.
Cameron McCormack <[EMAIL PROTECTED]> wrote on 08/10/2006 03:36:30 AM:
> Cameron McCormack:
> > Ah. Taking a look at a couple of these:
>
> Ok I think I?ve covered the errors that show up in the gump log, except
> for the AnimationTarget not being found one.
>
> Thomas, what do you think is the best approach for this? It would be
> nice if the animation support can be omitted and non-animated documents
> still work. I think the problem is that some of the classes in dom.svg
> and bridge implement interfaces from the anim package. A solution would
> be to have two jars: one (anim-intf.jar) that contains these interfaces
> (AnimationTarget, AnimatableElement and AnimationTargetListener) and
> another (anim.jar) that contains the rest of the anim package.
>
> Is this reasonable?
>
> --
> Cameron McCormack, http://mcc.id.au/
> xmpp:[EMAIL PROTECTED] ? ICQ 26955922 ? MSN [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]