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