Fop
  1. Fop
  2. FOP-1301

ClassCastException when fo:wrapper is used as a child of fo:block-container

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: unqualified
    • Labels:
      None
    • Environment:
      Operating System: Windows XP
      Platform: PC
    • External issue ID:
      41500

      Description

      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)

      1. test.fo
        60 kB
        Roberto Cisternino

        Activity

        Hide
        Roberto Cisternino added a comment -

        Transformation has been made using SAXON 7.9.1

        Show
        Roberto Cisternino added a comment - Transformation has been made using SAXON 7.9.1
        Hide
        Manuel Mall added a comment -

        Any chance of attaching an FO file demonstrating the problem? Not XML + XSLT
        just plain FO please.

        Show
        Manuel Mall added a comment - Any chance of attaching an FO file demonstrating the problem? Not XML + XSLT just plain FO please.
        Hide
        Roberto Cisternino added a comment -

        Attachment test.fo has been added with description: FO source do generate the error (transforming to PDF)

        Show
        Roberto Cisternino added a comment - Attachment test.fo has been added with description: FO source do generate the error (transforming to PDF)
        Hide
        Jeremias Maerki added a comment -

        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.

        Show
        Jeremias Maerki added a comment - 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.
        Hide
        Lars Marius Garshol added a comment -

        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.

        Show
        Lars Marius Garshol added a comment - 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.
        Hide
        Andreas L. Delmelle added a comment -

        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.

        Show
        Andreas L. Delmelle added a comment - 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.
        Hide
        Andreas L. Delmelle added a comment -

        (In reply to comment #6)
        > FWIW, the following implementation of
        > BlockContainerLayoutManager.wrapPositionElements() seems to fix the issue:

        Correction: BlockStackingLM.wrapPositionElements()...

        Show
        Andreas L. Delmelle added a comment - (In reply to comment #6) > FWIW, the following implementation of > BlockContainerLayoutManager.wrapPositionElements() seems to fix the issue: Correction: BlockStackingLM.wrapPositionElements()...
        Hide
        Andreas L. Delmelle added a comment -

        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.

        Show
        Andreas L. Delmelle added a comment - 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.
        Hide
        Andreas L. Delmelle added a comment -

        Fixed in FOP Trunk.

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

        Thanks for reporting!

        Show
        Andreas L. Delmelle added a comment - Fixed in FOP Trunk. See: http://svn.apache.org/viewvc?rev=654111&view=rev Thanks for reporting!
        Hide
        Glenn Adams added a comment -

        batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

        Show
        Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

          People

          • Assignee:
            fop-dev
            Reporter:
            Roberto Cisternino
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development