For the sake of completeness, see this message and the following ones in
the same thread:<[EMAIL

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
>>> 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

Reply via email to