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)
Transformation has been made using SAXON 7.9.1
Any chance of attaching an FO file demonstrating the problem? Not XML + XSLT just plain FO please.
Created attachment 19491 [details] FO source do generate the error (transforming to PDF)
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.
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.
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.
(In reply to comment #6) > FWIW, the following implementation of > BlockContainerLayoutManager.wrapPositionElements() seems to fix the issue: Correction: BlockStackingLM.wrapPositionElements()...
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.
Fixed in FOP Trunk. See: http://svn.apache.org/viewvc?rev=654111&view=rev Thanks for reporting!
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed