Hi Bones,

bonekrusher wrote:
> Hi,
>
> 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...
anyway... welcome!


> 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:
http://www.w3.org/TR/xsl11/#fo_retrieve-table-marker
Once you have read it... re-read it ;-)

If you haven’t done already, get yourself familiar with the development
process in FOP.
http://xmlgraphics.apache.org/fop/dev/index.html
Properly set up your development environment (especially Checkstyle):
http://xmlgraphics.apache.org/fop/dev/conventions.html
http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide

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
are passing):
https://issues.apache.org/bugzilla/index.cgi


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
model:
http://wiki.apache.org/xmlgraphics-fop/DeveloperPages
and more specifically
http://wiki.apache.org/xmlgraphics-fop/KnuthsModel

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

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
  TableContentLayoutManager#getNextKnuthElements and
  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.

Good luck!
Vincent


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Reply via email to