Bug 41500 - ClassCastException when fo:wrapper is used as a child of fo:block-container
Summary: ClassCastException when fo:wrapper is used as a child of fo:block-container
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: trunk
Hardware: PC Windows XP
: P1 blocker
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-30 15:32 UTC by Roberto Cisternino
Modified: 2012-04-01 06:29 UTC (History)
0 users



Attachments
FO source do generate the error (transforming to PDF) (60.31 KB, text/plain)
2007-01-31 10:48 UTC, Roberto Cisternino
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roberto Cisternino 2007-01-30 15:32:15 UTC
Below please find the error trace, the same error was available using 0.92 
beta.

Exception in thread "AWT-EventQueue-0" 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.getN
extKnuthElements(BlockContainerLayoutManager.java:612)
        at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList
(AbstractBreaker.java:554)
        at org.apache.fop.layoutmgr.AbstractBreaker.doLayout
(AbstractBreaker.java:301)
        at 
org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements
(BlockContainerLayoutManager.java:355)
        at 
org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements
(TableCellLayoutManager.java:168)
        at 
org.apache.fop.layoutmgr.table.TableContentLayoutManager.createElementsForRowGr
oup(TableContentLayoutManager.java:480)
        at 
org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRow
Iterator(TableContentLayoutManager.java:243)
        at 
org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements
(TableContentLayoutManager.java:183)
        at 
org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements
(TableLayoutManager.java:229)
        at 
org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements
(TableCellLayoutManager.java:168)
        at 
org.apache.fop.layoutmgr.table.TableContentLayoutManager.createElementsForRowGr
oup(TableContentLayoutManager.java:480)
        at 
org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRow
Iterator(TableContentLayoutManager.java:243)
        at 
org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements
(TableContentLayoutManager.java:183)
        at 
org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements
(TableLayoutManager.java:229)
        at 
org.apache.fop.layoutmgr.StaticContentLayoutManager$StaticContentBreaker.getNex
tKnuthElements(StaticContentLayoutManager.java:317)
        at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList
(AbstractBreaker.java:554)
        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:771)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage
(PageSequenceLayoutManager.java:777)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.makeNewPage
(PageSequenceLayoutManager.java:741)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.handleBreakTrait
(PageSequenceLayoutManager.java:827)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.access$300
(PageSequenceLayoutManager.java:62)
        at 
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.startPart
(PageSequenceLayoutManager.java:505)
        at org.apache.fop.layoutmgr.AbstractBreaker.addAreas
(AbstractBreaker.java:420)
        at org.apache.fop.layoutmgr.AbstractBreaker.addAreas
(AbstractBreaker.java:370)
        at 
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.doPhase3
(PageSequenceLayoutManager.java:369)
        at org.apache.fop.layoutmgr.AbstractBreaker.doLayout
(AbstractBreaker.java:345)
        at org.apache.fop.layoutmgr.AbstractBreaker.doLayout
(AbstractBreaker.java:263)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout
(PageSequenceLayoutManager.java:157)
        at org.apache.fop.area.AreaTreeHandler.endPageSequence
(AreaTreeHandler.java:385)
        at org.apache.fop.fo.pagination.PageSequence.endOfNode
(PageSequence.java:148)
        at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement
(FOTreeBuilder.java:378)
        at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
        at net.sf.saxon.event.ContentHandlerProxy.endElement
(ContentHandlerProxy.java:205)
        at net.sf.saxon.event.ProxyReceiver.endElement(ProxyReceiver.java:161)
        at net.sf.saxon.event.NamespaceReducer.endElement
(NamespaceReducer.java:184)
        at net.sf.saxon.event.ComplexContentOutputter.endElement
(ComplexContentOutputter.java:325)
        at net.sf.saxon.instruct.ElementCreator.processLeavingTail
(ElementCreator.java:186)
        at net.sf.saxon.instruct.Instruction.process(Instruction.java:166)
        at net.sf.saxon.instruct.Instruction.processChildren
(Instruction.java:208)
        at net.sf.saxon.instruct.ElementCreator.processLeavingTail
(ElementCreator.java:183)
        at net.sf.saxon.instruct.Instruction.processChildrenLeavingTail
(Instruction.java:269)
        at net.sf.saxon.instruct.Sequence.processLeavingTail(Sequence.java:147)
        at net.sf.saxon.instruct.Template.expand(Template.java:105)
        at 
