For the sake of completeness, see this message and the following ones in the same thread: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200805.mbox/<[EMAIL PROTECTED]>
Some non-trivial changes are indeed necessary in the table layout code... and might be further invalidated by the new page layout approach. Vincent Jeremias Maerki wrote: > On 01.09.2008 23:20:29 Andreas Delmelle wrote: >> On Sep 1, 2008, at 23:02, Andreas Delmelle wrote: >> >> (Moving this to fop-dev@) >> >>> On Sep 1, 2008, at 22:42, Jean-François El Fouly wrote: >>>> Hhmm... I've been quickly through the code and my first impression >>>> is that it IS implemented. >>> Not really, I'm afraid. I have prepared the implementation a while >>> ago. That much is true. FOP simply does nothing with a retrieve- >>> table-marker node, but the node is created and the properties >>> parsed. Only in layoutmgr.LayoutManagerMapping, you will notice >>> that the RetrieveTableMarker generates no LayoutManager yet. >>> >>>> I've set up a simple test case and, going through the stack trace, >>>> I guess it could be a simple bug fix, something like a bad or >>>> insufficient test in TablePart.java >>> Oh, rest assured, it's going to take a bit more thought and >>> effort... ;-) >> To spare some time looking, I see one issue that may turn out to be >> quite a challenge. >> One significant benefit is that it operates on the same fo:markers, >> so little work there, and it may even give you some ideas on how to >> solve it for the table-case, however... >> >> If you follow what happens during regular marker-retrieval, you'll >> notice that the resolution depends on the markers having been added >> to the page-viewport. >> This happens in the addAreas() phase. Later, when the page is >> finalized, the static-content is added, and at that point the markers >> are readily available. >> >> For a table-header (or -footer), there will be an additional >> difficulty, because at the point where we generate the base element >> list, the markers will not have been processed, so we cannot really >> depend on that same mechanism... Strictly speaking, we might also end >> up with borderline cases, where the table-header's height varies from >> page to page, depending on the content retrieved in the marker. Not >> sure, but the table-code may need some work to cater for this. > > Absolutely. At the moment the element list for headers and footers is > calculated once (in TableContentLayoutManager) and then used for every > break possibility (see TableHFPenaltyPosition). When > retrieve-table-markers are used you basically have to recalculate the > header and footer element lists for each break position in case the > markers change. > > That's quite a bit of processing effort that is even mostly done in vain > since most break positions won't even be used. But since we're still on > a total-fit approach, that is necessary. That should improve when > Vincent is finished with his revamping of the page breaking process. > >> Just so you know what you're getting yourself into. ;-) >> >> Then again, we're here for you, if you get stuck. >> >> Cheers >> >> Andreas >> > > > > > Jeremias Maerki
