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.

Just so you know what you're getting yourself into. ;-)

Then again, we're here for you, if you get stuck.

Cheers

Andreas

Reply via email to