xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hardy <vincent.ha...@sun.com>
Subject Re: GVTBuilder error with custom DOMs
Date Thu, 14 Mar 2002 10:03:59 GMT

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

   - 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

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


Vincent Hardy

This said, the 
Justin Couch wrote:
> Either that, or state up front in the documentation that the generator
> of the document must support XYZ features for it to be usable with Batik.

Yes, this is missing from the documentation, for historical reasons.

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

View raw message