commit to fop
bonjour fop-devs bertrand delacretaz told me you might welcome some help on fop. I would be pleased to contribute. *** why fop *** - i'm very interested in xml and java - i believe in open-source and wish to contribute to a project - bertrand told me you were a good team *** me *** you can get my background at www.oslutions.com/about *** documentation *** please could you tell me about the state of the following documentations: - xml.apache.org/fop/dev: this documentation refers to 0.20, right? - cvs/... /xdocs/DnI: simon, thanks a lot for your xdoc DnI, it really helped me diving into the code. some parts of it have changed. i started to update it and made a patch for chapter 4.1 , you can find it attached to bug 33126. if it's useful for you, i'll continue. - fop-wiki (http://wiki.apache.org/xmlgraphics-fop/FOPProjectPages) seems pretty up to date. please tell me if FOPProjectTasks and FOPWorkEstimates are up to date. - are there some more key-docs? *** plans *** (thinking loud) i plan to start with some documentation update. i see there is a brand new site at xmlgraphics.apache.org/ to do. what about rtf-rendering? is peter herweg still active on it? i'm open, so please give me some hints on where i could start as i am pretty new to open-source developpment, please let me know if i'm doing things the right way. have a nice weekstart greetings from switzerland renaud
Re: commit to fop
jeremias and simon: thanks for your response. now i see better where to look. i'll follow the maillinglist & start to dig in the code. renaud
Re: Page breaking
Jeremias, > I went back to Simon's and Finn's ideas about page breaking and I see > some overlap. could you point me to where Simon and Finn exposed their ideas? thanks, Renaud
Re: another nose for the grindstone
bonjour fop-devs i would like to work on the awt renderer. Mark (or someone else) , are you working on it? i checked out the code from FOP 0.20.5. is it the latest maintenance version? thanks, renaud On Mon, 17 Jan 2005 10:54:43 +0100, Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Hi Mark > > We'd love to have you with us. > > On 17.01.2005 05:18:23 Mark Brucks wrote: > > I'd like to join the fop development group. I've been an xsl/fop user > > for the last year or so (generating PDF), but several new projects I'm > > proposing have a need for a robust and complete awt renderer, and I'd > > like to devote some time to ensuring this happens. I have a little bit > > of time in the near term to commit to the project, and I hope much more > > time starting in the April time frame. I'd like to use the next 2 > > months to come up to speed, then dive in to serious work when more time > > is available. > > The AWT renderer is currently missing in CVS HEAD. It would be great if > someone took up that task. To build that renderer you can look at the > code from the maintenance branch (or FOP 0.20.5) for reference. Our > reference renderer in CVS HEAD is the PDF renderer (like before). > > Personally, I'd rather call it Java2D renderer, not AWT renderer, > because Java2D is essentially the name of the API you code against. AWT > is, as the name says, a windowing toolkit, not primarily a graphics API. > > > I need some advice. I've learned enough about xsl and fop to get my job > > done, but there are lots of holes in my knowledge base. I'd like to > > spend a little bit of time carefully reading the XSL spec. Should I > > read the XSL V1.1 working draft (in anticipation of things to come), or > > should I stick with the V1.0 recommendation (which I assume is what the > > new version of fop will implement). > > The recommendation is still the main reference. Glen Mazza already > started investigating the 1.1 WD (ex. bookmarks) and it might be helpful > sometimes to consult the 1.1 WD because it seems to be somewhat more > verbose. It's good to prepare for 1.1 but as long as it's in WD phase > the focus should remain on the 1.0 Rec for the time being. > > > Do the development and design documents that are available on-line > > relate to the root/trunk/redesign version, or do they still describe the > > maintenance branch? > > They refer to CVS HEAD. If they are not up-to-date, they should be > updated. > > > Is there a development schedule or a prioritized list of features to be > > implemented? > > A development schedule is always difficult in an all-volunteer project. > I think it's pretty realistic now to target an initial release in late > summer 2005. > > I'm currently working off this list: > http://wiki.apache.org/xmlgraphics-fop/FOPWorkEstimates > > But this list isn't binding. You're free to choose what you like to work > on. If you want to build the Java2D renderer, that's great. If you want > to help with the layout engine, even better. If you start a task simply > notify us what you're working on so we don't have duplicate effort. > > > Is anybody else actively working on the awt rendered for the next release? > > No, not at the moment. > > > Since this is my first foray into open-source development, any and all > > advice is welcome. > > The advice is simple: Choose something to work on, notify this list (if > it's something bigger), start hacking and in the end send patches via > Bugzilla. Of course, this is a bit simplistic but essentially this is > all what you need to know for now. :-) > > If you have questions simply ask. We're happy to help you getting > started. > > > Jeremias Maerki >
Re: another nose for the grindstone
Mark, just let me know when you'll start to work on it. Clay, sorry for not making clear that i needed the maintenance code for reference. Jeremias, thanks for the pointer i'm not sure about the following. please correct me if i'm wrong: the (currently named) AWTRenderer allows 3 different kinds of output 1) GUI-application 2) a java Image (containing all areas represented as Graphics2D's) 3) a printed document through AWTPrintRenderer, or is it the commandline options to start the differents output are 1) -awt 2) 3) -print i started to investigate the rendering system. the AbstractRenderer is well designed and already implementing a lot of stuff, so that should go allright for the AWTRenderer. thanks, renaud On Tue, 22 Feb 2005 07:48:28 +0100, Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Clay, > > he knows that. I told him to use the maintenance branch code as a > reference for bringing back the AWT Renderer in CVS HEAD. Renaud and I > met last Friday at lots.ch. > > So, Renaud, please use the code found under the "fop-0_20_2-maintain" > branch for reference. And happy hacking! > > On 22.02.2005 05:38:58 The Web Maestro wrote: > > On Feb 21, 2005, at 4:55 PM, Renaud Richardet wrote: > > > bonjour fop-devs > > > > Salut! Bienvenue! > > > > > i would like to work on the awt renderer. Mark (or someone else) , are > > > you working on it? > > > i checked out the code from FOP 0.20.5. is it the latest maintenance > > > version? > > > > > > thanks, renaud > > > > Actually, the fop-0.20.5 code is merely for reference. All FOP > > development has moved away from the fop-0.20-5 branch > > (fop-0_20-maintain OR 'maintenance' branch) in favor of the re-design > > branch (HEAD). This was done because the 'maintenance' branch had > > significant problems that were not easily resolvable. The re-design > > branch occurred because of problems in implementing the XSL0FO 1.0 > > spec--specifically with the 'keeps' I believe. > > > > In any case, if you wish to contribute to FOP development, please check > > out the HEAD branch. You may look to fop-0.20.5 for reference, but any > > work you do on that branch will probably not be integrated into FOP > > 1.0. > > Jeremias Maerki > > -- renaud.richardet (at) gmail (dot) com +41 78 675 9501 www.oslutions.com
AWTRenderer: getting the absolute position of an area
bonjour fop-dev's i've been walking through the rendering process. if i understand it rightly, an area doesn't records it's absolute position. therefore, we have to pass the currentIPPosition, currentBPPosition all along during the rendering process to figure out where to position an area. what i don't understand: this information (the absolute position of an area) MUST somehow have been known during the building of the area tree (otherwise we could'nt know where to break the pages). so my question: wouldn't it be easier to record the absolute position of an area during the page-breaking process? or am i missing something? renaud PS: the abstract Java2DRenderer sounds like a really good deal to me :)
Re: AWTRenderer: getting the absolute position of an area
hello Jeremias merci for the informations. > I wondered about that, too: > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=984481 interesting! Victor, in [1] you talked about dealing with the positioning of areas during the AreaTree building. could you point me to the classes in FOray that handle that logic? > So far, I can only say that there's so mandatory reason for that change. > It would certainly make the renderers simpler but there might be > problems in other areas. The real downside is when you have to do the > same calculations in every renderer. ok, that's what i was affraid of... but i understand that the area tree building is already enough complex. well, i'll base the Java2DRenderer on the pdf renderer. could someone tell me if it's stable enough (especially those tricky issues like reference-orientation and writing-mode that i don't completely understand yet). > Some can be (and already are) put > in AbstractRenderer but for others this is not so easily possible. No > definitive answer from me. We'll see what comes out of the page-break > rewrite. ok, good luck. i'm looking forward to see your rewrite. renaud [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=10534
Re: Renaming the AWT Renderer to Java2D Renderer
Glen Mazza <[EMAIL PROTECTED]> wrote: > Looks good! Now whether you wish to do this before or > after Renaud moves the logic over is up to you two. > There's advantages/disadvantages to either method. yes, that looks good! Jeremias, if it's ok for the team, i would apreciate if you would do the changes asap. thanks, Renaud
Re: AWTRenderer: getting the absolute position of an area
Victor, thanks for your explanations. i'll give a look into FOray when i'll feel more confident about the layout process. cheers, Renaud
Re: Renaming the AWT Renderer to Java2D Renderer
Glen, > We can do it this way. But on second thought, I think > it would be better for Renaud to move it in as > AWTRenderer, and slowly start factoring out more and > more while things are getting settled. BTW, this will > take some time to do anyway--it isn't easy because the > renderers are so different between 0.20.5 and 1.0. That's what I'm doing now. And yes, it might take some time... > [A note for Renaud: I would recommend cutting down on > the chatroom English and instead start writing > properly/respectfully to us, in the same manner that > all of us have been writing to you. Capitalize "I", > the first word of each sentence, your name, our > names[1], greetings, etc. Above all, when people > write to you in standard polite English, you shouldn't > be responding back with chatroom writing. None of us > here do. Thanks!] > > Glen > > [1] > http://marc.theaimsgroup.com/?l=fop-dev&m=110625230922690&w=2 Your note sounded hard to me. My apologies to you and the other members of the team. In the future i'll use standard English. Please do not take my writing style as a sign of misrespect, as this was NOT my intention. This style is pretty well accepted in Switzerland (in German, we have to capitalize all Words, so this saves a lot of Typing) and i find it personally nicer. If you have other objects like [1] in your stack, please let me know it now (via this maillist or directly to me). As I said in [2], I am pretty new to open-source developpment, so please let me know if i'm doing things the right way. I'm enjoying this project and would like to move forward smoothly (and respectfully of the other members of this team). Regards, Renaud [2] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=2080086
Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
Victor and Jeremias, thanks for your Inputs. Victor, I've checked out your aXSL. I'll study it and come back to you if I have questions. Jeremias wrote: > > Speaking of startVParea(), could we rename it to something more meanigfull? > > Proposition: TransformPosition, or something like this. > > Deleted the methods moved to AbstractRenderer. > Actually, I like startVParea() (or rather startViewportArea like I would > rather call it) because only for viewport a new transformation matrix is > necessary. I think when you port the matrix concatenation from the PDF > renderer over to Java2D in startVParea() you will start to understand > what's going on here. OK, thanks. That makes sense. > > fop.area.CTM: added two getters for e and f. If there's another way to get > > those > > values, please let me know. > Normally, we use toArray() but I guess these two getters are ok and > don't hurt although I think they are not necessary because you need to > use all other values in the CTM, too, to get the reference orientation > stuff right. See above. OK, I'll use the available toArray() instead. > > The enclosed image doesn't have ipd/bpd > > either. Again: is this normal so? I have a workaround in mind (getting those > > values through the FopImage), but it doesn't sound right. > In this case it is probably better to fix the LMs. I've started doing > that but haven't finished. ATM this is lower priority for me. I can send > you my current code if you want to try to fix it. Shouldn't be so > difficult. I would also prefer to fix the LM's. I don't want to go into it now (too complex for me ATM), but I'll come back to you later. > > renderTextDecoration(InlineArea) seems to work, even if it's not > > implemented?? > Huh? It was you who moved the implementation up from PDFRenderer to > AbstractRenderer. That's how you implemented it. Inheritance! I mean renderTextDecoration(InlineArea) from AbstractRenderer, which is an empty ATM . Did you mean renderTextDecoration(Font fs, InlineArea Inline, int baseline, int startx) instead? But I think I got in now: when I run examples/fo/basic/textdeko.fo , the underline of the sentence "This is a whole block wrapped in fo:inline with the property text-decoration="underline". Some more Text to get at least two lines." works ok. This is because the TextArea handles the underline (via renderTextDecoration(Font fs, InlineArea Inline, int baseline, int startx) ) and the renderTextDecoration(InlineArea) doesn't do anything. > 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. Sounds very good. Why haven't I thought of it ? ;) > Another thought: One of my low-priority tasks is to create a little > application that renders a test suite with all of FOP's renderers > creating bitmap images for each generated document and ultimately > creating a little website that lets us compare the output. PDFs and PS > files can be converted to bitmaps using GhostScript. Maybe you might > want to write such a thingy. I won't get to it before I get to updating > the PS renderer to full quality. That would be good. Do you mean something like the "Bitmap production" you documented on FopAndJava2D [1]? This is what I intend to work on after the basic Java2DRenderer works. Thanks for your valuable comments. I'll work them out carefully and post an improved patch. Regards, Renaud [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
Re: Skype-conference on page-breaking?
I would be please to listen. Renaud
Re: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems
Vincent Hennebert wrote: > By looking for this reference, I found the following article: > www.pi6.fernuni-hagen.de/publ/tr234.pdf > It's entitled 'On the Pagination of Complex Documents' (actually it's also > referencing Plass). There's another article, where the top level of the algorithm is presented (page 8). http://www.pi6.fernuni-hagen.de/publ/tr205.pdf Those 2 articles are summaries of a book. The link to command the book can be found at the bottom of http://web.informatik.uni-bonn.de/I/research/Pagination/ Renaud
Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
I worked on my patch and tried to integrate you inputs. There are still many issues, but I think the basic structure is OK. You can find a patch attached to bug 33760. Comments inline: On Mon, 28 Feb 2005, Victor Mote 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. 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. > > 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? > 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 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]. 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. Renaud [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
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! > 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
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
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
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: 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
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
