xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Becker <pbec...@meganesia.int.gu.edu.au>
Subject Re: Problems with DOMUtilities / ImageTranscoder
Date Thu, 12 Jul 2001 08:26:19 GMT
Thierry Kormann wrote:
> On Tuesday 26 June 2001 14:34, Peter Becker wrote:
> > Jon Bråtøymyr wrote:
> > > Hi,
> > >
> > > I'm having problems with creating an image from a plain
> > > org.w3c.dom.Document. I was told that I could use
> > > DOMUtilities.deepCloneDocument to convert a w3c-Document to a
> > > SVGDocument, but when I run the transcoding I get a ClassCastException.
> > > Apparently when the ImageTranscoder tries to cast the root element to
> > > org.apache.batik.dom.GenericElement.
> I think you might have used the method with an appropriate argument.
> You must give the original document and then the DOMImplementation you want
> to use.
> The document is the one you have (that can be from xerces, generic DOM or
> whatever) then the DOMImplementation must be the SVGDOMImplementation.
> DOMImplementation impl = SVGDOMImplementation.getDOMImplementation();

Even if this repeats Jons code more or less exactly, here is my try:

            org.jdom.adapters.DOMAdapter domAdapter = new
            org.jdom.output.DOMOutputter out = new
            org.w3c.dom.Document w3cdoc = domAdapter.createDocument();
            org.w3c.dom.Node root = w3cdoc.importNode( out.output(
_svgElement ), true );
            w3cdoc.appendChild( root );

            org.w3c.dom.DOMImplementation impl =
            org.w3c.dom.Document svgDoc =
org.apache.batik.dom.util.DOMUtilities.deepCloneDocument(w3cdoc, impl);

            ImageTranscoder t;
            if( target.toString().endsWith( ".jpg" ) ||
                target.toString().endsWith( ".jpeg" ) )
                // create a JPEG transcoder
                t = new JPEGTranscoder();
                // set the transcoding hints
"org.apache.crimson.parser.XMLReaderImpl" );
                t.addTranscodingHint( JPEGTranscoder.KEY_QUALITY,
                                      new Float(.8) );
            else if( target.toString().endsWith( ".png" ) )
                // create a PNG transcoder
                t = new PNGTranscoder();
                // set the transcoding hints
"org.apache.crimson.parser.XMLReaderImpl" );
                throw new ImageGenerationException( "Image '" +
target.toString() +
                                "' could not be generated: unknown
extension" );

            // create the transcoder input
            TranscoderInput input = new TranscoderInput( svgDoc );
            // create the transcoder output
            OutputStream ostream = new FileOutputStream( target );
            TranscoderOutput output = new TranscoderOutput( ostream );
            // save the image
            t.transcode( input, output );
            // flush and close the stream

(sorry about all the package names, but I knew I would have to remove it
later ;-) )

and here is the result:

java.lang.ClassCastException: org.apache.batik.dom.GenericElementNS






Exactly Jon's problem and what I wrote some time ago.

> BTW: We could not rely on a generic DOM implementation at least for building
> and rendering SVG documents because SVG is complex and needs special hooks.
> The best example is to implement external <use> element with the correct
> cascading algorithm for the CSS properties.

As said in the other thread: then either don't claim to accept the
generic interfaces or just fall back into a less performant mode, e.g.
like this:

<code implemented="false">
    public TranscoderInput(Document document) {
        if( document instanceof SVGDocument ) {
            this.document = document;
        else {
            this.document = DOMUtilities.deepCloneDocument(document,

where impl is an instance of your DOMImplementation and the
deepCloneDocument works. This should be easy to do (if the cloning
works), you can add a hint on the performance problem to the JavaDoc.
Jon, you and I would have saved hours.

So currently I have to stick with my temp files which sometimes just
won't get deleted but otherwise are not a big issue for me, but surely
are if you want to use a dynamic environment and not the more
compilerlike approach of XWeb.

BTW: I finished the first version of my Java rant *g* See:

Batik has many of the flaws mentioned there :-(


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

View raw message