RE: [VOTE] Two changes to 1.0 branch
Glen Mazza wrote: I moved RTF and MIF to new fop.render.* packages. Also the RTF Library has been moved under render.rtf. Now most of our render-type specific code is under its respective render type in our package structure. I hope this becomes a cleaner design, if not we can revisit moving non-render specific code to separate lib directories later. Yes -- this is fine. I just wanted to make sure that we keep the lib stuff separate. BTW, thanks for doing the RTF patch. I got up Saturday to work on it, and it was ... done. Victor Mote
Re: [VOTE] Two changes to 1.0 branch
Team, I moved RTF and MIF to new fop.render.* packages. Also the RTF Library has been moved under render.rtf. Now most of our render-type specific code is under its respective render type in our package structure. I hope this becomes a cleaner design, if not we can revisit moving non-render specific code to separate lib directories later. I will hold off doing anything with the PDF library still at the root until its use in FOP is further analyzed. (Perhaps more than one package is needed, or some files are obsolete, etc., etc.) I don't see a rush on this, however--it can stay there for quite some time. Another issue I was working on last weekend--still unsolved--was that in 1.0 layout, fo:block space-before is being added to the top of *each* page that the block consumes (instead of just once at the top of the block). This may take some time to fix--I'll keep working on it. Thanks, Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: 2.) Move org.apache.fop.rtf.renderer to org.apache.fop.render.rtf. It doesn't matter that the RTF renderer doesn't need an area tree, or descend from our AbstractRenderer.java, etc., etc.--actually, that may be something to celebrate. For the solid foundation that Victor was talking about, the renderers should be placed together in the same package--sooner or later they're probably all going to be implementing a common (very) high-level interface anyway. [Are you in sufficient agreement on this one, Victor...if you can take of this with Peter's latest patch, that would be great...] +0, too. 3.) Move the rest of the rtf packages under org.apache.fop.render.rtf. No more rtf in FOP's root. (This issue is more controversial than #2 above, and can wait.) I don't see why this is more controversial than #2. It's practically the same as #2. +0 __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: [VOTE] Two changes to 1.0 branch
On 30.10.2003 01:50:49 Glen Mazza wrote: snip/ My current inclination after reading Victor and your posts: 1.) (Still), move org.apache.fop.pdf to org.apache.fop.render.pdf.pdfdoc (rename it similar to our rtfdoc package). Get it cleaned up and perfected, etc., remove obsolete classes, etc. *Then* discuss its future componentization. Fine with that. I think we're in a good position where we can freely move code within FOP without causing too much grief for others. Can we call it pdflib and rtflib instead of pdfdoc/rtfdoc? So, +0 from me. 2.) Move org.apache.fop.rtf.renderer to org.apache.fop.render.rtf. It doesn't matter that the RTF renderer doesn't need an area tree, or descend from our AbstractRenderer.java, etc., etc.--actually, that may be something to celebrate. For the solid foundation that Victor was talking about, the renderers should be placed together in the same package--sooner or later they're probably all going to be implementing a common (very) high-level interface anyway. [Are you in sufficient agreement on this one, Victor...if you can take of this with Peter's latest patch, that would be great...] +0, too. 3.) Move the rest of the rtf packages under org.apache.fop.render.rtf. No more rtf in FOP's root. (This issue is more controversial than #2 above, and can wait.) I don't see why this is more controversial than #2. It's practically the same as #2. +0 4.) MIF hold off on until we know what to do with it. Hmm, there is no MIF renderer at all, ATM. Following your points above you'd have to dump the code in ...fop.render.mif.miflib until someone writes another MIF renderer. For code reuse: 5.) While FOP can happily use lots of components (svg, avalon, etc., the more the merrier) it should not be a repository itself for components. Like Batik and Xalan, all packages and classes in FOP should be put into places that make architecturally the most sense in FOP itself--as if no one else is using the code. More to the point, we don't keep dumping things in the root out of concern that an app importing us will need to use a long import statement to get to our classes. Example: our svg.PDFTextPainter imports from org.apache.batik.gvt.text.TextPaintInfo. When creating this class, Thomas DeWeese (?) did *not* say Uh oh...it would be horrible for FOP's code to be ruined with such a long import statement...I'm going to break Batik's architecture and place TextPainterInfo in Batik's root just so FOP can have a shorter import statement. It is more important to me that FOP looks better, even if I have to turn Batik's design into architectural sludge. I think the error in thinking here was that external users--at least the good ones--would *want* our classes to be anywhere other than the best place for FOP itself anyway! Open-source users want SW to be highly used, highly successful--personally, I'll happily write Texas-sized import statements so long as it keeps Batik the most solid SVG product. I don't get your point. What's the problem with long import statements? 6.) After a component is cleaned up and gets demand from someone externally, move it to XML-Commons. Then, have FOP reimport the new XML-Commons package. If you ask me most components that could be factored out from FOP are slightly out of focus for XML Commons. The PDF library for example has little to do with XML. I'd personally put it in http://commons.apache.org. But all that is debatable and some people will see it differently. I'd really start by separating the components but keeping them within the xml-fop module (not immediately, only when someone itches enough. I'm starting to). From there they can easily be moved elsewhere if desired but the obligation to create a clean design is already given. Another benefit is the ability to clearly state for every component in what state (proof-of-concept, beta, productive) it is. Less questions like it works in PDF but doesn't in PCL. Is that an option for you? 7.) Keep going. Keep cleaning up and keep moving to XML-Commons, and keep re-importing into FOP. But nothing get moved to XML-Commons unless there is a legitimate demand for it first. (Don't want to send them 14 things, only 6 of which end up getting used.) But a component may only get recognized as such when it has its separate place. As I said before I'd be careful what to separate from FOP. Only things that have promise to be used in more than one project. If SVG code is moving over to Batik the above is true for PDF and fonts code. This one is going to take Victor the most amount of self-discipline--I'm not very optimistic here--he'd send his son to XML-Commons if he could get away with it! ;-) IMO this is unfair despite the smiley. Jeremias Maerki
Re: [VOTE] Two changes to 1.0 branch
--- Jeremias Maerki [EMAIL PROTECTED] wrote: This is no unsolvable problem. We just have to find the best way which may also lie in between opinions. One way may just be not to do anything at all right now or another to let Glen put his no-nonsense proposal to action until there is enough energy to do really clean up the whole thing. Indeed, we're a little bit closer on this, because this issue was not as important to me as the renderWord()-renderText() one was. Great if it happens, I'll survive if not! As Jeremias said, this can (and should) wait until more ideas surface. (New problem though: moving rtf.renderer to render.rtf seems fairly important--see #2 below) My current inclination after reading Victor and your posts: 1.) (Still), move org.apache.fop.pdf to org.apache.fop.render.pdf.pdfdoc (rename it similar to our rtfdoc package). Get it cleaned up and perfected, etc., remove obsolete classes, etc. *Then* discuss its future componentization. 2.) Move org.apache.fop.rtf.renderer to org.apache.fop.render.rtf. It doesn't matter that the RTF renderer doesn't need an area tree, or descend from our AbstractRenderer.java, etc., etc.--actually, that may be something to celebrate. For the solid foundation that Victor was talking about, the renderers should be placed together in the same package--sooner or later they're probably all going to be implementing a common (very) high-level interface anyway. [Are you in sufficient agreement on this one, Victor...if you can take of this with Peter's latest patch, that would be great...] 3.) Move the rest of the rtf packages under org.apache.fop.render.rtf. No more rtf in FOP's root. (This issue is more controversial than #2 above, and can wait.) 4.) MIF hold off on until we know what to do with it. For code reuse: 5.) While FOP can happily use lots of components (svg, avalon, etc., the more the merrier) it should not be a repository itself for components. Like Batik and Xalan, all packages and classes in FOP should be put into places that make architecturally the most sense in FOP itself--as if no one else is using the code. More to the point, we don't keep dumping things in the root out of concern that an app importing us will need to use a long import statement to get to our classes. Example: our svg.PDFTextPainter imports from org.apache.batik.gvt.text.TextPaintInfo. When creating this class, Thomas DeWeese (?) did *not* say Uh oh...it would be horrible for FOP's code to be ruined with such a long import statement...I'm going to break Batik's architecture and place TextPainterInfo in Batik's root just so FOP can have a shorter import statement. It is more important to me that FOP looks better, even if I have to turn Batik's design into architectural sludge. I think the error in thinking here was that external users--at least the good ones--would *want* our classes to be anywhere other than the best place for FOP itself anyway! Open-source users want SW to be highly used, highly successful--personally, I'll happily write Texas-sized import statements so long as it keeps Batik the most solid SVG product. 6.) After a component is cleaned up and gets demand from someone externally, move it to XML-Commons. Then, have FOP reimport the new XML-Commons package. 7.) Keep going. Keep cleaning up and keep moving to XML-Commons, and keep re-importing into FOP. But nothing get moved to XML-Commons unless there is a legitimate demand for it first. (Don't want to send them 14 things, only 6 of which end up getting used.) This one is going to take Victor the most amount of self-discipline--I'm not very optimistic here--he'd send his son to XML-Commons if he could get away with it! ;-) Jeremias Maerki (who blabbers to much) I think I just outdid you! Glen __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
RE: [VOTE] Two changes to 1.0 branch
Jeremias Maerki wrote: For example, we could easily make Peter Herweg a committer for the RTF libraries and renderer, but there is some hesitation (even on my part, who thinks Peter does good work) to turn him loose in layout until we know more about him, which takes time. In the meantime both he and we must work more slowly. Normally, you don't just go and mess around in other people's code if you don't know what you're doing. I think it's a relatively weak point to deny someone the committership only because of that. If Peter is able to handle the RTF output I don't see any problem allowing him to do that. If he grows into the other parts, so much better. Even I have never messed around in layout, yet. This seems to argue against having regulated commit access at all. IOW, on this same principle, everyone could/should be a FOP committer. Or, perhaps every Apache committer should be a committer on all projects. I doubt that is what you mean, but I guess ... I don't know what you *do* mean. The point is that if all of us had to be proficient on all Apache projects before being given commit access to any/all of them, it would take a long time to grow new committers. That is why FOP's monolithism is a drawback. Also, even if you haven't messed around in layout yet, you have discussed and voted on (IIRC) layout-related issues. There is an expectation that committers will have a feel for the project as a whole, and be able to contribute ideas. It probably sounds like I am crusading for something here, but I am not. Jeremias's original comments about FOP's monolithism rang true in my ears. Hearing no other proposed solutions to the problem, and seeing that mine is deprecated, I humbly acknowledge that it is an unsolvable problem, or perhaps no problem at all. Victor Mote
RE: [VOTE] Two changes to 1.0 branch
Glen Mazza wrote: Making a nice framework for others to create a FOP-like product is not as big a concern for me. I want to create FOP, not something to be used for creating a FOP. Hmmm. I think this comment is directed at me. WRT the first sentence, since this is open source with an Apache-style license, if we fail to make a nice framework for others to create a FOP-like product, then we have, by definition, failed to make a nice framework for FOP developers to create FOP. If a debate is needed here at all, it should be over whether such a framework is needed at all. WRT the second sentence, I guess I don't understand how failing to create things that can be used to create a FOP helps create FOP. It is like saying I don't want to build a foundation, I just want to build a house. Again, a debate about whether we are building something that needs a foundation or not might be interesting and useful. OTOH, maybe it would just be a waste of everyone's time. Victor Mote
Re: [VOTE] Two changes to 1.0 branch
On 28.10.2003 03:56:27 Glen Mazza wrote: Tom DeWeese of Batik made that suggestion a few months back--we're tentatively in agreement that once FOP gets solidified, the transcoders can move to them for their maintenance and documentation. Looks like I missed that one. I still haven't read everything from when I was on holidays. Good news, then, although that means that we have to do something about the PDF lib and the font code because I wouldn't want that duplicated. It should be somewhere accessible to both projects. The PDF transcoder could probably have long been promoted to 1.0 status already. Sie haben vergessen! PDF transcoder is distributed up with Batik right now--it's one of 1.0's few success stories. We don't even use maintenance for the transcoder--there's not a target for it in maintenance's build.xml. I know, but that doesn't count as a release IMO. It's snapshot that has been integrated in a release from another project. The Batik people haven't got control over the code they release. Documentation for the SVG transcoder is practically non-existent except for a few bits on the FOP and Batik sites. As always, our user base's primary concern is to have a product that can generate [absurdly high number of huge image-heavy documents] in [ridiculously small amount of time]. That is FOP's responsibility to Cocoon, Struts programmers, HP PCL users, Adobe PDF, etc. Right, and maybe parts of our user base will suddenly become active contributing Java code if we can make life for a newbie easier. That way, you don't have to do it all by yourself. I see the way of accomplishing this is by having FOP be (1) extremely fast and optimized; (2) extremely accurate; and (3) extremely focused on (1) and (2) above. Yep, I target (3) with my comments. Anyway, if FOP is unable to attract more developers it will never reach 1.0. Making a nice framework for others to create a FOP-like product is not as big a concern for me. I want to create FOP, not something to be used for creating a FOP. It is a concern for me. I believe that a lot of components that originated in FOP can be very interesting to use outside FOP. That's why it may make sense to talk about separating things off of FOP to make them available to a new audience and therefore heightening the possibility to attract new developers. FOP can profit from that, too. The XSL-FO layout engine is the main concern for this project. Everything around it (PDF lib, SVG support, font parsers etc.) is only infrastructure plus goodies. Jeremias Maerki
Re: [VOTE] Two changes to 1.0 branch
On 28.10.2003 14:40:29 Victor Mote wrote: Jeremias Maerki wrote: For example, we could easily make Peter Herweg a committer for the RTF libraries and renderer, but there is some hesitation (even on my part, who thinks Peter does good work) to turn him loose in layout until we know more about him, which takes time. In the meantime both he and we must work more slowly. Normally, you don't just go and mess around in other people's code if you don't know what you're doing. I think it's a relatively weak point to deny someone the committership only because of that. If Peter is able to handle the RTF output I don't see any problem allowing him to do that. If he grows into the other parts, so much better. Even I have never messed around in layout, yet. This seems to argue against having regulated commit access at all. IOW, on this same principle, everyone could/should be a FOP committer. Or, perhaps every Apache committer should be a committer on all projects. I doubt that is what you mean, but I guess ... I don't know what you *do* mean. No, it's not what I mean. I'm strongly for commit access per project and for having to earn it. Peter is one of the few who submitted more than just one patch in the past year. Since we're looking for new people wanting to contribute Java code he's the closest thing to that right now. You yourself started with documentation and now you're deep down in Java code. I'm not against regulated commit access, I'm talking about creating an incentive for people to join. Serious people. I believe that FOP was too restrictive in choosing its committers but that's easily explained I think: There used to be quite a lot of them. But they all went away for whatever reasons. The point is that if all of us had to be proficient on all Apache projects before being given commit access to any/all of them, it would take a long time to grow new committers. That is why FOP's monolithism is a drawback. Also, even if you haven't messed around in layout yet, you have discussed and voted on (IIRC) layout-related issues. There is an expectation that committers will have a feel for the project as a whole, and be able to contribute ideas. Yeah, but you should also be allowed to grow into these things. It probably sounds like I am crusading for something here, but I am not. I didn't think so. Jeremias's original comments about FOP's monolithism rang true in my ears. Hearing no other proposed solutions to the problem, and seeing that mine is deprecated, I humbly acknowledge that it is an unsolvable problem, or perhaps no problem at all. That doesn't bring us forward. We've only heard three opinions so far. We've got 430 subscribers to this mailing list and not only committers are allowed to express their opinions. Then there's also the people that actually do things and the others who only talk most of the times (like me lately). Well, there are the others who never say anything but that's the ones who don't have any fun at all. And you have to filter all that's being said, because you can never convey all your thoughts to the mailing list just the way you have them in your brain. We've got the big problem that we normally can't sit together and talk it out face to face. It would be much more productive and a lot less tiring. This is no unsolvable problem. We just have to find the best way which may also lie in between opinions. One way may just be not to do anything at all right now or another to let Glen put his no-nonsense proposal to action until there is enough energy to do really clean up the whole thing. Let's not all get frustrated. It's enough if I am having to do Delphi 50% of my time lately. Have fun coding, do what you can. Jeremias Maerki (who blabbers to much)
Re: [VOTE] Two changes to 1.0 branch
Glen, first of all, thanks for your continuing effort in the development towards 1.0. I'm sad that I currently don't have the time to contribute and have been extremely happy when I saw the first few patches targeted at HEAD coming in recently. On 27.10.2003 13:53:33 Glen Mazza wrote: Team, Two changes I would like to make to the 1.0dev branch: 1.) Rename the org.apache.fop.area.inline.Word class to org.apache.fop.area.inline.Text, and rename the renderWord() method in the Renderer subclasses to renderText(). snip/ This is confusing--Text/renderText() is better for these objects. Here is my +1. +1 2.) Move the org.apache.fop.pdf package to a new org.apache.fop.render.pdf.document package. I'd rather not for the following reason: The PDF library could be used separately and outside of FOP. I think I brought that up before that I'd even prefer splitting up the FOP source code into coarse-grained components (core + components actually). Take the two Transcoders (for PDF and PS) for example. They could just as well be in Batik. Maybe they should actually be there, or maybe they should be in a separate project that is maintained by interested FOP and Batik people as there are concerns from both sides. The PDF transcoder could probably have long been promoted to 1.0 status already. Because it lives in the same space as FOP it isn't. Ok, Keiron and I didn't push hard enough, yet, but I hope you get my point. The PS transcoder could equally get there quickly enough. Having EPS output for SVG is an interesting thing IMO. The font code could be used by other projects. Maybe the same for the MIF and RTF libraries and image abstractions. Actually, the font code would have to be extracted from FOP, too, because the PDF library and the two transcoders depend on it. By extracted from FOP I don't mean that the code must necessarily go to a new project. It could also stay in the FOP code base but live in a separate package structure. I particularly like the way the Cocoon people have split up their code base. I'm sure there are pros and cons to such a move but I'd like to have that discussed before Glen's proposal is put to action. As positive points for the split-up I see: - Cleaner design as the dependencies get more important and the components have to be worked out as such. - The individual components get a higher visibility which could attract new people. FOP is rather monolithic from an outside view which I believe can scare away rookies. - The PDF (maybe even the PS/EPS) transcoder could be released soon. Thoughts? Jeremias Maerki
RE: [VOTE] Two changes to 1.0 branch
Jeremias Maerki wrote: Two changes I would like to make to the 1.0dev branch: 1.) Rename the org.apache.fop.area.inline.Word class to org.apache.fop.area.inline.Text, and rename the renderWord() method in the Renderer subclasses to renderText(). snip/ This is confusing--Text/renderText() is better for these objects. Here is my +1. +1 +1 from me also 2.) Move the org.apache.fop.pdf package to a new org.apache.fop.render.pdf.document package. I'd rather not for the following reason: I agree, and for much the same reasons. The PDF library could be used separately and outside of FOP. I think I brought that up before that I'd even prefer splitting up the FOP source code into coarse-grained components (core + components actually). +1 Take the two Transcoders (for PDF and PS) for example. They could just as well be in Batik. Maybe they should actually be there, or maybe they should be in a separate project that is maintained by interested FOP and Batik people as there are concerns from both sides. The PDF transcoder could probably have long been promoted to 1.0 status already. Because it lives in the same space as FOP it isn't. Ok, Keiron and I didn't push hard enough, yet, but I hope you get my point. The PS transcoder could equally get there quickly enough. Having EPS output for SVG is an interesting thing IMO. The font code could be used by other projects. Maybe the same for the MIF and RTF libraries and image abstractions. +1. The RTF stuff is already set up in a separate directory this way. This is primarily due to the design of the JFOR crew. MIF should be done the same way. And I agree that the same could be done with fonts. I would actually prefer to see a directory structure that started at either util or lib that had subdirectories like lib/pdf and lib/rtf. These are separate from, but used by, the renderers. Without belaboring the point (discussed earlier), I see benefits to even taking the FOP core stuff and breaking it up into smaller pieces. I think the FO Tree can be treated as a separate project. I *definitely* think there is benefit to treating each of the layout strategies as separate projects. To a lesser extent, but still important, I think each of the renderers can and probably should be treated that way as well. That just leaves the Area Tree, which will end up having a lot of sub-pieces dependent on it (each of the layout strategies and each of the laid-out renderers), and I even like having it as a separate sub-project. Core FOP then becomes the apps package, managing the flow between the various sub-projects. Actually, the font code would have to be extracted from FOP, too, because the PDF library and the two transcoders depend on it. By extracted from FOP I don't mean that the code must necessarily go to a new project. It could also stay in the FOP code base but live in a separate package structure. I particularly like the way the Cocoon people have split up their code base. I'm sure there are pros and cons to such a move but I'd like to have that discussed before Glen's proposal is put to action. As positive points for the split-up I see: - Cleaner design as the dependencies get more important and the components have to be worked out as such. Yes! - The individual components get a higher visibility which could attract new people. FOP is rather monolithic from an outside view which I believe can scare away rookies. Yes! We could have committers that work only on layout but don't mess with renderers, and vice versa. The monolithism hurts us from the inside looking out as well, in that we are hesitant to make new committers until they understand *all* of FOP. For example, we could easily make Peter Herweg a committer for the RTF libraries and renderer, but there is some hesitation (even on my part, who thinks Peter does good work) to turn him loose in layout until we know more about him, which takes time. In the meantime both he and we must work more slowly. - The PDF (maybe even the PS/EPS) transcoder could be released soon. Thoughts? I can think of no case where a project that can be *cleanly* broken down into smaller projects does not benefit from it. However, here are some (potential) drawbacks: 1. releasing code is probably more complicated (more dependencies must be managed) 2. if we want to granularize commit access, I don't know whether that can be done feasibly apart from separate projects. In the long run, we need a lib package for graphics formats. I think we need an Apache-license equivalent to Jimi and JAI. This could/should eventually be a separate package, but our existing native capabilities should probably be considered here as well. I would turn Ben Galbraith loose in this code in a heartbeat. Victor Mote
Re: [VOTE] Two changes to 1.0 branch
On 27.10.2003 18:38:07 Victor Mote wrote: snip/ +1. The RTF stuff is already set up in a separate directory this way. This is primarily due to the design of the JFOR crew. MIF should be done the same way. And I agree that the same could be done with fonts. I would actually prefer to see a directory structure that started at either util or lib that had subdirectories like lib/pdf and lib/rtf. These are separate from, but used by, the renderers. Without belaboring the point (discussed earlier), I see benefits to even taking the FOP core stuff and breaking it up into smaller pieces. I think the FO Tree can be treated as a separate project. I *definitely* think there is benefit to treating each of the layout strategies as separate projects. To a lesser extent, but still important, I think each of the renderers can and probably should be treated that way as well. That just leaves the Area Tree, which will end up having a lot of sub-pieces dependent on it (each of the layout strategies and each of the laid-out renderers), and I even like having it as a separate sub-project. Core FOP then becomes the apps package, managing the flow between the various sub-projects. You go further than I would have dared. snip/ For example, we could easily make Peter Herweg a committer for the RTF libraries and renderer, but there is some hesitation (even on my part, who thinks Peter does good work) to turn him loose in layout until we know more about him, which takes time. In the meantime both he and we must work more slowly. Normally, you don't just go and mess around in other people's code if you don't know what you're doing. I think it's a relatively weak point to deny someone the committership only because of that. If Peter is able to handle the RTF output I don't see any problem allowing him to do that. If he grows into the other parts, so much better. Even I have never messed around in layout, yet. - The PDF (maybe even the PS/EPS) transcoder could be released soon. Thoughts? I can think of no case where a project that can be *cleanly* broken down into smaller projects does not benefit from it. However, here are some (potential) drawbacks: 1. releasing code is probably more complicated (more dependencies must be managed) Right. Therefore, I'd only separate the parts that are useful in a non-FOP context keeping that effort at a minimum. 2. if we want to granularize commit access, I don't know whether that can be done feasibly apart from separate projects. Commit access is per project. 3. Splitting the whole thing up too much only brings other problems. You have to add tons of directories as source directories in your IDE, for example. IMO we shouldn't break up core-FOP too much. In the long run, we need a lib package for graphics formats. I think we need an Apache-license equivalent to Jimi and JAI. This could/should eventually be a separate package, but our existing native capabilities should probably be considered here as well. I would turn Ben Galbraith loose in this code in a heartbeat. Yeah, I thought about that one just 2 hours ago when I was working on Krysalis Barcode's bitmap generation code. If we went down that road we would need to define which parts we want to separate and where they go: 1. into another project (Batik) 2. into a new project (as XML subproject, Jakarta subproject, XML Commons, Apache Commons, Jakarta Commons) 3. into a separate place in xml-fop, thus staying in FOP but becoming some kind of sub-subproject. Jeremias Maerki
Re: [VOTE] Two changes to 1.0 branch
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Glen, first of all, thanks for your continuing effort in the development towards 1.0. Sure thing--two patches down, 21,234,198 to go! ;) Take the two Transcoders (for PDF and PS) for example. They could just as well be in Batik. Maybe they should actually be there, or maybe they Tom DeWeese of Batik made that suggestion a few months back--we're tentatively in agreement that once FOP gets solidified, the transcoders can move to them for their maintenance and documentation. The PDF transcoder could probably have long been promoted to 1.0 status already. Sie haben vergessen! PDF transcoder is distributed up with Batik right now--it's one of 1.0's few success stories. We don't even use maintenance for the transcoder--there's not a target for it in maintenance's build.xml. Thoughts? As always, our user base's primary concern is to have a product that can generate [absurdly high number of huge image-heavy documents] in [ridiculously small amount of time]. That is FOP's responsibility to Cocoon, Struts programmers, HP PCL users, Adobe PDF, etc. I see the way of accomplishing this is by having FOP be (1) extremely fast and optimized; (2) extremely accurate; and (3) extremely focused on (1) and (2) above. Making a nice framework for others to create a FOP-like product is not as big a concern for me. I want to create FOP, not something to be used for creating a FOP. Anyway, thanks everyone for voting, and especially to Victor and Jeremias for their well-explained positions. I'll get the first one taken care of shortly, and hold off on doing the second due to their concerns at this time. Glen __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
