Bug 46823 - LayoutException when rendering ./examples/fo/basic/blockcontainer.fo
Summary: LayoutException when rendering ./examples/fo/basic/blockcontainer.fo
Status: NEW
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: page-master/layout (show other bugs)
Version: all
Hardware: PC Linux
: P3 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-09 01:54 UTC by Adrian Cumiskey
Modified: 2012-04-18 06:55 UTC (History)
1 user (show)



Attachments
Proposed patch (3.78 KB, patch)
2009-03-24 05:42 UTC, Simon Pepping
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Cumiskey 2009-03-09 01:54:42 UTC
Rendering our own ./examples/fo/basic/blockcontainer.fo causes the BlockContainerLayoutManager to be unable to recover from content overflow.

Here is the exception:

org.apache.fop.layoutmgr.LayoutException: Content overflows the viewport of an fo:block-container in block-progression direction by 100800 millipoints. Content will be clipped. (See position 155:44)
        at org.apache.fop.layoutmgr.LayoutException$LayoutExceptionFactory.createException(LayoutException.java:92)
        at org.apache.fop.events.EventExceptionManager.throwException(EventExceptionManager.java:54)
        at org.apache.fop.events.DefaultEventBroadcaster$1.invoke(DefaultEventBroadcaster.java:152)
        at $Proxy0.viewportOverflow(Unknown Source)
        at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElementsAbsolute(BlockContainerLayoutManager.java:533)
        at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(BlockContainerLayoutManager.java:196)
        at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:304)
        at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:118)
        at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:115)
        at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:144)
        at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:553)
        at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:136)
        at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:303)
        at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:265)
        at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107)
        at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:234)
        at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120)
        at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:346)
        at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
        at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101)
        at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
        at org.apache.xerces.xinclude.XIncludeHandler.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:484)
        at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:236)
        at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:128)
        at org.apache.fop.cli.Main.startFOP(Main.java:174)
        at org.apache.fop.cli.Main.main(Main.java:205)
Comment 1 Andreas L. Delmelle 2009-03-09 10:50:04 UTC
FWIW: in spite of the fact that this bug is marked as applicable to 'ALL' versions, I cannot reproduce the issue with FOP Trunk on Mac OS X (tried rendering to PDF or AWT).
Comment 2 Andreas L. Delmelle 2009-03-09 10:53:45 UTC
Sorry, a bit too quick, but there is a logical explanation: I had commented out the last fo:block-container, which has a overflow='error-if-overflow', so the fact that you get an exception is expected.
Comment 3 Adrian Cumiskey 2009-03-09 13:58:31 UTC
I should have looked at the FO more closely...  still, this is not a very good example for someone wanting to try FOP out.  It would be better to remove the error on overflow and generate some useful output for the user. WDYT?
Comment 4 Andreas L. Delmelle 2009-03-09 14:05:29 UTC
(In reply to comment #3)
> I should have looked at the FO more closely...  still, this is not a very good
> example for someone wanting to try FOP out.  It would be better to remove the
> error on overflow and generate some useful output for the user. WDYT?

Good idea. Indeed, a dubious demo file. :-)
Comment 5 Simon Pepping 2009-03-24 03:26:54 UTC
The spec says: error-if-overflow: This value implies the same semantics as the value "hidden" with the additional semantic that an error shall be indicated; implementations may recover by clipping the region.

The code says: boolean canRecover = (getBlockContainerFO().getOverflow() != EN_ERROR_IF_OVERFLOW); (BlockContainerLayoutManager, line 533).

Does that not mean that the code is wrong: it should recover, but issue an ERROR instead of a WARNING?
Comment 6 Jeremias Maerki 2009-03-24 04:11:44 UTC
(In reply to comment #5)
> The spec says: error-if-overflow: This value implies the same semantics as the
> value "hidden" with the additional semantic that an error shall be indicated;
> implementations may recover by clipping the region.
> 
> The code says: boolean canRecover = (getBlockContainerFO().getOverflow() !=
> EN_ERROR_IF_OVERFLOW); (BlockContainerLayoutManager, line 533).
> 
> Does that not mean that the code is wrong: it should recover, but issue an
> ERROR instead of a WARNING?

The spec says "may recover", it doesn't say "should recover", so it isn't technically wrong. That doesn't mean it can't be changed. But my personal expectation is an error if I explicitely say "error-if-overflow" instead of "hidden". If I say "hidden" I don't care if any content is lost.
Comment 7 Simon Pepping 2009-03-24 05:42:14 UTC
Created attachment 23407 [details]
Proposed patch

Would the attach patch solve the problem in a good way?
Comment 8 Jeremias Maerki 2009-03-24 10:24:51 UTC
(In reply to comment #7)
> Created an attachment (id=23407) [details]
> Proposed patch
> 
> Would the attach patch solve the problem in a good way?

I think you're doing pretty much the same thing I did there, only in reverse. I specified the event for FATAL level, and "canRecover" can lower the severity to WARN. Your change would set the default level to WARN and increase it to ERROR if it's error-on-overflow. The only difference is that the error cause used FATAL before and uses ERROR after the change which would effectively not stop the formatting and allow the user to increase the event severity to FATAL if he so chooses. You could skip the isError attribute and just set all overflow events to ERROR level by default (Javadoc @event.severity). That would have the same effect. Don't forget that the block-container case is not the only overflow where an error is possible. As I said before I'm not opposed to lowering FATAL to ERROR for "error-if-overflow". A custom event handler can always throw an exception.
Comment 9 Glenn Adams 2012-04-07 01:42:03 UTC
resetting P2 open bugs to P3 pending further review