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 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. >>>>> >>>> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > fop-users-unsubscribe@**xmlgraphics.apache.org<fop-users-unsubscr...@xmlgraphics.apache.org> > For additional commands, e-mail: > fop-users-help@xmlgraphics.**apache.org<fop-users-h...@xmlgraphics.apache.org> > >
