Bug 47530

Created attachment 23983 [details]
Sample (but a bit complex) fo file to reproduce the problem..

After a bit of work, I've managed to make a patch overcoming this bug.

See attached patch, and simplified fo file to reproduce the problem.

Greets.

Created attachment 23984 [details]
Simplified failing fo file.

Created attachment 23985 [details]
Patch fixing the problem..

Not sure what to do with this. The patch just seems copied over from FOP Trunk (?)

The 0.94 release is considered final, and no changes are made anymore to the corresponding development branch. If you really need the fix, then it is recommended to use the more recent version.

Anyway, may be good to have in the archives for people that are stuck on 0.94, but still a WONTFIX...

The patch includes some fixes back-ported from turnk.. But the following code was not at trunk, nor 0.95.. see near the end of the patch.

Also, the problem can be reproduced with 0.95, but bugzilla didnt allow me to select more than one version.. 

So i'm pretty sure this is a fix needed on trunk..

diff -Nru fop-0.94-orig/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java fop-0.94-src/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
--- fop-0.94-orig/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java	2007-04-03 21:40:14.000000000 +0200
+++ fop-0.94-src/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java	2009-07-15 04:09:21.000000000 +0200
@@ -65,6 +65,7 @@
     
     // When viewport should grow with the content.
     private boolean autoHeight = true; 
+    private boolean inlineElementList = false;
     
     /* holds the (one-time use) fo:block space-before
     and -after properties.  Large fo:blocks are split
@@ -205,6 +206,10 @@
             //(i.e., it depends on content's blockprogression-dimension)" (XSL 1.0, 7.14.1)
             allocBPD = maxbpd;
             autoHeight = true;
+            if (getBlockContainerFO().getReferenceOrientation() == 0) {
+                //Cannot easily inline element list when ref-or="180" 
+                inlineElementList = true;
+            }
         } else {
             allocBPD = height.getValue(this); //this is the content-height
             allocBPD += getBPIndents();
@@ -267,13 +272,22 @@
         addKnuthElementsForBorderPaddingBefore(returnList, !firstVisibleMarkServed);
         firstVisibleMarkServed = true;
 
-        if (autoHeight) {
+        if (autoHeight && inlineElementList) {
             //Spaces, border and padding to be repeated at each break
             addPendingMarks(context);
 
+	    LayoutManager tmpLM;
             BlockLevelLayoutManager curLM; // currently active LM
             BlockLevelLayoutManager prevLM = null; // previously active LM
-            while ((curLM = (BlockLevelLayoutManager) getChildLM()) != null) {
+            while ((tmpLM = (LayoutManager) getChildLM()) != null) {
+		if (!(tmpLM instanceof BlockLevelLayoutManager)) {
+	                log.error("area of type: "+ tmpLM.getClass().getName() + " not allowed under flow - ignoring");
+        	        tmpLM.setFinished(true);
+                	continue;
+	        }
+
+		curLM = (BlockLevelLayoutManager)tmpLM;
+
                 LayoutContext childLC = new LayoutContext(0);
                 childLC.copyPendingMarksFrom(context);
                 // curLM is a ?

I see... Checked and confirmed. The sample testcase fails validation in fop-trunk, but that was easily fixed by removing the rowspan from the table-cell.

After doing that, I get the ClassCastException too. Also occurs if you remove the block-container from the picture. 
At any rate, I think the fix is even simpler. In that particular code-blocks, there seems to be no reason whatsoever to use the BlockLevelLM interface and we can simply declare the variables as plain LayoutManager. We can use a similar check as is now made in FlowLM (in trunk), since the wrapper should definitely not be ignored. If it only contains an empty block, it makes no difference, but if the block has content, then that should be rendered normally.
The check should probably be factored into a separate method to avoid unnecessary code-duplication. The fact that I had this fixed for FlowLM at some point, and now the same issue still exists for two other BlockStackingLMs just screams for improvement...

Thanks for reporting!

Currently experiencing this problem with trunk revision 834135 and,

  [...]
  <fo:list-item-body>
    <fo:wrapper>
      [...]
    </fo:wrapper>
  </fo:list-item-body>
  [...]

java.lang.ClassCastException: org.apache.fop.layoutmgr.InlineKnuthSequence canno
t be cast to org.apache.fop.layoutmgr.ListElement
        at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:302)
        at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130)
        at org.apache.fop.cli.Main.startFOP(Main.java:174)
        at org.apache.fop.cli.Main.main(Main.java:205)

Created attachment 26611 [details]
potential fix

Attached patch fixes the issue (+ updates test case wrapper_block.xml), for all potential parents to the fo:wrapper except fo:list-item-label.

One additional issue with wrappers as children of a regular block pops up (see comment in test case), but that is not related to this one.

Created attachment 26613 [details]
revised patch

Slightly revised patch, attempting at the same time to suppress the spurious lineArea produced by the second example in the test case. So far, only managed to reduce the lineArea's bpd to 0.

Given bug 50724, it may prove necessary to revise the whole approach... We need to make sure addAreas() is called once for every page the wrapper appears on, etc. Maybe, share more with InlineLayoutManager than LeafNodeLayoutManager?

this bug has no FO test input file on which to perform a test on current trunk; the obsoleted "Simplified failing fo file" is not usable due to failing for other reasons; please submit an input test file to obtain any further action on this bug, otherwise it will be moved to resolved+wontfix; alternatively, and better, close this bug and file a new bug based on the current state of trunk, providing new patch and input test file

resetting P2 open bugs to P3 pending further review

increase priority for bugs with a patch

see http://wiki.apache.org/xmlgraphics-fop/Design/XslFo/Wrapper