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

Reply via email to