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.
