I'd like the batik bridge package to function more like a Builder or Abstract Factory pattern from the Design Patterns book so that 3rd parties could take advantage of the existing reader code in bridge to build their own graphics node implementations. (Note that the book also contains a "Bridge" pattern, but I don't think batik.bridge is that kind of bridge. It seems more like an Abstract Factory) The builder/factory would build a tree of graphics nodes of which gvt would be one implementation. To accomplish this I'm trying to create an abstract factory layer between gvt and bridge so new clients can create their own object trees by subclassing the abstract factory classes. I'm not a batik expert, so I'm looking for feedback on whether this project seems doable and/or desireable, and if so, on implementation issues. I've done a skeletal first pass of creating the abstraction. In the attached code I've created a new package, org.apache.batik.bridge.gnode, which includes a set of interfaces that encapsulate the gvt-specific method calls made from the bridge classes. I've refactored some of the bridge classes so they only reference the new gnode interfaces, and I've moved some gvt-dependent bridge classes to a new package, org.apache.batik.bridge.gvt. (that may not be the best place for them, but that's where they are now). Those classes are dependent on gvt. I've also created 'demo.batik.bridge.myvt' which contains factory classes to build trees of objects from package 'demo.myvt'. I've only refactored a small bit of the existing classes. I'm posting this here to see if I can get feedback on what I've done so far. Thanks for your comments.
Created attachment 18209 [details] contains modifed source from bridge and new code in package demo
So I had some time to look into this yesterday. I didn't get through everything but I think I looked at enough to get the gist of things. In short you tool the basic interface of the GraphicsNode and turned them into interfaces. Then the Bridges interact with these interfaces. While I'm not dead set against this I would say that this is not particularly exciting to me. The whole 'gnode' interface is still rather large and proper implementation of it would be extremely difficult (for example all of text layout is done in the GVT tree yet this must be done properly for complex fills to be calculated properly). So there is a non-trivial interaction between the Bridge classes and the GVT implementation (this only get's worse when you consider the SVG DOM). To be honest I'm not interested in trying to debug across libraries as this would require (it works for GVT because of 'X' but fails for BLAH, but the Bridge should really handle case 'Z' even though it can't occur with the GVT...) Also this would really push the GVT out as a public 'interface' meaning that any change to the Bridge<->GVT tree would break 'external' software - or we would have to add new subinterfaces of interfaces that the bridge would check for (Gahhh!). Finally, I think that in _most_ cases people could, for less work, simply subclass our existing GVT classes, and subclass the Bridges (replacing the 'createGraphicsNode' method) to build a 'custom' GVT tree (all the above steps are required in the 'gnode' case anyways). The only drawback would be for someone who already had a graphics tree structure that was 'by chance' essentially identical in structure to the GVT tree. I encourage other people to look at it and come to separate opinions, I'm not dead set against it but I think it would add significantly to the effort needed to develop Batik and I don't think there would be significant benefit to Batik.
I didn't provide much motivation when I posted this RFE, so here is some of that, along with some thoughts on Thomas' comments. It's possible that GNode would be large and difficult, but I think the benefits would justify the effort. SVG has the potential to be the lingua franca (or RTF, if you prefer) of graphics applications, but at present it addresses only XML to raster conversions (i.e. gif, tiff, jpg). The goal of this proposal is to promote the potential of SVG to address conversion from any app to any other app. A way to do this is to give developers a leg up on importing SVG files into their apps. This enhancement would be useful for any application that deals with graphics. My goal in the attached code is not to build a 'custom gvt tree', but to build a completely distinct object graph for an application that has nothing to do with svg. (The demo code may look a lot like gvt, but it doesn't have to be.) I think it could potentially have a large impact on the disemination of svg if it were easy for developers to import svg documents and convert them to their own application data structures. Subclassing gvt classes is not sufficient and has the negetive effect of making gvt a defacto public interface. Since it is not designed for that, apps that used it that way would likely break in complicated ways in subsequent releases of batik, which would make subclassing gvt a risk not worth taking. The point of the GNode interface is to avoid pushing gvt out as a public interface. GNode would be the public interface and it would be designed for public consumption. I'm not sure I get the possbility where 'Bridge should really handle case 'Z' even though it can't occur with GVT. If we're talking about implementing the SVG spec it seems unlikely that there could be a situation where it was possible to write legal svg that wasn't handled by gvt. In addition, I think the GNode interface should be made as simple as possible, leaving most of the implementation details in subclasses. The more work required of the subclass, the less chance there will be of conflicts.