Return-Path: <ross.burton@mail.com>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 70323 invoked from network); 10 Apr 2000 15:44:46 -0000
Received: from doggy.lineone.net (HELO scooby.lineone.net) (194.75.152.224)
  by locus.apache.org with SMTP; 10 Apr 2000 15:44:46 -0000
Received: from eddie (host212-140-107-64.btinternet.com [212.140.107.64])
	by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA23477
	for <cocoon-dev@xml.apache.org>; Mon, 10 Apr 2000 16:41:42 +0100 (BST)
Message-ID: <002101bfa303$ab941020$406b8cd4@eddie>
From: "Ross Burton" <ross.burton@mail.com>
To: "Cocoon Development" <cocoon-dev@xml.apache.org>
Subject: Image Serializers
Date: Mon, 10 Apr 2000 16:16:41 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Hi,

I've been fiddling today with the SVG serializer, and have come to several
conclusions:

1) the demo SVGs which come with IBM's SVGView don't work, unless I delete
the DOCTYPE declaration (I get an Invalid Character error from Xerces) even
though the DTDs are in the same directory.  The SVG-ified Cocoon 2 logo also
fails to work.

2) The example sitemap needs the SVG serializer added to it (along with
ImageSerializer and FO2PDFSerializer)

3) IMHO, the image serializers need more abstraction.

At the moment all SVG files (SVGSerializer) and <image> tags
(ImageSerializer) are encoded using the Sun JPEG encoder, set to maximum
quality.  Although this works, it is hacky (IMHO):

* What if I want an alpha channel?
* What if I want exact detail in the image, which JPEG will remove
* What if I want to reduce the compression ratio, so that images are smaller
(high quality JPEGs can be large)

I propose the creation of this interface:

    package org.apache.cocoon.serializers.image;

    public interface ImageWriter implements Component, Configurable {
        void init(Configuration conf);
        String getContentType();
        encode(BufferedImage image, OutputStream out) throws IOException ;
    }

(This name is not perfect, but ImageSerializer is already used)

Concrete implementations of this interface are responsible for taking a
BufferedImage and outputing it to an OutputStream.  A JPEG implementation is
trivial, as the JDK comes with a JPEG codec.  PNG's are also fairly easy as
there is a Java package called PNGEncoder which is under the LGPL.

Obviously this abstraction is not very handy without some paramters to
fiddle with:

    <!-- create a JPEG image writer with good quality images -->
    <component role="jpegwriter"
class="org.apache.cocoon.serializers.images.JPEGWriter">
        <param name="compression" value="0.7"/>
    </component>

    <!-- create a JPEG image writer with poor quality images -->
    <component role="poorjpegwriter"
class="org.apache.cocoon.serializers.images.JPEGWriter">
        <param name="compression" value="0.2"/>
    </component>

    <!-- create a PNG image writier, default options -->
    <component role="pngwriter"
class="org.apache.cocoon.serializers.images.PNGWriter"/>

    <!-- create a SVG serializer, defaulting to using the JPEG writer -->
    <serializer name="svg"
class="org.apache.cocoon.serializers.SVGSerializer">
        <param name="writer" value="jpegwriter"/>
    </serializer>

    ...

    <process ...>
        <generator/>
        <filter/>
        <serializer name="svg">
            <!--
                here we override the image writer with the PNG writer.
                another solution would be to have two instances of the SVG
writer, one using JPEG
                and another using PNGs.
            -->
            <param name="writer" value="pngwriter"/>
        </serializer>
    </process>


IIRC, the original sitemap specification stated that parameters to sitemap
components are inherited, is this the case?

With this interface, when the serializers are configured they get a
reference to the ImageWriter through the component manager.  This is then
used instead of hardcoding a particular file type:

    public void notify(Document doc) throws SAXException {
        try {
            ImageWriter writer = context.getComponent(myWriter);  // String
myWriter was taken from the Configuration object passed
            BufferedImage img = SvgToAwtConverter.convert(doc,this.source);
            this.response.setContentType(writer.getContentType());
            writer.encode(img, output);
            output.flush();
        } catch (IOException e) {
            e.printStackTrace(System.err);
        }
    }

Well, that's it.  I'm sure there are holes in it somewhere, so poke it and
flame away!  If all goes well I'll probably start coding Tuesday night or
Wednesday (depending on how a meeting Tuesday goes).

Ross Burton