--- 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/
