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
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
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
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: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
Renaud Richardet wrote (in Bugzilla): http://issues.apache.org/bugzilla/show_bug.cgi?id=33760 Summary: [Patch] current AWTRenderer Product: Fop Version: 1.0dev ... = Points I would like to discuss (see the corresponding FIXME in the code) = Fonts: I must be missing something with the font-mechanism: the rendered text in the AWTRenderer is smaller that the one of PDFRenderer. What I need is a way to get a java.awt.Font from an area. Is the class FontSetup implemented correctly? Do I have to worry about multibyte-stuff? I could investigate the whole mechanism, but a hint would certainly speed my work. Here are some things that may help: 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 say theoretically because the aXSL interface was simply extracted from the FOray code, and FOray is almost certainly the only aXSL implementation available ATM. The point is that someone *could* write another aXSL implementation that would work seamlessly with FOP. The only cost would be the instantiation of the brand X FontServer implementation instead of the FOray FontServer implementation. 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. 2. The java awt Font-related classes don't give access to the underlying font file. This causes problems for the PDF renderer, which needs to be able to embed fonts in its output. Within FOray, the major distinction within the fonts is whether they are FreeStanding or System (awt) fonts. Embedding requires FreeStanding. AWT Renderer requires System fonts. There is some hope of merging the two at some time in the future, by using java.awt.Font.createFont method to create the AWT font from the application's (i.e. FOP/Folio/FOray) font registration system. However Java 1.3 1.4 only support TrueType fonts in this method, and 1.5 only adds support for Type1, so there are some built-in limitations. (FOrayFont doesn't support OpenType either, but it is very feasible to add that ourselves). 3. There are no doubt substantial improvements that can be made to the way aXSL/FOray handle the System font issue. I would be glad for someone who actually uses this aspect of the font system (I don't) to comment on it and suggest improvements. With the above as some background, I'll try to answer your questions: the rendered text in the AWTRenderer is smaller that the one of PDFRenderer. Some possibilities are 1) because of the dichotomy of the registration and selection of the fonts, you can actually be using different fonts for layout and rendering, 2) to the extent that the AWT renderer uses AWT to do the layout/rendering, there are bound to be differences between that and the way FOP does it. I wouldn't have expected font sizes to be a big issue, so maybe there is something else at work here as well. What I need is a way to get a java.awt.Font from an area. The aXSL Font interface java.awt.Font getAWTFont(FontConsumer consumer, int fontSize) method. If the font is a System font, it will return the AWT font to you. The trick for you then is to be able to get the aXSL font instance out of the FOP FOTree or AreaTree. I'll defer to the FOP developers to tell you how to get that done. Is the class FontSetup implemented correctly? It depends upon what you mean by correctly. Like so many other things in FOP, it kind of works, but is very difficult to improve because of the underlying design. It is what evolved into the FontServer class in aXSL and FOray. Much of its data is static, which causes problems when running multiple documents in multiple threads (fixed in FOray). That may not be an issue for an AWT renderer, but is an issue when trying to develop a general solution that will also work for other renderers. IMO, the whole font subsystem had evolved into an unmanageable mess that needed a serious cleanup. However, that really is just an opinion. Do I have to worry about multibyte-stuff? For screen display and java printing, I don't think so, since that is all handled by AWT. I could investigate the whole mechanism, but a hint would certainly speed my work. I am a FOP outsider these days, so maybe one of the committers can add some more insight. I implemented a simple .bmp rendering (BMPReader.java). It only supports 8-bit and 24-bit uncompressed windows bitmap images. I found this code on the net. I know you had problems with licences and I don't want to raise an
Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
(Comments inline) On 27.02.2005 23:51:25 bugzilla wrote: I've been working on the AWTRenderer those last days. Before I move forward, I would welcome some feedback to know if I'm heading in the right direction. I think you are. Interesting work. Keep it up! = What I did = Basically, I tried to implement in AWTRenderer what the PDFRenderer does. The drawback is that all what doesn't work for the PDFRenderer doesn't work for the AWTRenderer neither. I've posted a patch with the updated renderers. The patch has changes for the classes AWTRenderer, AbstractRenderer, PDFRenderer and CTM plus a new class BMPReader. AWTRenderer: I implemented several renderXXX() methods and the corresponding helper methods. 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. Each renderer may have a slightly different way of holding state (currently selected line width, font etc.). So far it looks good to me even if pulling up currentFontName was necessary. Ideally, this variable should probably not be in AbstractRenderer I think. PDFRenderer ans PSRenderer: I moved 2 lines (currentIPPosition = 0; currentBPPosition = 0; ) in startVParea() because the AWTRenderer uses those values in another way and need to keep track of them (see startVParea() in AWTRenderer). 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. I think the Java2D approach is not unlike the PDF/PS approach. See Graphics2D.setTransform() and AffineTransform.concatenate(). 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. = Points I would like to discuss (see the corresponding FIXME in the code) = Fonts: I must be missing something with the font-mechanism: the rendered text in the AWTRenderer is smaller that the one of PDFRenderer. The AWT/Java2D renderer uses a different font source than the PDF and PS renderers. The AWT/Java2D renderer gets the font metrics of the individual fonts from the AWT subsystem. See AWTFontMetrics and FontMetricsMapper. The different way of getting font metrics may result in a slighly differently rendered document when compared to PDF. That is expected and is the same in FOP 0.20.5. What I need is a way to get a java.awt.Font from an area. I think you are already on the right track with the current implementation. Simply use PDFRenderer.updateFont() as a reference. The only thing I see is that you should check currentFontName and -Size to avoid any unnecessary and costly creation of Font objects. The FontMetricsMapper should do all the rest for you. Is the class FontSetup implemented correctly? Yes, I think so, although it might be worth checking out if the available font could be enumerated and registered. On the other side this might lead to a lot of work being done during setup. Maybe this stuff could be refactored to do late font resolution (creation of the necessary objects when needed/requested). Check with a special font (not Arial or Times or one of the standard fonts) from your system to see what happens. Do I have to worry about multibyte-stuff? I don't think you have to worry about multi-byte stuff because it will be handled for you as Java internally uses Unicode and you only send normal Unicode strings to the Java2D api. I could investigate the whole mechanism, but a hint would certainly speed my work. Colors: My method updateColor (Graphics2D graphics, Area area) doesn't work for some areas.Same question here: how can I get a java.awt.Color from ANY area? Not sure but I think Graphics2D.setColor() only sets the stroking and text color. Have a look at Graphics2D.setPaint(). Did you see that you didn't use the fill parameter of updateColor? if fill is true you can probably simply set graphics.setPaint(newCol). Try to consolidate all the updateColor() methods. Also I'd remove ColorTypeProperty.getAWTColor() to avoid the dependency on java.awt.Color. Use AWTRenderer.toColor instead and improve this for non-sRGB colors (if we already have color outsite sRGB). There are still many issues with the positioning of the areas. I keep
Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
Thanks for bringing this up. I almost forgot. I'd be in favor of integrating Victor's improvements in this area. However, I'd also be inclined to gently nudge you, Victor, to bring the font stuff back to Apache into the XML Graphics Commons area once that's set up. But I wouldn't have a problem to use your code from your SourceForge location for the moment. We haven't talked, yet, what you'd think about that. :-) On 28.02.2005 17:20:32 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 say theoretically because the aXSL interface was simply extracted from the FOray code, and FOray is almost certainly the only aXSL implementation available ATM. The point is that someone *could* write another aXSL implementation that would work seamlessly with FOP. The only cost would be the instantiation of the brand X FontServer implementation instead of the FOray FontServer implementation. 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. Jeremias Maerki
RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
Jeremias Maerki wrote: Thanks for bringing this up. I almost forgot. I'd be in favor of integrating Victor's improvements in this area. However, I'd also be inclined to gently nudge you, Victor, to bring the font stuff back to Apache into the XML Graphics Commons area once that's set up. But I wouldn't have a problem to use your code from your SourceForge location for the moment. We haven't talked, yet, what you'd think about that. :-) Hmmm. This is certainly an Apache decision, not mine. If it works better for you to have the code a part of an Apache project, you are certainly welcome to do that. IMO, it would result in a lot of unnecessary duplication of effort. I used to think that duplication of effort was the greatest evil to be avoided, but my experience on FOP has expanded my horizons a bit -- pulling in opposite directions is worse. Still, duplication should be avoided if possible. My suggestion would be the following: 1) Write your font logic to the aXSL interface and use FOray as the implementation of that interface. 2) As improvements to font logic are needed, ask for them. I'll do my best to accommodate them within FOray. 3) If 2 proves unsatisfactory, I will be happy to consider adding some Apache people as committers on FOray (actually, I'll be glad to do that anyway). 4) If 3 becomes unsatisfactory, fork FOrayFont into an Apache project and start hacking away, or start a new project that uses the aXSL interface. 5) If the aXSL interface is inadequate and for any reason can't be changed, fork it and improve as necessary. Such a scheme allows us to be optimistic that we will be able to work together, but protects everybody in case we can't. Victor Mote
Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
I think you misunderstood. I wanted to suggest transferring (not copying/forking) these parts over to Apache with you as a committer in the Commons part. That would make it mostly your decision. I'm all against duplication of efforts. Actually, it was the motivation for this post. At Apache you'd have a bigger audience as well as a bigger chance of finding people willing to help. And I don't see a big risk for disputes as there were for the overall approach for FOP. It was just an idea in the hopes of bringing people back together to work on things with little to no potential for disagreements. On 28.02.2005 19:33:05 Victor Mote wrote: Jeremias Maerki wrote: Thanks for bringing this up. I almost forgot. I'd be in favor of integrating Victor's improvements in this area. However, I'd also be inclined to gently nudge you, Victor, to bring the font stuff back to Apache into the XML Graphics Commons area once that's set up. But I wouldn't have a problem to use your code from your SourceForge location for the moment. We haven't talked, yet, what you'd think about that. :-) Hmmm. This is certainly an Apache decision, not mine. If it works better for you to have the code a part of an Apache project, you are certainly welcome to do that. IMO, it would result in a lot of unnecessary duplication of effort. I used to think that duplication of effort was the greatest evil to be avoided, but my experience on FOP has expanded my horizons a bit -- pulling in opposite directions is worse. Still, duplication should be avoided if possible. My suggestion would be the following: 1) Write your font logic to the aXSL interface and use FOray as the implementation of that interface. 2) As improvements to font logic are needed, ask for them. I'll do my best to accommodate them within FOray. 3) If 2 proves unsatisfactory, I will be happy to consider adding some Apache people as committers on FOray (actually, I'll be glad to do that anyway). 4) If 3 becomes unsatisfactory, fork FOrayFont into an Apache project and start hacking away, or start a new project that uses the aXSL interface. 5) If the aXSL interface is inadequate and for any reason can't be changed, fork it and improve as necessary. Such a scheme allows us to be optimistic that we will be able to work together, but protects everybody in case we can't. Victor Mote Jeremias Maerki
RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
Jeremias Maerki wrote: I think you misunderstood. I wanted to suggest transferring (not copying/forking) these parts over to Apache with you as a committer in the Commons part. That would make it mostly your decision. I'm all against duplication of efforts. Actually, it was the motivation for this post. At Apache you'd have a bigger audience as well as a bigger chance of finding people willing to help. And I don't see a big risk for disputes as I don't mean to be rude or insult anyone, but the help I found at Apache was a net loss. Sure, there is some real help, but it was far outweighed by the hindrances. There is something wrong either with me or the way the FOP community works, maybe both. Of the 18 months that I spent working on FOP, I consider the last 12 of it to have been utterly wasted. Worse, I probably wasted other people's time along the way. There is a steady stream of FOP users who want to contribute to the project who simply cannot find a way to overcome the obstacles that the FOP committers place in front of them. The rather thin constituency that allows me to continue working on open-source publishing software would evaporate if I went down that path again. At the risk of seeming coy or ungrateful (I hope I am neither) it really is not an option for me. As for a bigger audience, I am not worried about that. If we produce something worthwhile, people will find it. willing to help. And I don't see a big risk for disputes as there were for the overall approach for FOP. You may be right, but I have reason to doubt it. If what you say were true, FOP would have done a 0.21 release in September that incorporated FOrayFont: a very modest (but real) cost to the project, significant gains to both users and the project, the fairly speedy removal of a whole class of support issues, a test-bed for one actual 1.0 module, modest cleanup of the code base, the opportunity to attract developers to work on a much simpler discrete subsystem, elimination of the *immediate* need for a competing product, etc. IMO, that should have been a slam-dunk, but wasn't. Here is a huge disagreement that has nothing to do with system design at all. As with many other FOP decisions, I am just baffled. It was just an idea in the hopes of bringing people back together to work on things with little to no potential for disagreements. I think we can and should work together, but I see only downside potential to making the relationship as tight as it once was. My philosophy makes ample room for making mistakes ... once. Victor Mote
