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