net.sf.saxon.instruct.CallTemplate$CallTemplatePackage.processLeavingTail
(CallTemplate.java:235)
        at net.sf.saxon.Controller.applyTemplates(Controller.java:284)
        at 
net.sf.saxon.instruct.ApplyTemplates$ApplyTemplatesPackage.processLeavingTail
(ApplyTemplates.java:143)
        at net.sf.saxon.Controller.applyTemplates(Controller.java:284)
        at net.sf.saxon.Controller.run(Controller.java:187)
        at net.sf.saxon.Controller.transformDocument(Controller.java:1536)
        at net.sf.saxon.Controller.transform(Controller.java:1342)
Comment 1 Roberto Cisternino 2007-01-30 15:33:54 UTC
Transformation has been made using SAXON 7.9.1
Comment 2 Manuel Mall 2007-01-30 15:55:11 UTC
Any chance of attaching an FO file demonstrating the problem? Not XML + XSLT  
just plain FO please.
Comment 3 Roberto Cisternino 2007-01-31 10:48:28 UTC
Created attachment 19491 [details]
FO source do generate the error (transforming to PDF)
Comment 4 Jeremias Maerki 2007-01-31 12:16:00 UTC
The problem appears as fo:wrapper is used as a direct child of
fo:block-container with block-level content. As documented in
http://xmlgraphics.apache.org/fop/compliance.html#fo-object-wrapper fo:wrapper
is currently only working properly around inline-level content. The work-around
at the moment is to use fo:block instead of fo:wrapper.

Let's keep this bug open until the implementation is fully finished for
fo:wrapper. Thanks for the test case.
Comment 5 Lars Marius Garshol 2008-04-10 05:07:18 UTC
For the record: this bug still exists in FOP 0.94 and 0.95beta. I just ran into it, and only discovered this bug after extensive searching. It would be nice if this bug was fixed. It did not exist in older FOP versions.

I was able to work around the problem thanks to the information here, though.
Comment 6 Andreas L. Delmelle 2008-04-27 01:42:48 UTC
FWIW, the following implementation of BlockContainerLayoutManager.wrapPositionElements() seems to fix the issue:

---
    protected void wrapPositionElements(List sourceList, List targetList, boolean force) {
          
        ListIterator listIter = sourceList.listIterator();
        Object tempElement;
        while (listIter.hasNext()) {
            tempElement = listIter.next();
            if (tempElement instanceof ListElement) {
                wrapPositionElement(
                        (ListElement) tempElement,
                        targetList,
                        force);
            } else if (tempElement instanceof List) {
                wrapPositionElements(
                        (List) tempElement, 
                        targetList,
                        force);
            }
        }
    }
---

Haven't committed it, since I still need to do some more thorough checking, and I'm not sure if this is the best way to avoid this error.
The problem is that the original implementation assumes that all the elements of the list will be instances of ListElement, where the WrapperLayoutManager generates an InlineKnuthSequence. This quick and dirty fix simply takes this possibility into account and changes the behavior in that case.
Comment 7 Andreas L. Delmelle 2008-04-27 01:46:16 UTC
(In reply to comment #6)
> FWIW, the following implementation of
> BlockContainerLayoutManager.wrapPositionElements() seems to fix the issue:

Correction: BlockStackingLM.wrapPositionElements()...
Comment 8 Andreas L. Delmelle 2008-05-07 00:36:03 UTC
In the meantime, I performed some further test with the proposed change, and it definitely still needs work, but this is a more general issue: if the wrapper has text-children, we get a new ClassCastException in BlockContainerLM.addAreas(), since it does not count on InlineArea children (and nor should it).

If the wrapper contains an inline-child, FOP correctly throws a ValidationException, since an inline is not allowed as a child of the block-container. Text-nodes currently are not validated.

I've begun implementing such validation in Wrapper, but stumbled upon issues with white-space. Since the parser reports all character data (as it is supposed to), we also receive characters() events for white-space that may or may not be considered ignorable. Mainly this latter concern made me think that it might be better to fold that type of validation into the white-space handling loop (as in: only throw a ValidationException in case non-white-space characters remain after applying white-space-treatment).

If not, then we would add yet another loop over the character array... I'd like to avoid this somehow.
Comment 9 Andreas L. Delmelle 2008-05-07 07:06:24 UTC
Fixed in FOP Trunk.

See: http://svn.apache.org/viewvc?rev=654111&view=rev

Thanks for reporting!
Comment 10 Glenn Adams 2012-04-01 06:29:40 UTC
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed