xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Sargent <rsarg...@xmission.com>
Subject Re: generating pdf fails depending on page layout order
Date Tue, 05 Jun 2012 15:06:22 GMT
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-margin">10.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 <rsargent@xmission.com
>>> <mailto:rsargent@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
>>>> <rsargent@xmission.com <mailto: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 <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.
>>>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message