For the sake of completeness, see this message and the following ones in
the same thread:
Some non-trivial changes are indeed necessary in the table layout
code... and might be further invalidated by the new page layout
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.
> Jeremias Maerki