Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: giacomo
Message-ID: <3A562C81.ECE99E93@apache.org>
Date: Fri, 05 Jan 2001 21:20:17 +0100
From: Giacomo Pati <giacomo@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] SVGSerializer using xml-batik / FOP .16
References: <20010103193112.5912.qmail@web111.yahoomail.com>
 <3A54DED5.B18183D5@apache.org> <3A54EDB3.32AEBB40@mail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

At least your are experienced with it. So your opinion is rather welcome
:)

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

This is very appreciable. I haven't read anything about how well it is
designed for server side usage (you know, multithreading stuff). Could
you get that information from the batik ML to us?

Giacomo

> 
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org