Getting rid of JIMI

[Dalibor Topic <ro...@kaffe.org>]

Hi,

I was looking into getting FOP to run with kaffe[1] recently[2][3], and 
decided to have another look at it today, after gettig maven to run with 
kaffe. I tried to generate DocBook docuemntation for another package, 
and the Maven sdocbook plugin insisted on fetching jimi.jar from Sun.

So I'm wondering whether there is any need for JIMI any more in current 
FOP CVS sources, i.e. if PNG image handling is now being done within FOP 
internally?

If that's not the case, would it be possible to use the LGPLd code from 
http://catcode.com/pngencoder/ and http://www.sixlegs.com/software/png/ 
for the job, and dropping the dependency on JIMI completely?

If this is a FAQ, I'm sorry for wasting your time, I couldn't find an 
answer in the FAQs ...

cheers,
dalibor topic

[1] A free software runtime for java programs, see http://www.kaffe.org
[2] http://www.mail-archive.com/kaffe@kaffe.org/msg04038.html
[3] http://www.mail-archive.com/kaffe@kaffe.org/msg04023.html

Re: Getting rid of JIMI

[Jeremias Maerki <de...@greenmail.ch>]

No apologies required!

Image IO (javax.imageio) support is not there, yet, I'm afraid. But if
you created an implementation for Image IO then your idea would work.
Shouldn't be very hard. Check the org.apache.fop.image package. You
wouldn't need to use JIMI. Think of JIMI, JAI and ImageIO as equals.
They all provide an API to access bitmap images.


On 23.01.2004 16:08:55 Dalibor Topic wrote:
> > A possible work-around is to establish a better plug-in concept for our
> > image lib adapters in HEAD (not 0.20.5) so interested parties can create
> > plug-ins outside of the ASF to use LGPL libraries.
> 
> I'm not very well aware of the differences between all the different 
> image io APIs, so please excuse me if my next question is a typical 
> newbie question. If, for example, we had javax.imageio support working 
> for PNG images in GNU Classpath (and Kaffe), would/could FOP 
> automatically use that, or would it still need to use JIMI?
> 
> The reasoning behind this being that PNG image support seems to be part 
> of JDK 1.4 anyway, so it will be implemented in free runtimes eventually 
> as well.


Jeremias Maerki

Re: Getting rid of JIMI

[Dalibor Topic <ro...@kaffe.org>]

Hi Jeremias,

thanks for the quick response.

Jeremias Maerki wrote:
> The ASF does see a problem. Until the FSF has clarified the relationship
> between "linking" and Java's import concept the ASF's policy is not to
> allow usage of LGPL packages. There are certain exceptions. For example,
> if you have a JAI-compatible image codec under the LPGL you could use it
> because FOP would directly link only with the JAI API, not with the
> codec that's made available through JAI.
> 
> See also:
> http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing

Thanks a lot for the link! That was precisely the sort of information I 
was looking for.

> A possible work-around is to establish a better plug-in concept for our
> image lib adapters in HEAD (not 0.20.5) so interested parties can create
> plug-ins outside of the ASF to use LGPL libraries.

I'm not very well aware of the differences between all the different 
image io APIs, so please excuse me if my next question is a typical 
newbie question. If, for example, we had javax.imageio support working 
for PNG images in GNU Classpath (and Kaffe), would/could FOP 
automatically use that, or would it still need to use JIMI?

The reasoning behind this being that PNG image support seems to be part 
of JDK 1.4 anyway, so it will be implemented in free runtimes eventually 
as well.

cheers,
dalibor topic

Re: Getting rid of JIMI

[Jeremias Maerki <de...@greenmail.ch>]

The ASF does see a problem. Until the FSF has clarified the relationship
between "linking" and Java's import concept the ASF's policy is not to
allow usage of LGPL packages. There are certain exceptions. For example,
if you have a JAI-compatible image codec under the LPGL you could use it
because FOP would directly link only with the JAI API, not with the
codec that's made available through JAI.

See also:
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing

I think it's no problem if you modify your copy of FOP to use one of the
LGPL packages. The ASF simply cannot publish code that uses these
packages at the moment.

A possible work-around is to establish a better plug-in concept for our
image lib adapters in HEAD (not 0.20.5) so interested parties can create
plug-ins outside of the ASF to use LGPL libraries.

On 23.01.2004 00:19:28 Dalibor Topic wrote:
> While I understand that GPL2 and ASL 1.1 are not compatible, I don't see 
> a problem with LGPL 2.1 and ASL 1.1. Could you elaborate?


Jeremias Maerki

Re: Getting rid of JIMI

[Dalibor Topic <ro...@kaffe.org>]

Hi Glen,

thanks for the quick reply.

Glen Mazza wrote:
> --- Dalibor Topic <ro...@kaffe.org> wrote:
> 
>>If that's not the case, would it be possible to use
>>the LGPLd code from 
>>http://catcode.com/pngencoder/ and
>>http://www.sixlegs.com/software/png/ 
>>for the job, and dropping the dependency on JIMI
>>completely?
>>
> 
> 
> No, (L)GPL and the Apache licenses are not compatible.

While I understand that GPL2 and ASL 1.1 are not compatible, I don't see 
a problem with LGPL 2.1 and ASL 1.1. Could you elaborate?

cheers,
dalibor topic

Re: Getting rid of JIMI

[Glen Mazza <gr...@yahoo.com>]

--- Dalibor Topic <ro...@kaffe.org> wrote:
> If that's not the case, would it be possible to use
> the LGPLd code from 
> http://catcode.com/pngencoder/ and
> http://www.sixlegs.com/software/png/ 
> for the job, and dropping the dependency on JIMI
> completely?
> 

No, (L)GPL and the Apache licenses are not compatible.

Glen

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/