| Summary: | LayoutException when rendering ./examples/fo/basic/blockcontainer.fo | ||
|---|---|---|---|
| Product: | Fop - Now in Jira | Reporter: | Adrian Cumiskey <dev> |
| Component: | page-master/layout | Assignee: | fop-dev |
| Status: | NEW --- | ||
| Severity: | normal | CC: | taffy-tyler6464 |
| Priority: | P3 | ||
| Version: | all | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: | Proposed patch | ||
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). 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. 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? (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. :-) 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? (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. Created attachment 23407 [details]
Proposed patch
Would the attach patch solve the problem in a good way?
(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. resetting P2 open bugs to P3 pending further review |
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)