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
