-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
sorry for answering so late, but I had some things to work.
> >> The other alternative is to simply include a Services entry in the
> >> standard Jar files. But for stuff we provide doing it through a
> >> static method helps to ensure they always get registered.
> TK> What I'm thinking of, is to reduce dependencies on implementing
> TK> classes. And with static calls, this is done. I think SPI is
> TK> perfect for a registration. Do you see problems, where this
> TK> mechanism could fail?
> I see two issues. First it's fairly easy for the Services file to
> 'get lost' (especially if someone is pulling bit's and pieces of Batik
> out into their own project).
I think a comment in Transcoder or AbstractTranscoder should help there. Also
this has to be mentioned in the documentation. And then, if someone doesn't
copy the service entries, it's his problem. There will always be problems,
when you need different things.When someone uses batik and forgets to have a
xml parser, he also has a problem. Adding them manually in the Registration
or somewhere else gives a place more to keep in sync with the transcoders.
But this can be added always without problems, as SPI has a function the
register manually.
> Second if various class pieces of the
> distribution get lost (not the Services file) I think the Service
> stuff will register what it can and ignore the rest, so if the JPEG
> codec was missing everything would appear to work except JPEG's which
> would probably be more confusing than getting a stack trace at class
> load time saying it can't create the JPEG codec.
Agreed.
> >> > > - - 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. Some of this is already done for the
> >> ImageTagRegistry. Some of the rest is in the BridgeExtension class
> >> (although I must admit that I didn't make that class localizable,
> >> although you are correct it should be).
> TK> You mean, because the external resource could depend on
> TK> e.g. Accept-Language? I think my problem is a little
> TK> different. I'd like to have the localization, to show the menus
> TK> and dialogs in the right language.
> No I was thinking very specifically of 'public String
> getDescription()'. The method is completely non-localizable. The
> method should be defined to either return a resource pack thingy or
> take a Locale.
I've seen. Right. You have already a comment there.
> >> > > - - 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 BridgeExtension allows
> >> for multiple registrations (the Batik Extensions do this:
> >> batik.extension.svg.BatikBridgeExtension.
> TK> I've seen, but this is not the problem. My problem is, that I
> TK> write a JAITranscoder, which uses the the encoders from JAI. These
> TK> have descriptors. But these don't give me enough informations. I
> TK> have to set Rendering Hints and others, partly specific to
> TK> them.
> I guess it's not clear to me where/when you get enough information
> to be able to know what format specific hints to provide.
What I'm planning is, to have this information in my TranscoderRegistration,
provided by the Transcoder or his Descriptor. This information will be used
to let applications create dialogs or command line options for these hints.
Then, the transcoder can access these hints.
> So if you
> have this specific hints stuff 'hard coded' in your class then you are
> 'expecting' support for this format so you can register it.
Yes and no. They are hardcoded in the JAI Encoders or in the case of imageio,
in the ImageWriteParam or a subclass of this. They are provided as methods
beginning with "set" there (e.g. setCompressionMode). The standard one for
the specific interface (JAI or ImageIO) will have descriptions, the others
can't have those because they are read out of the class.
> In the
> cases where you don't know anything about the format (no 'hard coded'
> information) then they are all equivilent as far as anyone is
> concerned, so you could just register once.
As the different encoders I use have different parameters, I have to provide
different hint's. So I have to register more than once. Also the informations
like file extension's and mime-type's are different.
> (BTW I don't have any
> strong feelings around this I just feel like I'm missing something,
> and I'm trying to see what it is).
Hope this mail helps. I'm currently writing all mails together. Hope this
helps again more.
> TK> And as far as I can see, the only way is to look into the classes
> TK> for set.* Methods. Another problem I have to solve is, that the
> TK> color depth has to be adjusted. For this, sometimes the pictures/
> TK> drawings have to be dithered or scaled with a praticable
> TK> algorithm. This can't be static, as it depends on the picture/
> TK> drawing. So this has to be put in Transcoder Hints.
> Well there is a start to this for the PNG encoder. It currently
> only uses the JDK dithering alg (and it creates a colormap with
> a simple median cut alg).
I've seen. I also have begun this for wbmp. My problem now is the
configuration. There are to many ways for conversion. E.G. JAI is very
powerful there. Theoretically I could handle embedded images different to
drawings. I think I will use simple dithering first and add other things
later. First I'd like to have a usable version and the
TranscoderRegistration. Extending this all later shouldn't be a problem.
> TK> With the mails I got upto now, I'll write a summary mail with
> TK> concrete interface's, packages needed etc. I hope I don't forget
> TK> any ideas.
> Sounds great.
I'm currently wrting at it.
With kind regards
Torsten Knodt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9c0hAvxZktkzSmiwRAkBJAKCCHvpBsoRC7mlUiMpr6Erhmf1MpACgi/3D
YQeWyEkTbC1rJjv0mXif0wg=
=YRL/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
