xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Adams <gl...@skynav.com>
Subject Re: generating pdf fails depending on page layout order
Date Mon, 04 Jun 2012 21:13:21 GMT
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 <rsargent@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-unsubscribe@xmlgraphics.apache.org>
> For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.org<fop-users-help@xmlgraphics.apache.org>
>
>

Mime
View raw message