-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> >> 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.
I've looked at it. It is possible to use meta data. But this can only be used
to forward informations between "compatible" transcoders. Yes, for batik
internal usage, we could put the DOM tree as meta data, but I don't think
this is a good idea. Then the PrintTranscoder and other vector oriented
Transcoders have to much garbage in them. I've added an idea for this into
the document I'm writing.
> 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).
You mean using ImageIO SPI for java 1.4, and e.g. your Service API for 1.2 and
1.3? And when batik requires java 1.4, this support can be removed. Would be
an idea.
> 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.
Could be done, but why can't we decide this at compile time? OK, there would
be two binary archives being needed. But I think this is OK. Avalon is doing
the same.
With kind regards
Torsten Knodt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9c1+qvxZktkzSmiwRAqnEAJsFpuP6O1LEUKGvWE810ipBTBdoeACgk0RX
vIGM9otvHSG4oCq5WZn8Lhc=
=jgIn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
