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: Skype-conference on page-breaking?
Sounds to me like 2) is the way to go right now. This would mean minimal recreation of vertical boxes in case of changing available IPD. Sure, this is an exotic case but XSL-FO makes it possible, therefore we must be prepared for it. Thanks for the hints and the helpful example. On 08.03.2005 19:43:57 Luca Furini wrote: Jeremias Maerki wrote: Luca, do you think your total-fit approach may be written in a way to handle changing available IPDs and that look-ahead can be disabled to improve processing speed at the cost of optimal break decisions? I think that a first fit algorithm could be implemented in two different ways: 1) wait until the list of elements representing a whole page-sequence is collected, and call findBreakingPoints(); this method will call a different considerLegalBreak() method, much simpler and faster than the knuth's one. 2) start building pages little by little: the FlowLM returns elements to the PageLM as soon as one of its own child returns them Alternative 1) is much like the total fit algorithm: breaks are computed at the end of each page-sequence; even if the evaluation method is much faster than Knuth's one, there could still be a long wait in order to get the whole list. With alternative 2) the PageLM would behave much the same as it now does: as soon as a page is filled, it is possible to call addAreas. Note that the last elements in the partial sequence cannot be considered as feasible break. For example, if there is a block which creates 6 lines, the sequence will be something like: box box penalty(not infinite) box penalty(not infinite) box box and the evaluation must stop at the second penalty; only when some following elements are known it will be possible to decide whether the last two lines could be at the end of a page. If the IPD is always the same, I think the two alternatives are equivalent, and the first one is better because it just needs a different considerLegalBreak() method; as the output file cannot be printed until the end of the process, the only advantage of 2) could be memory usage. That's the part where I have a big question mark about changing available IPD. We may have to have a check that figures out if the available IPD changes within a page-sequence by inspecting the page-masters. That would allow us to switch automatically between total-fit and best-fit or maybe even first-fit. If the IPD changes, I fear 2) must be necessarily used: if a block is split between pages with different ipd, only a few lines need to be recreated. Using 1), the LineLM should know how wide the lines are, but this cannot be known as page breaking has not yet started. The check could be done before starting the layout phase: if there is a change, 2) is used, otherwise 1). Maybe, the check could be even more sophisticated: for example, if the first page is different, but the following are equally wide, we could use 2) to create the first page and then switch to 1). A remaining question mark is with side-floats as they influence the available IPD on a line-to-line basis. This is a question mark for me too! :-) One thing for a deluxe strategy for book-style documents is certainly alignment of lines between facing pages. But that's something that's not important at the moment. I have created and implemented a new property right about this! :-) I'd be very interested to hear what you think about the difficulty of changing available IPD. The more I think about it, however, the more I think the total-fit model gets too complicated for what we/I need right now. But I'm unsure here. If changing ipd is really important and not just a theorical possibility, we could start implementing 2, and later add the check and the algorithm 1: the getNextKnuthElements() in the block-level LM could be used in both cases. Regards Luca 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: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java
--- Jeremias Maerki [EMAIL PROTECTED] wrote: RFC 2045 [1] says this: (1) Private values (starting with X-) may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or standardized. So to be on the safe side we would need to rename application/awt to application/X-awt. Sounds good--and acceptable for purists as well. Glen [1] http://www.faqs.org/rfcs/rfc2045.html
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
