Bug 47530 - [PATCH] Problem with fo:wrapper inside block-container or table-cell
[PATCH] Problem with fo:wrapper inside block-container or table-cell
Status: NEW
Product: Fop - Now in Jira
Classification: Unclassified
Component: page-master/layout
trunk
All All
: P2 normal
: ---
Assigned To: fop-dev
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2009-07-14 17:17 UTC by Pablo Ruiz
Modified: 2012-04-17 06:08 UTC (History)
0 users



Attachments
Sample (but a bit complex) fo file to reproduce the problem.. (86.15 KB, application/bar)
2009-07-14 17:19 UTC, Pablo Ruiz
Details
Simplified failing fo file. (1.08 KB, application/bar)
2009-07-14 19:20 UTC, Pablo Ruiz
Details
Patch fixing the problem.. (15.35 KB, patch)
2009-07-14 19:21 UTC, Pablo Ruiz
Details | Diff
potential fix (8.30 KB, patch)
2011-02-06 05:39 UTC, Andreas L. Delmelle
Details | Diff
revised patch (8.27 KB, patch)
2011-02-06 11:30 UTC, Andreas L. Delmelle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo Ruiz 2009-07-14 17:17:28 UTC
While trying to create a PDF file using the attached fo file as source, I got the followin error:

$ fop -fo tmpfo2.xml -pdf tmp.pdf

... removed output for brevity ...

java.lang.ClassCastException: org.apache.fop.layoutmgr.InlineKnuthSequence
        at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:168)
        at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
        at org.apache.fop.cli.Main.startFOP(Main.java:166)
        at org.apache.fop.cli.Main.main(Main.java:197)

---------

java.lang.ClassCastException: org.apache.fop.layoutmgr.InlineKnuthSequence
        at org.apache.fop.layoutmgr.BlockStackingLayoutManager.wrapPositionElements(BlockStackingLayoutManager.java:1454)
        at org.apache.fop.layoutmgr.BlockStackingLayoutManager.wrapPositionElements(BlockStackingLayoutManager.java:1439)
        at org.apache.fop.layoutmgr.BlockContainerLayoutManager$BlockContainerBreaker.getNextKnuthElements(BlockContainerLayoutManager.java:615)
        at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:551)
        at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:301)
        at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(BlockContainerLayoutManager.java:356)
        at org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:170)
        at org.apache.fop.layoutmgr.table.TableContentLayoutManager.createElementsForRowGroup(TableContentLayoutManager.java:490)
        at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:251)
        at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:179)
        at org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:243)
        at org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:170)
        at org.apache.fop.layoutmgr.table.TableContentLayoutManager.createElementsForRowGroup(TableContentLayoutManager.java:490)
        at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:251)
        at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:179)
        at org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:243)
        at org.apache.fop.layoutmgr.StaticContentLayoutManager$StaticContentBreaker.getNextKnuthElements(StaticContentLayoutManager.java:317)
        at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:551)
        at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:301)
        at org.apache.fop.layoutmgr.StaticContentLayoutManager.doLayout(StaticContentLayoutManager.java:239)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.layoutSideRegion(PageSequenceLayoutManager.java:407)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:415)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:146)
        at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:233)
        at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:145)
        at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:378)
        at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
        at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101)
        at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
        at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
        at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:165)
        at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
        at org.apache.fop.cli.Main.startFOP(Main.java:166)
        at org.apache.fop.cli.Main.main(Main.java:197)


PD: I have tried with 0.95 and 0.94 (jdk13) without success..
Comment 1 Pablo Ruiz 2009-07-14 17:19:11 UTC
Created attachment 23983 [details]
Sample (but a bit complex) fo file to reproduce the problem..
Comment 2 Pablo Ruiz 2009-07-14 19:19:42 UTC
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.
Comment 3 Pablo Ruiz 2009-07-14 19:20:32 UTC
Created attachment 23984 [details]
Simplified failing fo file.
Comment 4 Pablo Ruiz 2009-07-14 19:21:41 UTC
Created attachment 23985 [details]
Patch fixing the problem..
Comment 5 Andreas L. Delmelle 2009-07-15 13:07:07 UTC
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...
Comment 6 Pablo Ruiz 2009-07-15 13:28:32 UTC
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 ?
Comment 7 Andreas L. Delmelle 2009-07-15 13:58:34 UTC
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!
Comment 8 ms419 2009-12-01 23:19:16 UTC
Currently experiencing this problem with trunk 0 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)
Comment 9 Andreas L. Delmelle 2011-02-06 05:39:44 UTC
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.
Comment 10 Andreas L. Delmelle 2011-02-06 11:30:21 UTC
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?
Comment 11 Glenn Adams 2012-04-01 19:55:21 UTC
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
Comment 12 Glenn Adams 2012-04-07 01:43:33 UTC
resetting P2 open bugs to P3 pending further review
Comment 13 Glenn Adams 2012-04-11 03:20:49 UTC
increase priority for bugs with a patch