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