xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Seth Tager" <seth.ta...@gmail.com>
Subject Re: using bridge to create alternative to gvt
Date Thu, 06 Apr 2006 22:13:13 GMT
I've spent some time abstracting out interfaces in an attempt to
decouple gvt from bridge. So far it looks doable, but I'm wondering
whether I'm missing something. I'm not sure I understand your
statement about 'creating classes to hold the data between DOM and
GVT'. I think you're suggesting that one way to decouple them would be
to create an intermediate set of classes to hold the data and then
pass the data objects off to some object in gvt that would build the
tree. Another way would be to require bridge clients (like gvt) to
implement an interface, and then have the clients build the tree
themselves as the document is parsed. Here's what I've done so far and
where I'm headed. Since I have limited batik experience, please let me
know if you think I'm looking for trouble.

My goal is to leverage the considerable effort that has already been
spent on building a gvt tree from svg. It seems to me that a framework
for building arbitrary class trees from svg would do much to promote
svg as it would lower the barrier to entry for 3rd party projects that
wanted to read svg and transform it to their internal data format.

So far I've factored out most of the calls within bridge to methods of
GraphicsNode and CompositeGraphicsNode. What I have left to do is to
abstract the creation of objects, which entails (I think) making many
of the subclasses of AbstractGraphicsNodeBridge abstract
(SVGShapeElementBridge, for example), moving the gvt creation code to
gvt-specific subclasses, and then creating a second set of bridge
subclasses that will create my own objects.

Any comments?

Does anyone think that this would be a useful feature of batik?

Seth


On 3/13/06, thomas.deweese@kodak.com <thomas.deweese@kodak.com> wrote:
> Hi Seth,
>
> "Seth Tager" <seth.tager@gmail.com> wrote on 03/13/2006 05:23:00 PM:
>
> > I don't think this post made it the first time.
>
>    It did, I just didn't have much to add.  You are correct
> that the Bridge package is pretty tightly tied to both the
> DOM and the GVT (although both of those are independent of
> each other).
>
>    There are some pieces that are very reusable like the
> parsers package.  But most of the stuff that the Bridge
> does I have a hard time imagining how to abstract without
> creating a whole new set of classes just to hold the data
> between DOM and GVT - which to be honest just doesn't make
> sense to me.
>
>    The Bridge and GVT do try to use standard AWT classes
> wherever possible so depending on what your back end is
> you might be able to use parts of these.
>
> > Has anyone out there been able to leverage batik to build their own
> > internal data structures for manipulating svg docs?
> >
> > On 2/28/06, Seth Tager <seth.tager@gmail.com> wrote:
> >
> > > I'd like to read an svg document and convert it to my own internal
> > > object tree, similar to the way a gvt is built. It seems like the
> > > org.apache.batik.bridge package might be useful, but it doesn't look
> > > like the same kind of bridge described in Design Patterns by Gamma,
> > > Helms, etc.? (i.e. it seems to be tightly coupled with the GVT
> > > package, and _not_ meant for swapping gvt-like implementations)
> > >
> > > Is there some way I might leverage that package to build my own tree
> > > from an svg doc? It looks like the best i can do is to use the bridge
> > > and gvt packages as a template/guide for creating my own tree builder
> > > code. Has anyone done something like this already?
> > >
> > > Seth
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>

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


Mime
View raw message