Re: Getting rid of JIMI
Very classy response. (You're getting good at knowing how to handle me... ;-) Glen --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Noted. I will make it a point in the proposal so the > Batik people will > be able to comment and we can develop mechnisms to > ensure quality. > > On 25.01.2004 18:42:20 Glen Mazza wrote: > > The current (lowered) committer standards on the > FOP > > team definitely needs to be explained to the Batik > > team before we get write access to their > > project--something I'm still far from > recommending. > > Jeremias, being perhaps the leading proponent of > the > > new committer standards, is probably in the best > > position to explain this to Thomas--I still don't > > understand it myself. > > > Jeremias Maerki > __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Re: Getting rid of JIMI
Noted. I will make it a point in the proposal so the Batik people will be able to comment and we can develop mechnisms to ensure quality. On 25.01.2004 18:42:20 Glen Mazza wrote: > The current (lowered) committer standards on the FOP > team definitely needs to be explained to the Batik > team before we get write access to their > project--something I'm still far from recommending. > Jeremias, being perhaps the leading proponent of the > new committer standards, is probably in the best > position to explain this to Thomas--I still don't > understand it myself. Jeremias Maerki
Re: Getting rid of JIMI
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > I will probably have some time next month to write a > proposal on how our > two projects can move closer together to make the > code sharing happen. > > Jeremias Maerki > Ummm...Jeremias, remember, your recent nominations for FOP committers included those who don't even know Java [1][2] and haven't submitted any code patches (and barely any--*if* any--doc patches at that.) Per you and Joerg's new standards, to be a committer on the FOP team, just being helpful on the mailing lists suffices.[3] The Batik team, like Xalan, Struts, HTTPD, and other successful projects, however, still keeps programmatic committer standards and pretty high ones at that. (Take a look at the solid backgrounds of the Batik committers [4], for example.) To protect their user base and their excellent products, they don't gratuitously (and dangerously) hand out write access to people as tokens of appreciation. If you and Joerg want to insist on committers who haven't even learned CVS and Ant yet, then interfacing with other teams is going to be problematic, if only for the safety of their code. I wish you had both thought out the consequences beforehand (I certainly didn't appreciate being made into the "mean one" on this issue)--regardless, the Batik team should be aware of this issue. The current (lowered) committer standards on the FOP team definitely needs to be explained to the Batik team before we get write access to their project--something I'm still far from recommending. Jeremias, being perhaps the leading proponent of the new committer standards, is probably in the best position to explain this to Thomas--I still don't understand it myself. Glen [1] http://marc.theaimsgroup.com/?l=fop-dev&m=106640132114490&w=2 [2] http://marc.theaimsgroup.com/?l=fop-dev&m=107262232610618&w=2 [3] http://marc.theaimsgroup.com/?l=fop-dev&m=107271927618049&w=2 [4] http://xml.apache.org/batik/whoAreWe.html __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Re: Getting rid of JIMI
Jeremias Maerki wrote: I will probably have some time next month to write a proposal on how our two projects can move closer together to make the code sharing happen. Stuff that comes to mind immediately: - fonts, metrics, character and word width - various configuration stuff - character normalization and line breaking (for SVG flow text) - command line wrapper - common area rendering - embedded images, of course - API concerns, as discussed: hooks for custom resolvers for fonts, images, URLs in general J.Pietschmann
Re: Getting rid of JIMI
On 25.01.2004 12:46:08 Thomas DeWeese wrote: > Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > > Damn, you're right. I wonder why we haven't made use of this, yet. BTW, > > is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF > > renderer) or is this separately developed code (ASF origin)? > > This was contributed by Sun and is I believe the code came > from JAI (great group of guys). There have been some bug > fixes/improvements since then but it is basically that code. > > > You know that there's a number of people who would actually be > > interested in creating/having a BSD-style image (codec) library? > >Sure, but given imageio does it make sense to put a lot of > effort into an independent codec library? If I were going to > create a codec library I would create one that plugged into > image-io. I agree that the codec library should plug into ImageIO, but this API is only available since JDK 1.4. I'm sure that if there's enough interest in supporting the image library under pre-1.4 JDKs there will be contributions to make that happen. No need to lose too much time if it's not needed at first. > > I think that should be one of the packages that should be separated > > out, when FOP and Batik get closer together. > > This probably makes sense. I will probably have some time next month to write a proposal on how our two projects can move closer together to make the code sharing happen. Jeremias Maerki
RE: Getting rid of JIMI
Jeremias Maerki <[EMAIL PROTECTED]> wrote: Damn, you're right. I wonder why we haven't made use of this, yet. BTW, is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF renderer) or is this separately developed code (ASF origin)? This was contributed by Sun and is I believe the code came from JAI (great group of guys). There have been some bug fixes/improvements since then but it is basically that code. You know that there's a number of people who would actually be interested in creating/having a BSD-style image (codec) library? Sure, but given imageio does it make sense to put a lot of effort into an independent codec library? If I were going to create a codec library I would create one that plugged into image-io. I think that should be one of the packages that should be separated out, when FOP and Batik get closer together. This probably makes sense. On 24.01.2004 12:21:48 Thomas DeWeese wrote: It is certainly true that javax.imageio is the direction to go in the future. However, It is probably worth pointing out that you already include a PNG encoder/decoder with the FOP distribution, from Batik! org.apache.batik.ext.awt.image.codec.PNGImageEncoder org.apache.batik.ext.awt.image.codec.PNGImageDecoder Let me know if you want/need more info (including pointers to where FOP does the image loading would be helpful as well).
Re: Getting Rid of Jimi
Damn, you're right. I wonder why we haven't made use of this, yet. BTW, is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF renderer) or is this separately developed code (ASF origin)? You know that there's a number of people who would actually be interested in creating/having a BSD-style image (codec) library? I think that should be one of the packages that should be separated out, when FOP and Batik get closer together. On 24.01.2004 12:21:48 Thomas DeWeese wrote: > It is certainly true that javax.imageio is the direction > to go in the future. > > However, It is probably worth pointing out that you already > include a PNG encoder/decoder with the FOP distribution, > from Batik! > > org.apache.batik.ext.awt.image.codec.PNGImageEncoder > org.apache.batik.ext.awt.image.codec.PNGImageDecoder > > > Let me know if you want/need more info (including pointers > to where FOP does the image loading would be helpful as well). Jeremias Maerki
Re: Getting rid of JIMI
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
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
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
Hi Glen, thanks for the quick reply. Glen Mazza wrote: --- Dalibor Topic <[EMAIL PROTECTED]> 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
--- Dalibor Topic <[EMAIL PROTECTED]> 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/
