You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bonekrusher <dj...@yahoo.com> on 2008/05/19 13:31:57 UTC
Adding Table Continuation Label support
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.
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?
Regards,
Bones
--
View this message in context: http://www.nabble.com/Adding-Table-Continuation-Label-support-tp17316648p17316648.html
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Adding Table Continuation Label support
Posted by bonekrusher <dj...@yahoo.com>.
Thank you Vincent and Andreas for all your help. Indeed I have my homework
to do. Read.. read and reread :). I will try to digest what you both have
written and see what I can come up with.
Thanks Again,
Bones
Andreas Delmelle-2 wrote:
>
> On May 19, 2008, at 17:08, Vincent Hennebert wrote:
>
> Hi
>
>> 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.
>>
>> 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
>
> Indeed. I added this recently. The only thing currently incomplete is
> support for retrieve-table-markers as substitutes for the header/
> footer. (It seems like the Recommendation offers the possibility of
> putting the entire fo:table-header element in a fo:marker... Adrian
> pointed this out after I committed. As Vincent points out: read /and/
> re-read ;-))
>
>
>> <snip />
>> 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.
>
> The key point here is PageSequenceLayoutManager.resolveRetrieveMarker
> () which is called from AbstractLayoutManager.createChildLMs() (for
> the subclass StaticContentLayoutManager).
>
> <snip />
>> However,
>> org.apache.fop.fo.flow.AbstractRetrieveMarker seems like a good
>> starting
>> point.
>
> This contains the basic code for cloning the marker. Normally, this
> should not need any changes (apart from cleaning up some unrelated
> TODOs...)
> While it may be of educational value to browse through, it does not
> contain anything specific wrt the actual marker-resolution. It only
> contains the mechanism for the marker-duplication: cloning the
> subtree, evaluating property expressions in the proper context,
> triggering white-space-handling.
> This is all done because one fo:marker may be retrieved multiple
> times into different contexts, so it's important to separate the
> retrieved copy from the original.
>
> The main challenge in the layoutengine, as I see it is that, for
> marker-retrieval to work (on page-level), the cells in the table-body
> have to have 'added' their markers (see
> AbstractLayoutManager.addMarkersToPage(), which is called from
> addAreas()).
> In normal flow-layout, the marker-retrieval is triggered by the
> StaticContentLayoutManager.createChildLMs(), which is activated /
> after/ the areas for the Flow have been added to the body-region for
> the current page-viewport.
>
>
> Just my 2 cents...
>
> Cheers
>
> Andreas
>
--
View this message in context: http://www.nabble.com/Adding-Table-Continuation-Label-support-tp17316648p17337801.html
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Adding Table Continuation Label support
Posted by Andreas Delmelle <an...@telenet.be>.
On May 19, 2008, at 17:08, Vincent Hennebert wrote:
Hi
> 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.
>
> 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
Indeed. I added this recently. The only thing currently incomplete is
support for retrieve-table-markers as substitutes for the header/
footer. (It seems like the Recommendation offers the possibility of
putting the entire fo:table-header element in a fo:marker... Adrian
pointed this out after I committed. As Vincent points out: read /and/
re-read ;-))
> <snip />
> 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.
The key point here is PageSequenceLayoutManager.resolveRetrieveMarker
() which is called from AbstractLayoutManager.createChildLMs() (for
the subclass StaticContentLayoutManager).
<snip />
> However,
> org.apache.fop.fo.flow.AbstractRetrieveMarker seems like a good
> starting
> point.
This contains the basic code for cloning the marker. Normally, this
should not need any changes (apart from cleaning up some unrelated
TODOs...)
While it may be of educational value to browse through, it does not
contain anything specific wrt the actual marker-resolution. It only
contains the mechanism for the marker-duplication: cloning the
subtree, evaluating property expressions in the proper context,
triggering white-space-handling.
This is all done because one fo:marker may be retrieved multiple
times into different contexts, so it's important to separate the
retrieved copy from the original.
The main challenge in the layoutengine, as I see it is that, for
marker-retrieval to work (on page-level), the cells in the table-body
have to have 'added' their markers (see
AbstractLayoutManager.addMarkersToPage(), which is called from
addAreas()).
In normal flow-layout, the marker-retrieval is triggered by the
StaticContentLayoutManager.createChildLMs(), which is activated /
after/ the areas for the Flow have been added to the body-region for
the current page-viewport.
Just my 2 cents...
Cheers
Andreas
Re: Adding Table Continuation Label support
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
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