That's no problem, I think, because Batik has a TIFF encoder [3] already in their codebase and we can move this code to the common area and use that. Shouldn't be difficult to adjust.
Otherwise, I'd rather use ImageIO even if it's only available in JDKs >=1.4. [3] http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/ On 09.03.2005 11:30:51 Oleg Tkachenko wrote: > Jeremias Maerki wrote: > > > Thanks to Glen for raising the issue. The ideal approach is if Oleg > > would pack up his TIFFRenderer and donate it to the ASF accompanied with > > a software grant [1], but Oleg is a FOP committer and has a CLA on file. > > So if Oleg attaches a ZIP with the sources for the TIFFRenderer (ALv2 > > already applied) to a Bugzilla entry along with a note that we may > > include it in FOP, that's good enough for me. It's not that the thing is > > a big application in itself even though some people would argue works > > like Renaud's AWT patch and Oleg's TIFFRenderer must go/run through the > > Incubator. > > To make things even more complicated, TIFFRenderer is just a thin > wrapper around some weird licensed [1] Sun's codec sources, called "Java > Advanced Imaging API 1.1.1 Sample Source" [2], which includes some > provisional bits of JAI. I'm not sure if we want to use it. What about > using full-blown JAI? > > [1] > http://www.tkachenko.com/fop/JAI_1.1.1_sample_io_sourcecodelic.10_23_01.txt > [2] http://java.sun.com/developer/sampsource/jai/ > -- > Oleg Tkachenko > http://blog.tkachenko.com > Multiconn Technologies, Israel Jeremias Maerki
