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: Integration of TIFFRenderer in FOP
Glen Mazza wrote: Yeah, Peter makes me want to do that sometimes myself... ;) Glen Glen, It's not difficult. I can give you some tips off-line if you like. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Integration of TIFFRenderer in FOP
Jeremias Maerki wrote: Relationship to which PDF renderer? The one that directly creates PDF (PDFRenderer) or the one that creates PDF through JPS (normal PrintRenderer as defined in the Wiki painting to a Graphics2D instance provided by JPS) using a StreamPrintService? That's the two choices. Obviously, you will be taking the latter approach. If you wait a bit (until the common components area is set up) you'll have a neatly separated package to create PDF using JPS because I'll be publishing my proof-of-concept JPS StreamPrintService which you can build on. Hmm, this gives me another thing to talk about over in XML Graphics General. On 09.03.2005 00:53:16 Peter B. West wrote: This approach is obviously of interest to me, and I will follow developments closely. The wiki page is very general. If the Java2DRenderer is to be the (abstract) technical foundation, what will the relationship to the concrete PDF renderer be? The wiki is vague on this point. Jeremias, That will be extremely useful. However, I was trying to clarify the situation of PDFRenderer. The impression I got from Renaud's comment was that the Java2DRenderer was to be the basis of all renderers. Hence my interest. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Integration of TIFFRenderer in FOP
Peter, Then my comment gave you a wrong impression: the Java2DRenderer is the (abstract) base for all renderers that use the Java2D API for rendering. The reference renderer is still the PDFRenderer, which inherits from AbstractRenderer directly. Renaud
Re: Integration of TIFFRenderer in FOP
No, definitely not. From what I learned from you, that's what you intend to do. FOP pursues a different strategy. I believe that you can't get the same quality PDF with all cool features with a PDF renderer that operates with a Java2DRenderer as its base. On 09.03.2005 12:34:20 Peter B. West wrote: That will be extremely useful. However, I was trying to clarify the situation of PDFRenderer. The impression I got from Renaud's comment was that the Java2DRenderer was to be the basis of all renderers. Hence my interest. 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: Integration of TIFFRenderer in FOP
Renaud Richardet wrote: Peter, Then my comment gave you a wrong impression: the Java2DRenderer is the (abstract) base for all renderers that use the Java2D API for rendering. The reference renderer is still the PDFRenderer, which inherits from AbstractRenderer directly. Renaud Renaud, Understood. 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
Integration of TIFFRenderer in FOP
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
Re: Integration of TIFFRenderer in FOP
On Mar 8, 2005, at 7:23 AM, Renaud Richardet wrote: snip 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. snip I think that would be great! Just be careful when you do, that the output isn't restricted to 72-dpi (IIRC, I had some problems in the past when i tried to use Oleg's TIFFRenderer--I ended up using ImageMagick to complete my task). Cheers! Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: Integration of TIFFRenderer in FOP
Renaud Richardet wrote: 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. Unfortunately I'm sort of busy currently. Go ahead, that will be great renderer. -- Oleg Tkachenko http://blog.tkachenko.com Multiconn Technologies, Israel
Re: Integration of TIFFRenderer in FOP
Renaud Richardet 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 Renaud, This approach is obviously of interest to me, and I will follow developments closely. The wiki page is very general. If the Java2DRenderer is to be the (abstract) technical foundation, what will the relationship to the concrete PDF renderer be? The wiki is vague on this point. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Integration of TIFFRenderer in FOP
How to leave this group. Please help me to unsubscribe. --- Peter B. West [EMAIL PROTECTED] wrote: Renaud Richardet 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 Renaud, This approach is obviously of interest to me, and I will follow developments closely. The wiki page is very general. If the Java2DRenderer is to be the (abstract) technical foundation, what will the relationship to the concrete PDF renderer be? The wiki is vague on this point. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
Re: Integration of TIFFRenderer in FOP
Send an e-mail to: [EMAIL PROTECTED] Be sure to use the e-mail address from which you subscribed. On Mar 8, 2005, at 4:03 PM, vivek gupta wrote: How to leave this group. Please help me to unsubscribe. --- Peter B. West [EMAIL PROTECTED] wrote: Renaud Richardet 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 Renaud, This approach is obviously of interest to me, and I will follow developments closely. The wiki page is very general. If the Java2DRenderer is to be the (abstract) technical foundation, what will the relationship to the concrete PDF renderer be? The wiki is vague on this point. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
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
Re: Integration of TIFFRenderer in FOP
Yeah, Peter makes me want to do that sometimes myself... ;) Glen --- vivek gupta [EMAIL PROTECTED] wrote: How to leave this group. Please help me to unsubscribe. --- Peter B. West [EMAIL PROTECTED] wrote: Renaud Richardet 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 Renaud, This approach is obviously of interest to me, and I will follow developments closely. The wiki page is very general. If the Java2DRenderer is to be the (abstract) technical foundation, what will the relationship to the concrete PDF renderer be? The wiki is vague on this point. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
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: Integration of TIFFRenderer in FOP
Relationship to which PDF renderer? The one that directly creates PDF (PDFRenderer) or the one that creates PDF through JPS (normal PrintRenderer as defined in the Wiki painting to a Graphics2D instance provided by JPS) using a StreamPrintService? That's the two choices. Obviously, you will be taking the latter approach. If you wait a bit (until the common components area is set up) you'll have a neatly separated package to create PDF using JPS because I'll be publishing my proof-of-concept JPS StreamPrintService which you can build on. Hmm, this gives me another thing to talk about over in XML Graphics General. On 09.03.2005 00:53:16 Peter B. West wrote: This approach is obviously of interest to me, and I will follow developments closely. The wiki page is very general. If the Java2DRenderer is to be the (abstract) technical foundation, what will the relationship to the concrete PDF renderer be? The wiki is vague on this point. Jeremias Maerki
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