>>>>> "TK" == Torsten Knodt <[EMAIL PROTECTED]> writes:
>> The jdk1.4 javax.imageio does a better job of supplying info I
>> think.
TK> The design is nice, but is not directly useable, as it depends on
TK> BufferedImage.
Actually if you look closely at the API it does not require the
use of BufferedImage (although that is the easiest way to access the
image data). It's been a while since I looked at the API's in detail
but I'm very sure it's possible to get demand pull access to data.
TK> Transcoders are more generic. But the registration process itself,
TK> perhaps some subclasses too, are good, I think. But this would
TK> make batik depend on jdk1.4. Would this be OK?
I don't believe so. Of course eventually we will probably move to
1.4 (as we moved from 1.2 to 1.3) but I don't think 1.4 is quite there
yet. And a lot of people are still using 1.3. It is possible that we
might require 1.4 for compile (or add an additional 1.4 build target -
I think ant allows you to check for 1.4 in the 'build.xml' file or we
could add it to the 'build.properties' file).
With that there would be a lot of tricks that you can play with
the class loader where you load a 1.3 safe class that checks for 1.4
features (like javax.imageio) and if so bootstraps the 1.4 specific
features into Batik. Otherwise all the classes that require 1.4 while
on the class path would never be loaded - so no problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
