You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jean-François El Fouly <je...@elfouly.fr> on 2008/09/02 11:21:09 UTC

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:block>Table 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

Posted by Andreas Delmelle <an...@telenet.be>.
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

Re: A (long) question on implementing fo:retrieve-table-marker

Posted by Andreas Delmelle <an...@telenet.be>.
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:block>Table 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

Posted by Andreas Delmelle <an...@telenet.be>.
On Sep 2, 2008, at 11:21, Jean-François El Fouly wrote:

> <snip />
> 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.
> *

Indeed, a shortcoming. There is one other case: the entire header/ 
footer can be contained within an fo:marker. This will currently also  
throw a ValidationException.

<snip />
> 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).

The best way to go about it is probably to check the ancestry of the  
fo:marker before validating the child node. If the marker appears as  
a descendant of an arbitrary fo:table, then fo:table-row is allowed.  
However, we need to watch out because the same fo:marker could be  
retrieved into a static-content, in which case the fo:table-row would  
not be valid.

So, on the one hand, the validation rule needs to be relaxed. On the  
other, the regular marker-retrieval may not be disturbed...

What Vincent pointed out earlier does not seem entirely correct to  
me. The validation is independent from the parent fo, and so should  
not be delegated, but rather /deferred/ until the marker is retrieved/ 
reparented ... and even then, if a marker with a table-row ends up  
being retrieved by a normal retrieve-marker, I think this deserves  
only a serious warning about content being ignored/skipped. (The  
author of the stylesheet should probably take care to assign these  
markers to a special marker-class, which only gets retrieved by  
retrieve-table-marker.)



HTH!

Cheers

Andreas


Re: A (long) question on implementing fo:retrieve-table-marker

Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Jean-François,

Jean-François El Fouly wrote:
> I take as reference: http://www.w3.org/TR/xsl/

<snip/>

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

That’s right.

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

Actually, just below the content model you have the following sentence:
“An fo:marker may contain any formatting objects that are permitted as
a replacement of any fo:retrieve-marker or fo:retrieve-table-marker that
retrieves the fo:marker’s children.”

Which actually is a bit inconsistent with the content model just above.
If you ever feel like mentioning this inconsistency to xsl-editors@...
I think the behaviour you get by following that sentence is sensible, so
go for it.


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

Unless I’m missing something, Marker.validateChildNode should do nothing
else than passing the call to its parent element.

HTH,
Vincetn