Re: Problems with DOMUtilities / ImageTranscoder

[Thierry Kormann <tk...@ilog.fr>]

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();


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.

Hope this helps,
Thierry.

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

Re: Problems with DOMUtilities / ImageTranscoder

[Peter Becker <pb...@meganesia.int.gu.edu.au>]

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:

<code>
            org.jdom.adapters.DOMAdapter domAdapter = new
org.jdom.adapters.XercesDOMAdapter();
            org.jdom.output.DOMOutputter out = new
org.jdom.output.DOMOutputter();
            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.apache.batik.dom.svg.SVGDOMImplementation.getDOMImplementation();
            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
                t.addTranscodingHint(
JPEGTranscoder.KEY_XML_PARSER_CLASSNAME,
                                     
"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
                t.addTranscodingHint(
PNGTranscoder.KEY_XML_PARSER_CLASSNAME,
                                     
"org.apache.crimson.parser.XMLReaderImpl" );
            }
            else
            {
                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
            ostream.flush();
            ostream.close();
</code>

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

and here is the result:

<output>
java.lang.ClassCastException: org.apache.batik.dom.GenericElementNS

	at
org.apache.batik.dom.svg.SVGOMDocument.getRootElement(SVGOMDocument.java:519)

	at
org.apache.batik.transcoder.image.ImageTranscoder.transcode(ImageTranscoder.java:142)

	at
org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(XMLAbstractTranscoder.java:126)

	at
net.sourceforge.xweb.backend.images.SVGImageGenerator.createImageFileInternal(SVGImageGenerator.java:176)

	at 
	<skip/>
</output>

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,
impl);
        }
    }
</code>

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:
   http://www.peterbecker.de/texts/javacritique.html

Batik has many of the flaws mentioned there :-(

HTH,
  PeterB

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