xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: using bridge to create alternative to gvt
Date Fri, 07 Apr 2006 01:30:14 GMT
Hi Seth,

"Seth Tager" <seth.tager@gmail.com> wrote on 04/06/2006 06:13:13 PM:

> 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.

   In the end I don't think there is a large difference between the
two.  Perhaps you save some intermediate memory but if I give you
an java.awt.Path with the data what is the difference from calling
20 different methods (like PathParser does)?  You can pull the data
out of the path object at least as easily as implement the PathHandler
interface...

> 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.

   Well, I'm not sure what you code looks like so it's a little hard
to say.  I'll say that in general the most challenging parts of batik
are the 'use' element, and 'text' (text is _really_ hard).  Also of
course efficient dynamic updates are tricky (dependency tracking).

   Also the implementation of the SVG DOM (getting things like 
getting BBox, Text content interfaces, getting intersection lists).

> 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.

   I don't know for certain but it seems to me that this interface would
be huge (filters, clips, patterns, gradients, fill, stroke, use) I
would expect that many people would prefer to implement the Graphics2D
interface to import SVG data - it may be useful for importing other data
as well.  However it can be a bit lossy.

> 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.

   I really don't think I follow you here.  Do you care to share your
work so far?

> 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
> 


---------------------------------------------------------------------
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