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


On 06/05/2012 01:37 AM, Pascal Sancho wrote:

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="@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"
<xsl:attribute name="master-name">
<xsl:value-of select="concat('gallery6-page-', position())"/>
<xsl:when test="(position() mod 2) = 0">
<xsl:attribute name="margin">
<xsl:value-of select="$leftGalleryMargins"/>
<!-- We need to fake out 3up-followed-by-gallery situation -->
<xsl:when test="//pages/page[@pos = $prevpage and @layout-id =
<fo:region-body column-count="1" margin-top="{$gallery-top-margin}"

<fo:region-body column-count="2" column-gap="{$twoColumnGap}"

     margin-top="{$gallery-top-margin}" margin-bottom="0.0in"

<xsl:attribute name="margin">
<xsl:value-of select="$rightGalleryMargins"/>
<xsl:when test="//pages/page[@pos = $prevpage and @layout-id =
<fo:region-body column-count="1" margin-top="{$gallery-top-margin}"

<fo:region-body column-count="2" column-gap="{$twoColumnGap}"

     margin-top="{$gallery-top-margin}" margin-bottom="0.0in"

<fo:region-before extent="11in" precedence="true">  <!--
     background-color="green" -->
<xsl:attribute name="region-name">
<xsl:value-of select="concat('header-gallery6-page-', position())"/>

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

     Standing by,


     On 06/04/2012 03:13 PM, Glenn Adams wrote:
     before filing a new bug, please review

     to see if the patch to that bug introduced the problem you are

     On Mon, Jun 4, 2012 at 2:07 PM, Rob Sargent
<<>>  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

         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.


         On 06/04/2012 02:05 AM, Pascal Sancho wrote:


             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

             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/@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"
                 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" />

             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 =

             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"
                 master-name="three-side-page-11" margin="0.0in 0.0in
                 0.6in 0.833in">
<fo:region-body margin-top="0.75in"
                 column-count="1" />
<fo:region-before region-name="default-right-header"
                 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:
                         Don't know how
                         to restart at

                         and Anatomy of the Cerebral Commissures]],





















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

                         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.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to