please rewrite bug report in terms of XSL-FO (not XSLT), provide an FO input file and a PDF output file exhibiting problem

also, see http://xmlgraphics.apache.org/fop/compliance.html#fo-property-keep-with-next

Created attachment 27859 [details]
zip file containing riddle.fo and riddle.pdf file

Apache FOP does not properly handle the <xsl:attribute
name="keep-with-next.within-page">always</xsl:attribute> and <xsl:attribute
name="keep-together.within-page">always</xsl:attribute> options in basic
blocks.

You will notice from the PDF snap that the Apache FOP places a break between
2.1.1. Bay: 25 and its accompanying image. (To get to this section in the PDF expand Section 2. Substation Riddle Section 2.1. Voltage level: D).

I have compared Apache FOP (Vrsn: fop-1.0) with RenderX XEP (Vrsn: xep-4.19-20110414) XSL-FO using processors using XMLmind XSL Utility (Vrsn: 4.5.0-01) to render DITA Files into PDF format. The Apache FOP does not properly handle the <xsl:attribute name="keep-with-next.within-page">always</xsl:attribute> option.

(In reply to comment #2)
> Created attachment 27859 [details]
> zip file containing riddle.fo and riddle.pdf file
> 
> Apache FOP does not properly handle the <xsl:attribute
> name="keep-with-next.within-page">always</xsl:attribute> and <xsl:attribute
> name="keep-together.within-page">always</xsl:attribute> options in basic
> blocks.
> 
> You will notice from the PDF snap that the Apache FOP places a break between
> 2.1.1. Bay: 25 and its accompanying image. (To get to this section in the PDF
> expand Section 2. Substation Riddle Section 2.1. Voltage level: D).
> 
> I have compared Apache FOP (Vrsn: fop-1.0) with RenderX XEP (Vrsn:
> xep-4.19-20110414) XSL-FO using processors using XMLmind XSL Utility (Vrsn:
> 4.5.0-01) to render DITA Files into PDF format. The Apache FOP does not
> properly handle the <xsl:attribute
> name="keep-with-next.within-page">always</xsl:attribute> option.

Your description of the problem remains in the XSLT domain, not XSL-FO.

There is no such thing as <xsl:attribute name="keep-with-next.within-page">always</xsl:attribute> in XSL-FO.

In XSL-FO, this is a property on an FO object, e.g.,

<fo:block keep-with-next.within-page="always">...</fo:block>

Also, I would advise you to try to narrow down the problem to the smallest XSL-FO input that reproduces the problem. It is difficult to have to wade through the 1MB riddle.fo file to look for the problem area, which I see is contained in the following XSL-FO fragment:

<fo:block space-before.optimum="1.5em" space-before.minimum="1.2em" space-before.maximum="1.8em" space-after.optimum="0.75em" space-after.minimum="0.6em" space-after.maximum="0.9em" hyphenate="false" font-family="sans-serif" font-weight="bold" text-align="left" keep-with-next.within-column="always" font-size="140%" padding-bottom="0.05em" border-bottom="0.6pt solid blue" keep-with-next.within-page="always">2.1.1. Bay: 25
</fo:block>
<fo:block space-before.optimum="0.75em" space-before.minimum="0.6em" space-before.maximum="0.9em" space-after.optimum="0.75em" space-after.minimum="0.6em" space-after.maximum="0.9em">
  <fo:block space-before.optimum="0.75em" space-before.minimum="0.6em" space-before.maximum="0.9em" space-after.optimum="0.75em" space-after.minimum="0.6em" space-after.maximum="0.9em" id="_4WuGAAEqEeG8i4jXCiAfTQ__I_io3oa_">
    <fo:block space-before.optimum="0.75em" space-before.minimum="0.6em" space-before.maximum="0.9em" space-after.optimum="0.75em" space-after.minimum="0.6em" space-after.maximum="0.9em" hyphenate="false" font-family="sans-serif" font-weight="bold" text-align="left" keep-with-next.within-column="always" font-size="120%"/>
    <fo:block space-before.optimum="1.5em" space-before.minimum="1em" space-before.maximum="2em"
space-after.optimum="1.5em" space-after.minimum="1em" space-after.maximum="2em" id="_4WuGAAEqEeG8i4jXCiAfTQ__I_d16yk_">
      <fo:block border-before-width.conditionality="discard" border-after-width.conditionality="discard">
        <fo:block space-before.optimum="0.75em" space-before.minimum="0.6em" space-before.maximum="0.9em" space-after.optimum="0.75em" space-after.minimum="0.6em" space-after.maximum="0.9em" font-size="110%" text-indent="1em"/>
        <fo:block text-align="center">
          <fo:external-graphic src="url(file:/C:/helinks/workspace/workspaces/r2be/build.com.helinks.sts/workspaces/riddle/Report/items/Ridde_D_25_fun.png)" content-width="247px"/>
        </fo:block>
      </fo:block>
      <fo:block hyphenate="false" font-style="italic" space-before.optimum="0.5em" space-before.minimum="0.4em" space-before.maximum="0.6em" space-after.optimum="0.5em" space-after.minimum="0.4em" space-after.maximum="0.6em" text-align="left" keep-with-previous.within-column="always">Figure 2. Function Diagram of Ridde/D/25</fo:block>
    </fo:block>
  </fo:block>
</fo:block>
</fo:block>

For example, if you started with the above fragment, then removed as much extraneous material that still exhibits the problem, then you would have reduced it to a manageable level.

Finally, note that there is already a test for keep-with-next.within-page="always" in the FOP test suite (I will attach an edited version of this test to this bug report which you can use as a template). Perhaps you could verify this yourself and then modify this using your minimal data to try to reproduce your problem.

Created attachment 27860 [details]
current FO test content for keep-with-next.within-page on fo:block

See comment 3.

Created attachment 27864 [details]
"keep-with-next-problem.zip" containing files to examine "keep-with-next" problem

Hi Glenn,

  i have created a new project to run tests against the keep-with-next.within-page="always" property on an FO object.

The XSL-FO for the project is included in the "keep-with-next-problem.zip" called "mytest.fo".

To help narrow down the <fo:block keep-with-next.within-page="always">...</fo:block> where i believe there is a problem i have extracted from the" mytest.fo" file, with my limited knowledge about Appache FOP, as well as i could two places where the problem occurs.

These blocks i have saved to the files "keep-with-next-problem1.fo" and "keep-with-next-problem1.fo". These files are also included in the  "keep-with-next-problem.zip" file.

In mytest.pdf file the "keep-with-next" problem can be viewed in two locations. The first location 1.1. MySubstaion SLD Diagram. The second location is where 2.1.1. Bay: Bay1. In both places you will see that the section heading is segregated from its image.

According to the "Keeps and Breaks Properties" in the W3C XSL-FO 1.1 standard compliance table my understanding of the "keep-with-next" property is that it supposed to keep both the section heading and image together providing that the implemented block-level FOs are not inline-level FOs or integer specified. I have run my tests with the "keep-together" property and this does not seem to be the case.

To get a real sense of how the "keep-with-next" and "keep-together" i have run my tests against RenderX XEP (Vrsn: xep-4.19-20110414) XSL-FO and sure enough both the section heading and image together are keep together.

Despite the fact that you have created a wonderful template where i can insert the problematic blocks to be run against the "keep-with-next.within-page="always" test case" I am not experienced enough to know how to do this yet, and if so doing whether or not i am doing it right to determine whether indeed there is a problem.

Please let me know if the information and files i have included in this report is sufficient for you to examine this matter.

Regards,
Alberto Perri

For additional comments see "keep-with-next-problem.zip" containing files to examine "keep-with-next" problem Details

resetting P2 open bugs to P3 pending further review

i'm afraid i need to ask you to work harder to provide a "maximally minimal" but *complete* input FO test file and corresponding output PDF file that demonstrates the problem (along with any external graphics that are referenced by this maximally minimal FO file)

the two keep-with-next-problem* files are (1) not complete FO files, and (2) not maximally minimal;

by maximally minimal, I mean you should remove all constructs of the FO file until you are able to remove nothing else while still demonstrating the problem

Dear Apache Team,

  i am not an xml expert so please excuse me if i am using the XML terminology incorrectly. 

  What i reported now several months ago is not a bug but a great misunderstanding on my part. When using the keep-together or keep-with-next FO Attributes it is important to know which elements you want to keep together. There must be at least two different elements/blocks that have this attribute. My experience is that if this is not specified nothing will happen. I realized this when at the request of Glenn Adams i went about butting together a "maximally minimal" but *complete* input FO test file and corresponding output PDF file that
demonstrates the problem (along with any external graphics that are referenced
by this maximally minimal FO file).

Dear Apache Team,

  i am not an xml expert so please excuse me if i am using the XML terminology incorrectly. 

  What i reported now several months ago is not a bug but a great misunderstanding on my part. When using the keep-together or keep-with-next FO Attributes it is important to know which elements you want to keep together. There must be at least two different elements/blocks that have this attribute. My experience is that if this is not specified nothing will happen. I realized this when at the request of Glenn Adams i went about butting together a "maximally minimal" but *complete* input FO test file and corresponding output PDF file that
demonstrates the problem (along with any external graphics that are referenced
by this maximally minimal FO file).  

Please find in the RiddleTest.rar file the files Riddle.fo, Riddle.png, RiddleSysteDiagram.png and Riddle.pdf that demonstrate that the keep-together attribute does indeed work.

Created attachment 28634 [details]
keep-together attribute used correctly

per reporter, the problem was the user's misunderstanding rather than a behavior or feature problem

batch transition resolved+wontfix to closed+wontfix

batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen