> Since FOP 0.94 and 0.95 Beta do not have support for Table Continuation
> Labels, I would like to see if I can possible work on this for the project.
Not sure this is the simplest way to start contributing to FOP...
> I've downloaded the source files, but trying to figure out where to start is
> a big task. Can someone point me I the right direction? Where is a good
> place to start?
Of course, studying the part of the Recommendation related to
fo:retrieve-table-marker is a pre-requirement:
Once you have read it... re-read it ;-)
If you haven’t done already, get yourself familiar with the development
process in FOP.
Properly set up your development environment (especially Checkstyle):
Once you have something working, create a patch and attach it to a new
Bugzilla entry (after having run ‘ant junit’ to make sure all the tests
To implement this feature, 4 steps basically need to be performed:
- implement support for fo:retrieve-table-marker in the FO tree;
I believe this stage is more or less complete
- add the necessary code to the layout engine; this is the biggest task
- ensure the corresponding areas are added to the area tree; there
should be almost nothing to do here.
- write testcases for this new feature; we can talk about that later ;-)
You will need to have a basic understanding of the Box-Glue-Penalty
and more specifically
I can’t help you much regarding how other markers are currently handled,
since I haven’t looked at this part of the code yet. However,
org.apache.fop.fo.flow.AbstractRetrieveMarker seems like a good starting
As to what needs to be done in table, this is roughly the following:
- when headers and footers are repeated at page breaks, the
corresponding elements are put in the Penalty element that’s created
for each step in the table body. Their heights are added to the normal
length of the penalty (see
TableStepper#getCombinedKnuthElementsForRowGroup). Those heights are
computed once and for all at the beginning, which doesn’t work in
practice: this may depend on the content retrieved by the table
marker, and also on the resolved collapsed borders between the
header/footer and the body (current limitation). This needs to be
changed so that the height is updated as necessary.
- currently the Knuth elements for headers and footers are created using
the same merging algorithm as for the table’s body. This is
unnecessary since by definition headers and footers are never broken
accross pages. Treating headers and footers separately would allow to
simplify the handling of markers by avoiding to fiddle with the
merging algorithm. This should also be much more efficient since this
should become possible to re-compute only what’s necessary, instead or
relaunching the merging algorithm for every break.
To get an idea of what’s going on at the FO tree stage you can have
a look at the org.apache.fop.fo.flow.table package. For the layout stage
look at o.a.f.layoutmgr.table. Start from the
TableLayoutManager#getNextKnuthElements method and follow the method
calls. Don’t worry if you don’t get it the first time, this is quite
a complex area.
If you have any other questions, don’t hesitate to ask.
Vincent Hennebert Anyware Technologies
Apache FOP Committer FOP Development/Consulting