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


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


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

Reply via email to