Re: generating pdf fails depending on page layout order
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=@layout-id = $loGallery6
xsl:variable name=gallery-top-margin10.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[@pos = $prevpage and @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[@pos = $prevpage and @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 rsarg...@xmission.com
mailto:rsarg...@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
rsarg...@xmission.com mailto:rsarg...@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
Re: generating pdf fails depending on page layout order
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=@layout-id = $loGallery6
xsl:variable name=gallery-top-margin10.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[@pos = $prevpage and @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[@pos = $prevpage and @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 rsarg...@xmission.com
mailto:rsarg...@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
rsarg...@xmission.com mailto:rsarg...@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
Re: generating pdf fails depending on page layout order
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/@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@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
Re: generating pdf fails depending on page layout order
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 rsarg...@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/@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
Re: generating pdf fails depending on page layout order
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 rsarg...@xmission.com mailto:rsarg...@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/@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
Re: generating pdf fails depending on page layout order
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 rsarg...@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 rsarg...@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/@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 +
Re: generating pdf fails depending on page layout order
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-margin10.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[@pos = $prevpage and @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[@pos = $prevpage and @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 rsarg...@xmission.com
mailto:rsarg...@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
rsarg...@xmission.com mailto:rsarg...@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
Re: generating pdf fails depending on page layout order
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@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 -- Pascal ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-size=1in line-height=1 fo:layout-master-set fo:simple-page-master page-width=8.5in page-height=11in master-name=gallery6-page-3 fo:region-body margin-right=0.1in margin-top=9in + 0.001pt/ /fo:simple-page-master fo:simple-page-master page-width=8.5in page-height=11in master-name=three-side-page-4 fo:region-body/ /fo:simple-page-master fo:page-sequence-master master-name=document-sequence fo:single-page-master-reference master-reference=gallery6-page-3 / fo:single-page-master-reference master-reference=three-side-page-4 / /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=document-sequence fo:flow flow-name=xsl-region-body fo:block text text text text text text text text text text text text text text /fo:block /fo:flow /fo:page-sequence
Re: generating pdf fails depending on page layout order
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). 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 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@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
