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
