Justin, As the team contact for the Batik project, and on behalf of our team, I am responding to your comments about the software we are developing at Apache.
> From [EMAIL PROTECTED] Wed Mar 13 17:35:52 2002 > Date: Thu, 14 Mar 2002 12:38:32 +1100 > From: Justin Couch <[EMAIL PROTECTED]> > Subject: [JAVA3D] No SVG Textures :( > Comments: To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > > Excuse me while I vent a moment please.... > > Batik is a PoS. > > There, I feel better now :) > This is insulting. You may not have found yet what you wanted in the Batik software, but I do not see why you would make such a comment. The Batik team is working very hard on its SVG implementation and has been for almost two years now. We are putting a lot of effort in ensuring the quality of our project and we are considered to be one of the top SVG implementations. We all prefer working in a spirit of mutual respect. Batik may not be perfect (but what is?), and we are open to comments. But Batik offers a lot of functionality, and I am convinced it offers what you need. > Anyway, I've come across multiple insurmountable problems with using the > Batik library as a texture generator. Firstly, an most importantly, it > won't work with any user generated DOM. The DOM must be generated by > their internal document loader. It won't even run with the standard JAXP > parser that comes with JDK1.4FCS, let alone our custom DOM builder that > is used by Xj3D. Right, and I have explained why on the batik mailing list where you sent your question. There is no way an SVG renderer could work with a generic DOM implementation (I have copied my detailed answer below). > I started the process of trying to get some of the code > to be modified so that it would work with any old DOM, but there are > sooo many assumptions about using their internal interfaces and > implementations which completely screws the use of anything else. > Basically, after spending a day trying to modify the code to get it to > work, I've given up. If someone wants us to do SVG textures using Batik, > you'll have to pay me to do it.... :( > > On top of this, the architecture of the library is no conducive to > building real-world applications. The way they've structured the code is > to basically assume you are going to use one of their very highlevel > structures, such as a swing canvas (SVGCanvas). This is incorrect. You can do a lot in Batik without the JSVGCanvas: you can use Renderers directly, you can use GraphicsNodeRable8Bit GraphicsNodeRed8Bit, etc.... > Within this there are so > many levels of threading and caahcing that is would be a nightmare > trying to use it in a 3D graphics environment. > There is threading in the Swing components. It is needed to get a reactive interface when processing documents. You do not have to use these threads for converting an SVG document to a raster format. People are doing it and our sample rasterizer application does it. You could too. > Anyway, SVG Textures, and consequently implementing Text nodes in Xj3D > are now put on the backburner for a very long time unless someone can > come up with an alternative SVG library implementation. I really don't > feel like starting yet another project and implementing my own renderer. For your information: - SVG is a 600+ pages specification which uses other specifications (CSS, DOM, SMIL) of comparable sizes. - Implementing Batik so far has meant about 10 men/year. There is more in Batik than just the renderer, but the bulk of the effort was in the renderer. It seems to me that trying harder to use Batik would be more efficient than writing your own renderer. Regards, Vincent Hardy Senior Staff Engineer, Sun Microsystems Apache Batik Team Contact. > Justin, > > I'll also respond to your email on the java3d-interest mailing list > and cc the batik-users list. > > In the meanwhile, let me explain why Batik does not work > with a generic DOM tree and why it could not, even if it wanted to. > > DOM is an *API* that implementations need to expose. There are generic > implementations of that API, such as the ones provided by Xerces or > Crimson, and they allow generic manipulation of XML content through > the DOM API. However, this is limited to generic manipulation and > it is not enough for what is required for SVG processing. > > Concrete examples: > > - SVG requires implementation of the SVG DOM which has a lot of > extensions compared to DOM Core. This is not supported by generic > implementations. > > - You cannot have a generic SVG DOM implementation because it > requires a rendering engine. The SVG DOM implementation needs > to have to have access to the rendering > engine to be able to implement the SVG DOM (e.g., for returning > the bounding box of an object). The rendering engine is > implementation > specific. > > There are other examples, such as the implementation of CSS styling or > the implementation of the SVG structure (e.g., the <use> element). > Simply put: Batik exposes the DOM API as it is supposed to but can > only work with it own DOM implementation. > > As to accepting a org.w3c.dom.Document in the GVTBuilder interface, > you have a point that we should document the restriction. We are > accepting an org.w3c.dom.Document object for historical reasons and > I agree it is misleading. > > Note that there is a utility to convert any DOM tree to our > implementation: > > org.apache.batik.dom.util.DOMUtilities.deepCloneDocument() > > Regards, > Vincent Hardy > > This said, the > Justin Couch wrote: --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
