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
