We're using FOP-1.0.

Admittedly it may be a stretch to call these "simple" page layouts but the attached FOs show that the ordering of the page layouts can cause the generation of the pdf to fail.  The fo-fails.xml exists with

Caused by: java.lang.UnsupportedOperationException: Don't know how to restart at positionNonLeafPos:927(Flow <at> 61f93f69[ <at> id=]], NonLeafPos:399(BlockContainer <at> 52ab9d99[ <at> id=group-Normal Development and Anatomy of the Cerebral Commissures]], NonLeafPos:106(BlockContainer <at> e09d7b9[ <at> id=]], NonLeafPos:7(Block <at> 58a2b90b[ <at> id=]], LeafPos:-1(pos=29, lm=Block <at> 58a2b90b[ <at> id=]])))))
    at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:377)
    at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:85)
    at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107)
    at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238)
    at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120)
    at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349)
    at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
    at com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
    at org.jdom.output.SAXOutputter.endElement(SAXOutputter.java:1046)
    at org.jdom.output.SAXOutputter.element(SAXOutputter.java:903)
    at org.jdom.output.SAXOutputter.elementContent(SAXOutputter.java:1093)
    at org.jdom.output.SAXOutputter.elementContent(SAXOutputter.java:1067)
    at org.jdom.output.SAXOutputter.element(SAXOutputter.java:897)
    at org.jdom.output.SAXOutputter.output(SAXOutputter.java:621)
    at org.jdom.transform.JDOMSource$DocumentReader.parse(JDOMSource.java:476)
    at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:636)
    at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:707)
    ... 7 more

Some explaintion of the intent:  The "three-side-page-*" s-m-ps usurp a two-column text xsl-region body placing a static region over one of the columns and the gallery6-page-* attempt to set the size of the region-body to zero (creating a 'text-less' page).

Note that the gallery6-page-* layout was recently reworked to be textless.  Prior to that (developed originally in FOP-0.95) we had an inch of text available and detected no order dependency amongst the orderings of layouts.

And yes the s-m-ps are generated on the fly by the xsl translation, whereby a static page definitions is loaded into a page-number specific master, also left/right adjusted.

Furthermore, in other we also experience a single line of text on the gallery6-page-*s only when preceded by a three-side-page-* s-m-p. If necessary I will report that as a separate issue, but at this point I'm hoping both symptoms are tightly related.

Any work-around much appreciated.  If requested, I'm more than willing to report this as a bug.  Unfortunately we cannot wait for FOP-1.1 but we could run off the trunk.

As I see it the diffs in the two attached FO's are entirely in the static-regions as one would expect.

We're at crunch time and could go back to the original definition of gallery6-page* but would /really/ rather not.

Cheers,

rjs

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe <at> xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help <at> xmlgraphics.apache.org