xml | FOTree | AreaTree | Rendered

[Clay Atkins <ca...@spcmg.com>]

I think it is possible to make some small structural changes to the
commandline classes, driver and the render classes for the purpose of
"piping" from the xml through the renderer.  It would be multi-threaded (a
performance goody for some of us) and would reduce the memory requirements.
Except for AWTRenderer, the size of the document would not be memory
dependent; AWTRenderer randomly request pages from the AreaTree.

This is something I'd like to work on sometime, but I don't know exactly how
this volunteer process works.

I'd also be glad to flesh-out some of the formatting objects, but I don't
know who is working on what.  It would be great if there was a list of the
formatting objects and their implementation status :)

RE: xml | FOTree | AreaTree | Rendered

[Clay Atkins <ca...@spcmg.com>]

I read through the documentation on who does what and when, and that makes
sense.  I want to work on things that make sense.  A problem that I would
have with using the product is the memory requirements for large documents.
The FOTree is completely built, before the AreaTree, which is completely
built before being rendered.  What I want to use the product for is
generating large reports for archives, like 1200 page account balances.
I've been experimenting with Cocoon and the SQL processor, which has a
similar problem; well, a cocoon problem since it is built on DOM.  But,
cocoon2 is suppose to be "stream" oriented (my word).

I like to argue (can you tell?).  Anyway, I'd be more than happy to
investigate any number of small issues that are pending.  Just let me know.

-----Original Message-----
From: James Tauber [mailto:jtauber@jtauber.com]
Sent: Friday, December 03, 1999 1:37 AM
To: fop-dev@xml.apache.org
Subject: Re: xml | FOTree | AreaTree | Rendered


> I think it is possible to make some small structural changes to the
> commandline classes, driver and the render classes for the purpose of
> "piping" from the xml through the renderer.

While I agree it is possible, be aware that there is backtracking and in
some cases multiple passes involved in going from FOs to Areas.

> This is something I'd like to work on sometime, but I don't know exactly
how
> this volunteer process works.

Basically, a small number of people have write access to CVS. These people
are called "committers". Anyone on this list is more than welcome to
contribute ideas, patches, entire classes, but it is up to the committers to
add it to the "official" version of FOP in the CVS. You can become a
committer on the basis of the merit of your contributions.

The xml.apache.org site has more details on this plus voting, etc.

> I'd also be glad to flesh-out some of the formatting objects, but I don't
> know who is working on what.  It would be great if there was a list of the
> formatting objects and their implementation status :)

There is a list in the README. It doesn't go into any detail, so let me know
how you'd like to see it improved.

Working on the FOs themselves (unless they are independent like SVG or
MathML) is not easy because they tend to require changes in many places.
Coordination of this was easy when I was the only developer but it is going
to be interesting how it develops from now on.

If there is something you'd like to implement, let this list know and I can
certainly say if I've had any thoughts about it already. Lurking on this
list should give you a pretty good idea of what people are working on.

I can certainly suggest little "projects" for people if they want to get
into the code.

James Tauber

Re: xml | FOTree | AreaTree | Rendered

[James Tauber <jt...@jtauber.com>]

> I think it is possible to make some small structural changes to the
> commandline classes, driver and the render classes for the purpose of
> "piping" from the xml through the renderer.

While I agree it is possible, be aware that there is backtracking and in
some cases multiple passes involved in going from FOs to Areas.

> This is something I'd like to work on sometime, but I don't know exactly
how
> this volunteer process works.

Basically, a small number of people have write access to CVS. These people
are called "committers". Anyone on this list is more than welcome to
contribute ideas, patches, entire classes, but it is up to the committers to
add it to the "official" version of FOP in the CVS. You can become a
committer on the basis of the merit of your contributions.

The xml.apache.org site has more details on this plus voting, etc.

> I'd also be glad to flesh-out some of the formatting objects, but I don't
> know who is working on what.  It would be great if there was a list of the
> formatting objects and their implementation status :)

There is a list in the README. It doesn't go into any detail, so let me know
how you'd like to see it improved.

Working on the FOs themselves (unless they are independent like SVG or
MathML) is not easy because they tend to require changes in many places.
Coordination of this was easy when I was the only developer but it is going
to be interesting how it develops from now on.

If there is something you'd like to implement, let this list know and I can
certainly say if I've had any thoughts about it already. Lurking on this
list should give you a pretty good idea of what people are working on.

I can certainly suggest little "projects" for people if they want to get
into the code.

James Tauber