xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Sargent <rsarg...@xmission.com>
Subject Re: generating pdf fails depending on page layout order
Date Fri, 01 Jun 2012 16:13:18 GMT
Thanks Pascal,

Sort of glad to know it's not just me!  Unfortunately I don't think you 
example minimal fo actually recreates my problem.  I'm trying to get the 
"gallery" page to have NO text at all, whereas you working example has 
two line of text on the "gallery" page.   The best I have attained is a 
single line of text on my gallery page by dialing in the margin-top to 
10.82in (10.83in generates the same exception, using 10.5 pt 

I should mention that in our production situation the textless gallery 
pages work just fine, except when preceded by our "three-side" layout.  
We have two symptoms: aside from the FOPException reported, in some 
cases a  single line of text appears on the gallery page.  Since, as 
I've said, I believe these two cases are related I have not generate the 
'single line of text' example.  That has it's own interesting story 
which I will refrain from telling at this time, except to confess the 
actual page-layout dimensions for the gallery pages:

<fo:simple-page-master page-width="8.5in" page-height="11in" 
master-name="gallery6-page-3" margin="0.0in 0.0in 0.6in 0.833in">
<fo:region-body margin-top="10.0in" margin-right="0.70in" 
margin-bottom="0.40in" column-gap="0.40in" column-count="2" />
<fo:region-before precedence="true" extent="9.0in" 
region-name="header-gallery6-page-3" />

<fo:simple-page-master page-width="8.5in" page-height="11in" 
master-name="three-side-page-11" margin="0.0in 0.0in 0.6in 0.833in">
<fo:region-body margin-top="0.75in" margin-right="4.3585in" 
column-count="1" />
<fo:region-before region-name="default-right-header" precedence="true" 
extent="0.50in" />
<fo:region-end extent="3.465in" region-name="three-side-start-11" />

Please advise as to how to procede.  Happy to register the failure 
you've isolated (though I don't understand why the "fail" case doesn't 
generate one-line of text on the first page?).Should I enter another on 
the negative interplay of the two page layouts?

On 06/01/2012 03:15 AM, Pascal Sancho wrote:
> Hi Rob,
> sure you are facing a bug:
> when there is no room on 1 page to insert a line-break, then, if IPD 
> change on next page, the described FOPException is thrown.
> See the attached minimal XSL-FO: when you remove the expression
>  " + 0.001pt" from the margin-top value, it works like charm.
> Can you please fill in a bug on FOP bug list, attaching this minimal 
> As a workaround, you should decrease the margin-top of your 
> simple-page-master "gallery6-page-3" (leaving room for 2 * line-height,
> and/or add a break-before on the %block% that come in 1st place of 
> your page 4.
> Le 01/06/2012 04:00, Rob Sargent a écrit :
>> 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@61f93f69[@id=]],
>>     NonLeafPos:399(BlockContainer@52ab9d99[@id=group-Normal Development
>>     and Anatomy of the Cerebral Commissures]],
>>     NonLeafPos:106(BlockContainer@e09d7b9[@id=]],
>>     NonLeafPos:7(Block@58a2b90b[@id=]], LeafPos:-1(pos=29,
>>     lm=Block@58a2b90b[@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@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message