>>>>> "TK" == Torsten Knodt <[EMAIL PROTECTED]> writes:

>> 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).  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.

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

>> > > - - 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.  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.  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. (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).

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).

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to