A (long) question on implementing fo:retrieve-table-marker
I take as reference: http://www.w3.org/TR/xsl/
To begin with, I've built a simple example / test case related to my
customer's needs but fairly based on the one in 6.13.1.1.2:
http://www.w3.org/TR/xsl/#d0e14681
This example looks good and though not trivial to understand at first
sight, it is a common-sense use of fo:retrieve-table-marker.
It has a sort of conditional row that is displayed (or not) in the
table footer and is defined just after table-body:
*fo:marker marker-class-name=continued
fo:table-row
fo:table-cell
fo:blockTable continued.../fo:block
/fo:table-cell
/fo:table-row
/fo:marker
*
Now if I run my test case against the trunk of FOP I get this error message:
*GRAVE: Exception
javax.xml.transform.TransformerException:
org.apache.fop.fo.ValidationException:
file:/D:/Java/fop-0.95beta/test-rtm.fo:533:112: Error(533/112):
fo:retrieve-tab
le-marker is not a valid child element of fo:table-header.
*
For the sake of clarity only let's call this a bug since
*fo-retrieve-table-marker* /is/ a valid child element of
*fo:table-header:* http://www.w3.org/TR/xsl/#fo_retrieve-table-marker
So let's read the full stack trace and fix this by adding one more
condition in *org.apache.fop.fo.flow.table.TablePart.validateChildNode()*.
The next step is where I'm puzzled and don't know how to proceed since
the W3C recommendation and the example they give seem inconsistent with
each other, while the error message FOP returns seems consistent with
the recommendation:
*GRAVE: Exception
javax.xml.transform.TransformerException:
org.apache.fop.fo.ValidationException:
{http://www.w3.org/1999/XSL/Format}table-row; is not a valid child of
fo:mark
er! (See position 557:21)
*
This error is consistent with the W3C TR:
http://www.w3.org/TR/xsl/#fo_marker
that says that the fo:marker contents is:
(#PCDATA|%inline; http://www.w3.org/TR/xsl/#inline.fo.list|%block;
http://www.w3.org/TR/xsl/#block.fo.list)*
but it makes the example they give useless (indeed, neither inline nor
block allow directly or indirectly table-row).
And so I don't quite know where I'm allowed to go from here. (If I
change a behaviour in
*org.apache.fop.fo.flow.Marker.validateChildNode()* I may end up with
something that works and fits the bill but is inconsistent with the TR).
Any comment appreciated !
Jean-Francois El Fouly
Re: A (long) question on implementing fo:retrieve-table-marker
On Sep 2, 2008, at 11:21, Jean-François El Fouly wrote: Just another hint I thought of: To begin with, I've built a simple example / test case related to my customer's needs but fairly based on the one in 6.13.1.1.2: http://www.w3.org/TR/xsl/#d0e14681 This example looks good and though not trivial to understand at first sight, it is a common-sense use of fo:retrieve-table-marker. It has a sort of conditional row that is displayed (or not) in the table footer and is defined just after table-body: *fo:marker marker-class-name=continued fo:table-row fo:table-cell fo:blockTable continued.../fo:block /fo:table-cell /fo:table-row /fo:marker * Due to the problems you ran into so far, I'd advise first trying to get the retrieval of a simple fo:block into the header/footer working. That would already help most people out who need this, I think. Once that works, extending the approach to also work with entire table-parts should prove a relatively simple exercise. Cheers Andreas
Re: A (long) question on implementing fo:retrieve-table-marker
On Sep 2, 2008, at 11:21, Jean-François El Fouly wrote: ... and another detail, to facilitate studying the process through debugging: snip / file:/D:/Java/fop-0.95beta/test-rtm.fo:533:112: Error(533/112): fo:retrieve-tab ^^^ For your own convenience, trim that testcase down! ;-) Seriously, try to generate extra space by means of space-before and/ or -after to generate multiple pages. Use an extra small page-size to limit the amount of needed content to trigger page-breaks... Generating dummy content, leading to a FO of 500+ lines, will not make the job any easier. Something I've also found helpful, in case you're unaware of it: specify ids on the FOs to easily track the corresponding FObj and their related LayoutManager in a debugger. Andreas
