cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Burton <>
Subject Re: [C2] SVGSerializer using xml-batik / FOP .16
Date Thu, 04 Jan 2001 21:40:03 GMT

> > 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
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.

View raw message