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

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

[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!


Do you Yahoo!?
Exclusive Video Premiere - Britney Spears

Reply via email to