Pascal Sancho | 5 Jun 2012 17:12
Picon
Favicon

Re: generating pdf fails depending on page layout order

Rob,

Your FO test case was OK.
I just posted a very minimal FO that reproduce your's output, removing 
whatever doesn't help in finding bug.

Le 05/06/2012 17:06, Rob Sargent a écrit :
> I'm sorry.  Did I not include your "+ 0.001pt" example in my bug report?
> I certainly tried to...
>
> rjs
>
> On 06/05/2012 01:37 AM, Pascal Sancho wrote:
>> 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

Gmane