Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
On 08.03.2005 03:18:21 Renaud Richardet wrote: snip/ On Mon, 28 Feb 2005 , Jeremias Maerki wrote: AbstractRenderer: I moved what I could reuse from PDFRenderer to AbstractRenderer: renderTextDecorations(), handleRegionTraits(), and added the needed empty methods. I think that was good although only time will tell if this will hold for all renderers to come. Eventually, I didn't modify AbstractRenderer, PDFRenderer and PS Renderer at all. The implementation of AWTRenderer is close to the other renderers, so that putting some methods in AbstractRenderer should not be a big problem. I agree. Speaking of startVParea(), could we rename it to something more meanigfull? Proposition: TransformPosition, or something like this. Actually, I like startVParea() (or rather startViewportArea like I would rather call it) because only for viewport a new transformation matrix is necessary. startViewportArea() is fine for me. I think the Java2D approach is not unlike the PDF/PS approach. Adobe was Sun's closest partner when they developed the Java2D API. I implemented a simple .bmp rendering (BMPReader.java). If there's a better way to render .bmp (JAI?), let me know. This should not be necessary. We have a BMP implementation in org.apache.fop.images. The BMP bitmaps should be loaded through that mechanism. OK, now I see. But how can I get an awt.Image from a FopImage? I've modified your patch to demonstrate, but it needs some additional work to handle the different color models. Probably the image package should be extended to provide the necessary information/methods. BTW, Using Graphics.create() you should be able to create a copy of the current Graphics2D object. By pushing the old one on a stack and overwriting the graphics member variable should should be able to create the same effect as with currentState.push()/saveGraphicsState() in PDFRenderer.startVParea () and currentState.pop()/restoreGraphicsState ()in endVParea(). When leaving a VP area you can simply restore an older Graphics2D object for the stack and continue painting. This will undo any transformations and state change done in the copy used within the VP area. See second paragraph in javadocs of java.awt.Graphics. Thanks for the hint. I did just that in AWTGraphicsState (same as PDFState). It holds all the context (font, colour, stroke, transformation) of the current graphics, and can act as a stack, too. I created an interface (RendererState) that could be implemented by all xxxState of the renderers. To be discussed... I moved the interface into the awt package for now since it contains Java2D-dependant methods and classes. I don't see right now how the other renderer would fit into the picture. The PDF renderer's state class is in the pdf package and should probably stay there. I also added a Debug button on the AWTRenderer-Windows, which outlines the blocks. This is just a test, and I would like to develop a full-fledged visual debugger [1]. That's an interesting feature. If this code works for you, then I'll start to separate the Java2DRenderer and the AWTRenderer. Otherwise, please tell me how I can improve my code. I liked the patch. It's a big step forward. Keep it up! Renaud [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D Jeremias Maerki
DO NOT REPLY [Bug 33760] - [Patch] current AWTRenderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33760. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33760 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 12:53 --- Patch applied with modifications. Thanks a lot! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
By the way, Renaud, you should sign and send an ICLA (Individual Contributor license agreement) to the ASF if you haven't done so already. http://www.apache.org/licenses/#clas Just so we're on the safe side. After all you're not just doing little bug fixes. Thanks! Jeremias Maerki
Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
Thanks for integrating my patch in FOP. But how can I get an awt.Image from a FopImage? I've modified your patch to demonstrate, but it needs some additional work to handle the different color models. Probably the image package should be extended to provide the necessary information/methods. OK, I've put that on my TODO-list. I created an interface (RendererState) that could be implemented by all xxxState of the renderers. To be discussed... I moved the interface into the awt package for now since it contains Java2D-dependant methods and classes. I don't see right now how the other renderer would fit into the picture. Neither do I right now, but I think it will come clearer in the future. The PDF renderer's state class is in the pdf package and should probably stay there. Yes, in any case. If this code works for you, then I'll start to separate the Java2DRenderer and the AWTRenderer. Otherwise, please tell me how I can improve my code. I liked the patch. It's a big step forward. Keep it up! /me happy By the way, Renaud, you should sign and send an ICLA (Individual Contributor license agreement) to the ASF if you haven't done so already. I just did it last week. Thanks for remembering me. Renaud
RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
Renaud Richardet wrote: 1. FOray has factored the FOP font logic into a separate module, cleaned it up significantly, and made some modest improvements. A few weeks ago, I aXSL-ized it as well, which means that it is written to a (theoretically) independent interface: http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-font/src/java/org /axsl/ font/ I think there is general support within FOP to implement the FOray/aXSL font work in the FOP 1.0 code, but so far no one has actually taken the time to do it. If you get into messing with fonts at all, I highly recommend that FOray be implemented before doing anything else. I will be happy to support efforts to that end. For what I understand now, your approach sounds good to me. But I'm missing some major pieces of the picture ATM to start implementing your aXSL interface in FOP. Please let me come back to you when I'll feel more comfortable with the font-mechanism. Sure. The main thing I wanted to alert you about is that right now, AFAIK, the HEAD code is pretty similar to the maintenance branch code and integration *should be* relatively easy. If improvements are made to the HEAD code, then issues of merging, etc. crop up that make integration difficult. That is OK too -- I just want to make sure that if it is done that way, it is done that way on purpose. Please feel free to contact me offline if you have implementation questions. Victor Mote
DO NOT REPLY [Bug 32612] - [PATCH] refactoring of knuth line breaking code.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32612. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32612 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 16:05 --- Applied. This was long due and it helps me while preparing for page breaking. Reference in the mailing list archives: http://marc.theaimsgroup.com/?t=11026228562r=1w=2 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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: Skype-conference on page-breaking?
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
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/
Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java
The application/awt MIME type doesn't exist. I think Jeremias wanted this to be null instead for output types that lack a MIME type, correct? Thanks, Glen --- [EMAIL PROTECTED] wrote: +/** The MIME type for AWT-Rendering */ public static final String MIME_TYPE = application/awt;
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: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java
No. It's quite ok like this. It is in line with my vision how renderers should be made available to FOP in the future (dynamic registration like the FOP extensions). It's clear that the AWT preview doesn't manifest a certain type of file that has an officially defined MIME type. But nobody is blocked from creating a new, special one for special purposes. Only if you want to be purist about MIME types is this probably suboptimal. The MIME type is ideal for choosing a renderer. JPS, for example, works much in the same way. 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. [1] http://www.faqs.org/rfcs/rfc2045.html On 09.03.2005 01:31:24 Glen Mazza wrote: The application/awt MIME type doesn't exist. I think Jeremias wanted this to be null instead for output types that lack a MIME type, correct? Thanks, Glen --- [EMAIL PROTECTED] wrote: +/** The MIME type for AWT-Rendering */ public static final String MIME_TYPE = application/awt; Jeremias Maerki
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
