On 27.10.2003 18:38:07 Victor Mote wrote:


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

You go further than I would have dared.


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

Normally, you don't just go and mess around in other people's code if
you don't know what you're doing. I think it's a relatively weak point
to deny someone the committership only because of that. If Peter is able
to handle the RTF output I don't see any problem allowing him to do that.
If he grows into the other parts, so much better. Even I have never
messed around in layout, yet.

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

Right. Therefore, I'd only separate the parts that are useful in a
non-FOP context keeping that effort at a minimum.

> 2. if we want to granularize commit access, I don't know whether that can be
> done feasibly apart from separate projects.

Commit access is per project.

3. Splitting the whole thing up too much only brings other problems. You
have to add tons of directories as source directories in your IDE, for
example. IMO we shouldn't break up core-FOP too much.
> 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.

Yeah, I thought about that one just 2 hours ago when I was working on
Krysalis Barcode's bitmap generation code.

If we went down that road we would need to define which parts we want to
separate and where they go:
1. into another project (Batik)
2. into a new project (as XML subproject, Jakarta subproject, XML
   Commons, Apache Commons, Jakarta Commons)
3. into a separate place in xml-fop, thus staying in FOP but becoming
   some kind of sub-subproject.

Jeremias Maerki

Reply via email to