-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
in the last weeks, here was a discussion about a TranscoderRegistration for
batik. Now, I've hopefully written all ideas together into a text file.
I'm open for ideas and comments. There are still points to think of.
Some parts (called clean up) can also be done before. I hope to get an OK for
them, so they are commited to cvs, when I make the changes.
With kind regards
Torsten Knodt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9c3u9vxZktkzSmiwRAqxBAKCXkfcEaw+lEg/DfMG4u95F78pFOACeNfsb
I3jOQSw8IZ7+K71EPLHpbss=
=HmVM
-----END PGP SIGNATURE-----
Idea for a TranscoderRegistration
---------------------------------
Author: Torsten Knodt <[EMAIL PROTECTED]>
Version: 0.1
Date: 2002-09-02
Abstract:
This document describes an idea for having a TranscoderRegistration in batik.
For this the Transcoder API will be extended, and perhaps, simplified at some
points. As the aim of this registration is to support interaction with other
applications, this document also covers other parts of the API's,
which could be changed/ extended to support interacting with other
applications. This document is a summary of mail exchanges in the batik
developers mailing list. Ideas came from:
- Keiron Liddle <[EMAIL PROTECTED]>
- Thomas E Deweese <[EMAIL PROTECTED]>
I hope, I haven't missed one. Feel free to contact me, if so.
Oh yes, my personal interest in this project is, to make the interaction with
cocoon better. I've written a ImageMap transcoder, which is currently in clean
up phase, and a still little problematic WBMP transcoder using the Java
Advanced Imaging Toolkit. As the transcoders will get more, I don't want to
integrate everyone seperatly into cocoon. The same is for the rasterizer,
which I use for testing.
1. Why the registration?
Currently batik has many applications in itself, like Squiggle and the
Rasterizer.
- The rasterizer has to know about the transcoding hints, to print out his
help and parse them. Also the file extensions have to be handled.
- Squiggle has to create dialogs for configuring the Transcoders. The file
extensions are the smaller problem.
But also, batik is used in external programs, like FOP and Cocoon.
- FOP uses batik for embedding graphics.
- Cocoon uses batik for the same.
At least for cocoon, creating the hints for the Transcoders is a problem, as
he has to know about the needed hints for them. So currently the specific
cocoon sources have to be kept in sync with batik. Writing a transcoder for
batik, requires to write code for cocoon to use it there.
2. Now, the requirements
- The registration should be decentralized, so that Transcoders are
registered automatically, as they are in the classpath.
- Manually adding Transcoders should be possible.
- A single transcoder class should be able to register for different file
formats.
- The registration should provide all informations nercesary for the
programs. This should be:
- Standard extensions for the file format
- Default extension for the file format
- Standard MIME-Types for the file format
- Default MIME-Type for the file format
- Description of the Transcoder
- Author of the Transcoder
- Perhaps usage licensing information
- Description of the used hints
- It should be easy to write adaptors to the applications using batik.
- Applications shouldn't have to implement all things again and again. The
following utilities should be available:
- Choosing transcoders and configuring them out of a swing dialog. This
could be done by providing the whole dialog or only by providing a
container with components.
Used by e.g.: squiggle
- Choosing transcoders and configuring them via the Avalon Configurable/
Parameterizable interface.
Used by e.g.: cocoon
- Choosing transcoders and configuring them via command line parameters.
Used by e.g.: rasterizer
3. Implementation idea's
- Locating transcoders
- The transcoders could be located via javax.imageio.spi.ServiceRegistry.
The problem is, that this is a java 1.4 interface.
- A java 1.3 compatible alternative would be org.apach.batik.util.Service.
We could decide on compile time, or on runtime, what interface is used.
Both are compatible from registree (Transcoder) view.
- Queries to the transcoder database will be done via a TracoderRegistry
class. There it will be possible to get an iterator, or if possible, a
default transcoder matching different criterias. The problem is, that some
transcoders need different input/ output interfaces, for which different
criterias are needed:
File based implies Stream based: File extension
Stream based: MIME-Type
Printer: ???
XML (SAX) based: ?DOCTYPE?
The input and output format has also to be a criteria to look at. Why:
- Rasterizer will only be interested in files as source and destination.
- Cocoon will be interested in SAX events as source and a SAX stream or
OutputStream when using as transformer or serializer.
- Squiggle will be interested as
- The transcoders should provide methods for getting informations out of
them. This interface should have localisation support. These informations
are also used when quering the TranscoderRegistration.
- Utilitiy Classes
- Support the Avalon Command Line interface for configuring and choosing
the transcoders.
- Support for GUI's
- getting menu's with export formats
- supporting save dialogs with file format's
- containers for configuring transcoders
- Support for Avalon base appliactions
- choosing and configuring applications via Configurable and
Parameterizable
4. To look at/ To think of
- It would be helpful, to have java 1.4 for the TranscoderRegistration. How
long should we wait for java 1.4, and do we delay the Registration until
then.
- What existing interfaces can be used to simplify things.
- Perhaps other Avalon interfaces like Poolable could also be used. No
application is required to use them, but could do it. At least for
cocoon, it would be helpful I think.
- Perhaps it would be good to change the whole hinting system to the
Avalon Configurable or Parameterizable concept. This concept would allow
more complex configuration of transcoders, which could e.g. be used to
control dithering before the encoding.
- We can classify transcoders in serveral ways.
Some are working on a bulk file, others on XML data, others on a
SVGDocument, some a GVT tree and again others on a BufferedImage. Some
also need more than one. Perhaps javax.imageio can be used for the last.
For the output, we have similar alternatives.
The current system of extending abstract classes based on the input
format seems not a good solution for me. The problem is to find an
alternative which reduces the work in the transcoders.
- The current hinting system will be a problem, with Transcoders using other
interfaces. E.G. JAITranscoder uses the JAI Encoder interface. The encoder
specific hints have to be read out of the class files. So they are not
known at compilation time. I think this will be a problem, with the
current system. The hints (configuration) shouldn't be pushed to the
transcoders, they should be able to fetch what they need.
5. Implementation steps (commited seperatly)
1. Clean up's in batik
- Convert cli tools to Avalon CLI interface
- Move transcoder specific parts from applications to transcoders
(Will later be extracted to utility classes partially)
2. Basic registration
- Create a TranscoderRegistration without query support
- Implement Transcoder Iteration
- Implement Manual Registration
- Create interface for javax.imageio.spi
- Create interface for org.apache.batik.util.Service
- Implement Java 1.4 support in build.xml and friends.
3. Query support
- Add method to TranscoderRegistration to query for MIME-types,
file extensions and other basics.
- Use these within the applications.
4. Utilities
- Extract parts from the transcoders to utility classes.
- Use those classes in the applications.
Please send comments to the batik developers mailing list.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
