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




    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    fop-users-unsubscr...@xmlgraphics.apache.org
    <mailto:fop-users-unsubscr...@xmlgraphics.apache.org>
    For additional commands, e-mail:
    fop-users-h...@xmlgraphics.apache.org
    <mailto:fop-users-h...@xmlgraphics.apache.org>



Reply via email to