Re: Good job! / Re: Integration of TIFFRenderer in FOP
Let me sum up this tread to see if I get the picture: * Sun's codec [1] will not be integrated. * instead, Batik's transcoders will be used [2]. * where and how these transcoders will be made available to fop will be discussed next week [3] * I'll start by implementing basic functionalities for TIFF and PNG using Batik's codecs. This will be 1.3 compilant. I should be able to use the actual codecs without modifications. * aditional functionalities (like TIFF compressions) will be added via the Java Image I/O (needs Java 1.4) or via JAI.Those additional functionalities will be stored in a separate directory (src/java-1.4). * an alternative would be to create|integrate these functionalities in the Batik code. * I should check that the output isn't restricted to 72-dpi [4] Any input to tell me if these assertions are true is welcome. Regards, Renaud [1] http://java.sun.com/developer/sampsource/jai/ [2] http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/ [3] http://mail-archives.eu.apache.org/mod_mbox/xmlgraphics-general/200503.mbox/[EMAIL PROTECTED] [4] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=10756
Re: Good job! / Re: Integration of TIFFRenderer in FOP
That's all correct although the third point does not really have anything to do with the bitmap renderer. On 10.03.2005 14:34:57 Renaud Richardet wrote: Let me sum up this tread to see if I get the picture: * Sun's codec [1] will not be integrated. * instead, Batik's transcoders will be used [2]. * where and how these transcoders will be made available to fop will be discussed next week [3] * I'll start by implementing basic functionalities for TIFF and PNG using Batik's codecs. This will be 1.3 compilant. I should be able to use the actual codecs without modifications. * aditional functionalities (like TIFF compressions) will be added via the Java Image I/O (needs Java 1.4) or via JAI.Those additional functionalities will be stored in a separate directory (src/java-1.4). * an alternative would be to create|integrate these functionalities in the Batik code. * I should check that the output isn't restricted to 72-dpi [4] Any input to tell me if these assertions are true is welcome. Regards, Renaud [1] http://java.sun.com/developer/sampsource/jai/ [2] http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/ [3] http://mail-archives.eu.apache.org/mod_mbox/xmlgraphics-general/200503.mbox/[EMAIL PROTECTED] [4] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=10756 Jeremias Maerki
Re: Good job! / Re: Integration of TIFFRenderer in FOP
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
Re: Good job! / Re: Integration of TIFFRenderer in FOP
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
Re: Good job! / Re: Integration of TIFFRenderer in FOP
Renaud Richardet wrote: Peter, let me answer you last mail [1] here: You are right that the wiki is still vague about the detailled implementation of the different renderers. Actually, I haven't started to think about it until today. I will put my ideas tomorrow on the wiki. I would be happy if you could put your inputs there, too. Renaud, I don't have particular input. I haven't given the rendering any detailed thought at all, apart from the perception fostered by the presence of PDFGraphics2D, PDFGraphicsConfiguration, PDFGraphicsDevice and similar classes in other contexts, that a mapping of the Area tree to Java Graphics2D output could be translated very directly into PDF (and other formats). If that necessarily involves the JPS, so be it. In order to flesh these notions out, I will be taking maximum advantage of the expertise of others, including yourself. In the meantime, I continue to work on the generation of the Area tree. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Good job! / Re: Integration of TIFFRenderer in FOP
I downloaded sun's codecs [2] that Oleg used in his TIFFRenderer. Jeremias, you mean that we can legally just put those in the FOP-code? Following codecs are included in [2]: - TIFF - JPEG - PNG - BMP So it should be possible to create a renderer for each of this file formats. But do we need them all? Do we also need GIF encoding ([2] only supports GIF decoding) . If yes, we'll have to use other libraries like ACME Labs GIF encoder (right?) Besides, I haven't understand yet if Oleg will donate his code to Apache. Otherwise, I'd rather use ImageIO even if it's only available in JDKs =1.4. I thought FOP should be 1.3 compilant [3]? So how do we go around that? Regards, Renaud [3] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1332332
Re: Good job! / Re: Integration of TIFFRenderer in FOP
On 09.03.2005 12:51:11 Renaud Richardet wrote: I downloaded sun's codecs [2] that Oleg used in his TIFFRenderer. Jeremias, you mean that we can legally just put those in the FOP-code? This would have to be checked out. I'd rather not, especially when we have PNG and TIFF codecs under Apache license already available. Following codecs are included in [2]: - TIFF - JPEG - PNG - BMP So it should be possible to create a renderer for each of this file formats. But do we need them all? Do we also need GIF encoding ([2] only supports GIF decoding) . If yes, we'll have to use other libraries like ACME Labs GIF encoder (right?) I would like to suggest that you implement TIFF and PNG output using Batik's codecs. Besides, I haven't understand yet if Oleg will donate his code to Apache. I have the impression that he wants to. There are simply a few issues to look at. Looking at possible licensing issue I'd suggest Oleg simply donates his own classes (not the codec) to the FOP project by applying the Apache license and posting them as a Bugzilla issue. You can then use these classes to implement output via Batik's codecs. Or you simply reimplement the same functionality without copy/paste. :-) As he said, it's only a thin wrapper. The key is to have codecs with the right licensing. Otherwise, I'd rather use ImageIO even if it's only available in JDKs =1.4. I thought FOP should be 1.3 compilant [3]? So how do we go around that? That's right. But nothing stops us from providing additional code that's JDK 1.4 dependent as long as it's not core functionality and it's in a separate directory (src/java-1.4). Regards, Renaud [3] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1332332 Jeremias Maerki
Re: Good job! / Re: Integration of TIFFRenderer in FOP
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Otherwise, I'd rather use ImageIO even if it's only available in JDKs =1.4. I thought FOP should be 1.3 compilant [3]? So how do we go around that? That's right. But nothing stops us from providing additional code that's JDK 1.4 dependent as long as it's not core functionality and it's in a separate directory (src/java-1.4). BTW, does it have to be in a separate directory? Can we keep it in the directory it would otherwise be in if FOP were 1.4-based but somehow alter the Ant scripts to help the 1.3-only users? Glen
Re: Good job! / Re: Integration of TIFFRenderer in FOP
Jeremias Maerki wrote: 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. Last time I checked Batik's TIFF encoder was kinda limited WRT some TIFF compressions, and that's the reason I used the codec from Sun. That would be really nice to fix Batik's codec instead. -- Oleg Tkachenko http://blog.tkachenko.com Multiconn Technologies, Israel
Re: Good job! / Re: Integration of TIFFRenderer in FOP
Jeremias Maerki wrote: I would like to suggest that you implement TIFF and PNG output using Batik's codecs. Yep, that's the best solution. But please check that Batik's TIFF codec supports all TIFF compressions Sun's codec does. 2 years ago it was sort of limited, particularly wrt fax compressions. I have the impression that he wants to. There are simply a few issues to look at. Looking at possible licensing issue I'd suggest Oleg simply donates his own classes (not the codec) to the FOP project by applying the Apache license and posting them as a Bugzilla issue. Ok, I will anyway, just to be at least a bit helpful here :) -- Oleg Tkachenko http://blog.tkachenko.com Multiconn Technologies, Israel
Re: Good job! / Re: Integration of TIFFRenderer in FOP
Yes, please, because it's a lot easier to handle inside an IDE. You simply define an additional source folder if you're on JDK 1.4, and you don't get compile error on JDK 1.3. On 09.03.2005 16:34:39 Glen Mazza wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: Otherwise, I'd rather use ImageIO even if it's only available in JDKs =1.4. I thought FOP should be 1.3 compilant [3]? So how do we go around that? That's right. But nothing stops us from providing additional code that's JDK 1.4 dependent as long as it's not core functionality and it's in a separate directory (src/java-1.4). BTW, does it have to be in a separate directory? Can we keep it in the directory it would otherwise be in if FOP were 1.4-based but somehow alter the Ant scripts to help the 1.3-only users? Glen Jeremias Maerki
Re: Good job! / Re: Integration of TIFFRenderer in FOP
Ah, there's the catch. Yes, CCITT4 is particularly interesting which is not supported by the code in Batik. But still, I think we don't have to support everything under JDK 1.3. I wonder how many people under JDK 1.3 would need that particular compression type. And if they really do they then have several examples on how to adjust the bitmap renderer for themselves. And a additional JAI implementation is certainly not a big deal after we have the first one. On 09.03.2005 16:38:33 Oleg Tkachenko wrote: Jeremias Maerki wrote: 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. Last time I checked Batik's TIFF encoder was kinda limited WRT some TIFF compressions, and that's the reason I used the codec from Sun. That would be really nice to fix Batik's codec instead. Jeremias Maerki
Re: Good job! / Re: Integration of TIFFRenderer in FOP
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Ah, there's the catch. Yes, CCITT4 is particularly interesting which is not supported by the code in Batik. But still, I think we don't have to I don't think we have to support everything under JDK 1.3. Or anything, for that matter. 1.3 users can remain on 0.20.5 IMO, optionally downloading Oleg's TIFF patch if they need to. Glen
Re: Good job! / Re: Integration of TIFFRenderer in FOP
Le 9 mars 05, à 01:12, Glen Mazza a écrit : ...[Thanks also to Bertrand for sending Renaud our way. This is the second quality developer--Peter Herweg being the other--that we have gotten from him since I've been on this project.].. You're welcome - and you don't even know how many people I sent your way that did not make it ;-) (just kidding - I'm happy to contribute, even if it's just helping convince people to jump in) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Good job! / Re: Integration of TIFFRenderer in FOP
Team, Oleg's TIFF Renderer is under the Mozilla license[1], not the Apache one (also apparently some of the code is from Sun?). Is the former compatible with the latter? If not, I would like Oleg to switch the license on it before we proceed further in putting it into FOP. Renaud--thanks for your fantastic work with the AWT Renderer. You clearly have ace technical skills, enthusiasm, organization, and you write beautifully. You have a bright future ahead of you. [Thanks also to Bertrand for sending Renaud our way. This is the second quality developer--Peter Herweg being the other--that we have gotten from him since I've been on this project.] Regards, Glen [1] http://www.tkachenko.com/fop/tiffrenderer.html --- Renaud Richardet [EMAIL PROTECTED] wrote: Oleg, I'm currently working on the AWTRenderer. The basic idea is to create a Java2DRenderer which provides the (abstract) technical foundation. Other renderers can subclass Java2DRenderer and provide the concrete output paths [1]. I think it would be a good idea to integrate your TIFFRenderer, as you propose in [2]. Would you like to integrate it yourself? Otherwise I would like to do it. Regards, Renaud [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D [2] http://www.tkachenko.com/fop/fop.html
Good job! / Re: Integration of TIFFRenderer in FOP
Glen, Thanks for your mail. It's good you raised the legal issue. Peter, let me answer you last mail [1] here: You are right that the wiki is still vague about the detailled implementation of the different renderers. Actually, I haven't started to think about it until today. I will put my ideas tomorrow on the wiki. I would be happy if you could put your inputs there, too. Regards, Renaud [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=10759 -- renaud.richardet (at) gmail (dot) com +41 78 675 9501 www.oslutions.com
Re: Good job! / Re: Integration of TIFFRenderer in FOP
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. [1] http://www.apache.org/licenses/#grants On 09.03.2005 01:12:05 Glen Mazza wrote: Team, Oleg's TIFF Renderer is under the Mozilla license[1], not the Apache one (also apparently some of the code is from Sun?). Is the former compatible with the latter? If not, I would like Oleg to switch the license on it before we proceed further in putting it into FOP. Renaud--thanks for your fantastic work with the AWT Renderer. You clearly have ace technical skills, enthusiasm, organization, and you write beautifully. You have a bright future ahead of you. [Thanks also to Bertrand for sending Renaud our way. This is the second quality developer--Peter Herweg being the other--that we have gotten from him since I've been on this project.] Regards, Glen [1] http://www.tkachenko.com/fop/tiffrenderer.html --- Renaud Richardet [EMAIL PROTECTED] wrote: Oleg, I'm currently working on the AWTRenderer. The basic idea is to create a Java2DRenderer which provides the (abstract) technical foundation. Other renderers can subclass Java2DRenderer and provide the concrete output paths [1]. I think it would be a good idea to integrate your TIFFRenderer, as you propose in [2]. Would you like to integrate it yourself? Otherwise I would like to do it. Regards, Renaud [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D [2] http://www.tkachenko.com/fop/fop.html Jeremias Maerki
