-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
some days ago I posted an Transcoder to generate Image Maps, which I'm still
improving. Also I'm working on a Transcoder to use any Encoders of the Java
Advanced Imaging Toolkit (JAI). The last is done to have support for WBMP's,
but others are also supported, including BMP. I think adding ICO for favicons
is not so much work.
All these transcoders will be used in cocoon by me. But the transcoders are
also used in the rasterizer, the browser and perhaps others. This brought me
to the idea to create something like a transcoder registration in batik,
which would be used by all applications.
What do you all think about this?
Has anyone else tought about it before?
Has anyone idea's for this?
What should a Transcoder Descriptor contain?
Here what I think:
- - There should be an interface for such a registration class.
- - One implementation, the only we provide, should staticly register all
Transcoders we have. This shouldn't be done directly, but by calling a static
register method in the Transcoder Object itself. For this the Transcoder
interface has to be extended for such a method.
- - There should be a TranscoderDescriptor class which contains a list of
mime-types, default extensions, transcoder name and hint descriptions. For
the last two, there has to be support for localization.
- - Each Transcoder has one or more TranscoderDescriptors. The PNG, GIF, TIFF
and SVG transcoders can have one descriptor each, as they only generate one
graphic format. The JAI ones, generate their Descriptors out of the Encoder
Descriptors from JAI. This is partly done using the reflection API. Sorry, no
other way in the mean time.
- - The registration interfaces should be accessible by some hash maps sorted by
extensions, mime-types and transcoder names. There should also be sorted
enumerations to create menu's or filters for FileDialogs.
On application side, the following has to be done:
- - The rasterizer must be changed to use the new interface. The hints should be
moved to one parameter like -hint:name=value. The help must read them out of
the registration.
- - Squiggle is more work. There the export dialogs have to be created out of
the registration, also the export menu. The last shouldn't be a great deal,
but the first.
- - For cocoon I haven't looked so far. First I'd like to hear your ideas and if
you agree, implement the registration.
With kind regards
Torsten Knodt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9XBL9vxZktkzSmiwRAu/NAJ9jBKi9XaSyRegjYKv2TgE34B4JCgCfbgqP
VGpJ3YJd5Grt3lQF9CpIPBo=
=bByN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
