cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [C2] SVGSerializer using xml-batik / FOP .16
Date Thu, 04 Jan 2001 22:49:08 GMT

All the pieces are in place now with respect to support for Batik in SVGSerialier. Please
do take
a look at (in C2) this is where the SVG-DOM Document is built and as usual has the code for invoking the Transcoder. Now we need to generate
list of requirements for hints etc and help/push the Batik guys. 


--- Ross Burton <> wrote:
> > > Checked in changes to move to FOP .16 and Batik. I have not yet cleaned up
the Image
> Encoders etc
> > > (though they are not needed anymore). If i don't hear any objections, i will
clean it up
> tomorrow.
> > >
> > > FYI, FOP .16 will not work with the CSIRO SVG ToolKit. So we have to move to
Batik if we
> need FOP
> > > .16
> > That's what I was wanting to ask Ross Burton since a long time (and
> > always forgot to do :)
> > Could we move the ImageEncoders to the Batik machinery?
> Spooky!!  last night I updated my Batik checkout and was going to start
> hacking
> about with Batik to see how well it works...
> What shall we do with the Image Encoders?  I think they can be removed -
> Batik's "Transcoder" interface (org.apache.batik.transcoder.Transcoder)
> is rather similar to the "ImageEncoder" interface, though more specific
> to a single document type - the core method is "transcodeToStream()"
> which takes XML (as a Document or InputSource), so the transcoder is
> responsible for the conversion from the stream to an image.  All
> concrete Batik Transcoders extend ImageEncoder which is an abstract
> class which takes a Document, casts it to SVGDocument, and the renders
> it to a BufferedImage.  The subclasses then encode this image as a file
> (such as JPEG or PNG) and then output it.
> My ImageEncoders took a BufferedImage and output to an OutputStream, so
> the conversion from stream to image was the responsibility of the
> calling code (in our case the SVGSerializer).  This meant that the image
> encoders only knew how to convert an Image to a file, and nothing else. 
> I prefer the Image Encoder model (but I am probably biased!) but keeping
> them in now that Batik is used is keeping redundant code...
> Also, the Transcoders at the moment are not customizable in the
> slightest - all PNGs have a transparent background, the background
> colour is always white, the compression ration is not customizable (and
> for JPEGs is set to 1! *), etc etc.  From a quick look it looks as if a
> set of hints can be defined for transferring this information from the
> C2 sitemap into the Transcoders.
> I'm going to join the Batik mailing list and see what we can do to get
> the transcoders suitable for proper use.
> Ross Burton
> * For people who do not know the JPEG spec (most people I presume!) JPEG
> compression varies from 0 to 1 - where 0 is so compressed that the image
> is a blur, and 1 is a perfect representation.  1 is the only compression
> ratio in JPEG which is not lossy (meaning the other compression levels
> result in the loss of data).  This would be fine - but JPEG is not that
> good at non-lossy compression and generally produces rather large
> files.  IMHO the default compression level for JPEGs in Batik should be
> about 0.8, which is compressed, but still rather good quality.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:
> .
> r additional commands, email:
> .

Davanum Srinivas, JNI-FAQ Manager

Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!

View raw message