5 Jun 2012 09:37
Re: generating pdf fails depending on page layout order
Pascal Sancho <pascal.sancho <at> takoma.fr>
2012-06-05 07:37:18 GMT
2012-06-05 07:37:18 GMT
Hi,
Thanks, Rob.
I've added minimal test case and ref. to this thread.
Le 05/06/2012 02:20, Rob Sargent a écrit :
> I've added issue #53358 - Insufficient space for line break causes error
> on zero-length region-body. My work-around is to conditionally define
> the region-body of the gallery pages as:
>
> <xsl:when test=" <at> layout-id = $loGallery6">
> <xsl:variable name="gallery-top-margin">10.99in</xsl:variable>
> <xsl:variable name="prevpage" select="position() - 1"/>
> <fo:simple-page-master page-height="11in"
> page-width="8.5in">
> <xsl:attribute name="master-name">
> <xsl:value-of select="concat('gallery6-page-', position())"/>
> </xsl:attribute>
> <xsl:choose>
> <xsl:when test="(position() mod 2) = 0">
> <xsl:attribute name="margin">
> <xsl:value-of select="$leftGalleryMargins"/>
> </xsl:attribute>
> <xsl:choose>
> <!-- We need to fake out 3up-followed-by-gallery situation -->
> <xsl:when test="//pages/page[ <at> pos = $prevpage and <at> layout-id =
> $loThreeSide]">
> <fo:region-body column-count="1" margin-top="{$gallery-top-margin}"
>
> margin-left="{$columnWidth3up}"/>
> </xsl:when>
> <xsl:otherwise>
> <fo:region-body column-count="2" column-gap="{$twoColumnGap}"
> background-color="orange"
>
> margin-top="{$gallery-top-margin}" margin-bottom="0.0in"
>
> margin-left="{$outerMargin}in"/>
> </xsl:otherwise>
> </xsl:choose>
> </xsl:when>
> <xsl:otherwise>
> <xsl:attribute name="margin">
> <xsl:value-of select="$rightGalleryMargins"/>
> </xsl:attribute>
> <xsl:choose>
> <xsl:when test="//pages/page[ <at> pos = $prevpage and <at> layout-id =
> $loThreeSide]">
> <fo:region-body column-count="1" margin-top="{$gallery-top-margin}"
>
> margin-left="{$columnWidth3up}"/>
> </xsl:when>
> <xsl:otherwise>
> <fo:region-body column-count="2" column-gap="{$twoColumnGap}"
> background-color="orange"
>
> margin-top="{$gallery-top-margin}" margin-bottom="0.0in"
>
> margin-right="{$outerMargin}in"/>
> </xsl:otherwise>
> </xsl:choose>
> </xsl:otherwise>
> </xsl:choose>
> <fo:region-before extent="11in" precedence="true" > <!--
> background-color="green" -->
> <xsl:attribute name="region-name">
> <xsl:value-of select="concat('header-gallery6-page-', position())"/>
> </xsl:attribute>
> </fo:region-before>
> </fo:simple-page-master>
> </xsl:when>
>
>
>
>
> On 06/04/2012 05:45 PM, Glenn Adams wrote:
>> ok, thanks, just wanted to check, as 0.001pt is exactly 1 millipoint
>> which is a bit of magic number in FOP, as it uses an integer
>> representation of millipoints in many computations, including the
>> epsilon in the bug I referred to below
>>
>> On Mon, Jun 4, 2012 at 4:10 PM, Rob Sargent <rsargent <at> xmission.com
>> <mailto:rsargent <at> xmission.com>> wrote:
>>
>> If I'm following along correctly, I don't think my issue is one of
>> rounding, rather one of actual layout /style/. I run into trouble
>> when the "next page" isn't of the same region-body definition AND
>> has no room for text. So far, with my conditional region-body
>> definition I'm able to bypass the issue Pascal would have me report.
>>
>> Standing by,
>>
>> rjs
>>
>>
>> On 06/04/2012 03:13 PM, Glenn Adams wrote:
>>> before filing a new bug, please review
>>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51043
>>>
>>> to see if the patch to that bug introduced the problem you are seeing
>>>
>>> On Mon, Jun 4, 2012 at 2:07 PM, Rob Sargent
>>> <rsargent <at> xmission.com <mailto:rsargent <at> xmission.com>> wrote:
>>>
>>> I ran your fo with and without the "+ 0.001pt" and indeed it
>>> fails and works as you said it would.
>>>
>>> Good news, however. Following up on your to arrange it such
>>> that the "computed i-p-d for the content equals the one of
>>> the next page", I am now creating region-body definitions for
>>> the gallery page conditional on the preceding page layout
>>> (three-side or not). This seems to be working very well so far.
>>>
>>> Would you still like me to submit the bug report. I don't
>>> feel the thread title here would be appropriate. Perhaps
>>> "Insufficient space for line break causes error on
>>> zero-length region-body" would be closer to the truth.
>>>
>>> Thanks a ton for the work-around! Saved the day, to be sure.
>>>
>>> rjs
>>>
>>>
>>>
>>> On 06/04/2012 02:05 AM, Pascal Sancho wrote:
>>>
>>> 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 <http://org.apache.fop.fo>
>>> .FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349)
>>>
>>> at org.apache.fop.fo
>>> <http://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
RSS Feed