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

Reply via email to