Fop
  1. Fop
  2. FOP-1293

FOP dies with ClassCastException in org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements

    Details

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

      Description

      In my tests, FOP 0.93 dies with a ClassCastException in
      org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements:

      21.01.2007 15:34:58 org.apache.fop.cli.Main startFOP
      SCHWERWIEGEND: Exception
      java.lang.ClassCastException
      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:160)
      at org.apache.fop.cli.Main.main(Main.java:191)

      ---------

      java.lang.ClassCastException
      at
      org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:76)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextKnuthElements(PageSequenceLayoutManager.java:272)
      at
      org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:554)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextBlockList(PageSequenceLayoutManager.java:264)
      at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:301)
      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
      org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1050)
      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.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
      at
      org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:452)
      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:160)
      at org.apache.fop.cli.Main.main(Main.java:191)

      (will attach test file)

      1. foo.fo
        62 kB
        Julian Reschke

        Activity

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

        FYI: Adrian recently discovered that one of our examples generates SEVERE errors due to the usage of
        fo:wrapper as direct descendant of the fo:flow (= advanced/cid-fonts.fo)

        The reason being the bare white-space node descendants of the wrapper --ultimately collapsed, that's
        true, but whitespace handling is done later...

        As a workaround there, the usage of fo:wrapper could easily be avoided, I think, because it is merely used
        for inherited properties... These might as well be specified on the fo:flow itself, and overridden only for
        the trailing fo:table (which is not enclosed by the fo:wrapper), if necessary.

        Show
        Andreas L. Delmelle added a comment - FYI: Adrian recently discovered that one of our examples generates SEVERE errors due to the usage of fo:wrapper as direct descendant of the fo:flow (= advanced/cid-fonts.fo) The reason being the bare white-space node descendants of the wrapper --ultimately collapsed, that's true, but whitespace handling is done later... As a workaround there, the usage of fo:wrapper could easily be avoided, I think, because it is merely used for inherited properties... These might as well be specified on the fo:flow itself, and overridden only for the trailing fo:table (which is not enclosed by the fo:wrapper), if necessary.
        Hide
        Jeremias Maerki added a comment -

        Patch applied. Thanks, Adrian!
        http://svn.apache.org/viewvc?view=rev&rev=498835

        Please note that while Adrian's fix removes the ugly ClassCastException,
        fo:wrapper will still not fully work as expected. You can use it to set
        inheritable properties but setting an "id" attribute will not have the desired
        effect. It will simply be ignored. The test wrapper_block_id.xml shows this.

        So, Julian, you will not be able to use fo:wrapper like you did in your example
        file for now. Please use an empty fo:block instead.

        I'm not sure how best to solve the "id" problem. Maybe something with an LM
        checking whether its parent is a wrapper. Suggestions welcome. Anyway, I'm
        closing this bug as this was about the ClassCastException and we're rid of that.

        Show
        Jeremias Maerki added a comment - Patch applied. Thanks, Adrian! http://svn.apache.org/viewvc?view=rev&rev=498835 Please note that while Adrian's fix removes the ugly ClassCastException, fo:wrapper will still not fully work as expected. You can use it to set inheritable properties but setting an "id" attribute will not have the desired effect. It will simply be ignored. The test wrapper_block_id.xml shows this. So, Julian, you will not be able to use fo:wrapper like you did in your example file for now. Please use an empty fo:block instead. I'm not sure how best to solve the "id" problem. Maybe something with an LM checking whether its parent is a wrapper. Suggestions welcome. Anyway, I'm closing this bug as this was about the ClassCastException and we're rid of that.
        Hide
        Adrian Cumiskey added a comment -

        I am new to the Apache FOP project and do not have commit rights yet so have
        reassiged this bug to owner.

        Show
        Adrian Cumiskey added a comment - I am new to the Apache FOP project and do not have commit rights yet so have reassiged this bug to owner.
        Hide
        Adrian Cumiskey added a comment -

        I reported this problem with one of the fop examples
        (examples/fo/advanced/cid-fonts.fo) last week. The following patch fix the
        exception.

        — snip —

        C:/workspace/fop/src/java/org/apache/fop/layoutmgr/FlowLayoutManager.java
        ===================================================================

        C:/workspace/fop/src/java/org/apache/fop/layoutmgr/FlowLayoutManager.java
        (revision 497065)
        +++
        C:/workspace/fop/src/java/org/apache/fop/layoutmgr/FlowLayoutManager.java
        (working copy)
        @@ -69,11 +69,11 @@
        int flowBPD = (int) getCurrentPV().getBodyRegion().getBPD();

        // currently active LM

        • BlockLevelLayoutManager curLM;
          + LayoutManager curLM;
          LinkedList returnedList;
          LinkedList returnList = new LinkedList();
        • while ((curLM = ((BlockLevelLayoutManager) getChildLM())) !=
          null) {
          + while ((curLM = getChildLM()) != null) {
          if (curLM instanceof InlineLevelLayoutManager) {
          log.error("inline area not allowed under flow -
          ignoring");
          curLM.setFinished(true);

        — snip —

        Adrian

        Show
        Adrian Cumiskey added a comment - I reported this problem with one of the fop examples (examples/fo/advanced/cid-fonts.fo) last week. The following patch fix the exception. — snip — C:/workspace/fop/src/java/org/apache/fop/layoutmgr/FlowLayoutManager.java =================================================================== — C:/workspace/fop/src/java/org/apache/fop/layoutmgr/FlowLayoutManager.java (revision 497065) +++ C:/workspace/fop/src/java/org/apache/fop/layoutmgr/FlowLayoutManager.java (working copy) @@ -69,11 +69,11 @@ int flowBPD = (int) getCurrentPV().getBodyRegion().getBPD(); // currently active LM BlockLevelLayoutManager curLM; + LayoutManager curLM; LinkedList returnedList; LinkedList returnList = new LinkedList(); while ((curLM = ((BlockLevelLayoutManager) getChildLM())) != null) { + while ((curLM = getChildLM()) != null) { if (curLM instanceof InlineLevelLayoutManager) { log.error("inline area not allowed under flow - ignoring"); curLM.setFinished(true); — snip — Adrian
        Hide
        Julian Reschke added a comment -

        Attachment foo.fo has been added with description: Test case

        Show
        Julian Reschke added a comment - Attachment foo.fo has been added with description: Test case
        Hide
        Julian Reschke added a comment -

        This test input shows the bug, when run under JDK 1.4, producing PDF output.

        Show
        Julian Reschke added a comment - This test input shows the bug, when run under JDK 1.4, producing PDF output.

          People

          • Assignee:
            fop-dev
            Reporter:
            Julian Reschke
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development