Re: generating pdf fails depending on page layout order

Hi,

I have focused on the 1st issue I found. May be there are other issues 
behind.

Le 01/06/2012 18:13, Rob Sargent a écrit :
> 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
> TimesNewRomanPSMT).

Hmm?
With the XSL-FO attached to my previous email FOP throws a FOPException, 
and produces no output.
I've set both font-size and line-height to 1in (on fo:root), and the 
available b-p-d of the 1st page body is less than 2in 
(page-height="11in" - body/ <at> margin-top="9in + 0.001pt"), so there is no 
place for line break. Can you check again that you tried that example?

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

for the body of gallery6-page-3:
b-p-d is 11in - 0 - 0.6in - 10in - 0.4in = 0,
so, in case of multi-line content, there is no room for line-break, that 
cause a FOP exception if i-p-d changes on next page (this is a FOP bug).

for each column:
i-p-d = (8.5in - 0 - 0.833in - -0.7in - 0.4in) / 2 = 3.2865in

If you leave a 0 b-p-d to force an empty page, you should ensure that 
computed i-p-d for the content (here each column) equals the one of the 
next page, the issue you are facing should not occur.

> <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" />
> </fo:simple-page-master>
>
>
> 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
>> XSL-FO?
>>
>> 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 <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.

--

-- 
Pascal