Created attachment 26480 [details] XSL-FO demonstrating the odd page content overflow I have a scenario where I print mailing labels on the back of each piece of paper (even pages). When content is too much on page 1, it should overflow onto page 3 (while mailing labels print on both page 2 and page 4). ISSUE: In FOP 1.0 when the content overflows page 1 to flow onto the next ODD page, a java.lang.NullPointerException is thrown. This functionality did work in FOP 0.95. Attached a simple XSL-FO to demonstrate this. Thanks. lance Here's the exception: java.lang.NullPointerException at org.apache.fop.layoutmgr.PageBreakingAlgorithm.filterActiveNodes(PageBreakingAlgorithm.java:1028) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:527) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:439) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:369) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:85) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177) 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)
The difference is that 0.95 did not yet support alternating page-ipd. In this scenario it did not show, since the narrower pages were empty. For future reference, from a technical perspective the issue is the double restart that is triggered without content in between (actually: restart - overflow - restart). The first restart works like a charm, and kicks off from a SpaceHandlingBreakPosition as expected, but the overflow triggered by the second (empty) page, leaves us with no active node. Hence, NPE in PageBreakingAlgorithm.filterActiveNodes(). Adding the proposed fix for bug 49835, the NPE is avoided, but in that case, it becomes apparent that the SpaceHandlingBreakPosition is consumed, and the new blockList after the second restart, starts with a TableContentPosition, from which no restart is possible... In addition to the fix for bug 49835, my first idea would be to: - store the last restart point in AbstractBreaker as a member - in case a restart is not triggered from a SpaceHandlingBreakPosition, and that position immediately follows the previous restart point, restart from the stored one, as that is an indication there was not enough room to fit any content on the next page(s). Still left to verify whether this approach could resolve the issue. Stay tuned...
Created attachment 26643 [details] possible fix? This patch to fop.layoutmgr.AbstractBreaker, in conjunction with the patch attached to Bugzilla 49835 seems to resolve the issue, and passes the unit tests. Not entirely sure if this is airtight, though, hence the question-marks in the code comment...
Created attachment 26644 [details] minor change Actually, that second condition was not necessary I believe... might even have caused mayhem at some point (?)
*** Bug 50985 has been marked as a duplicate of this bug. ***
resetting severity from major to normal pending further review
resetting P2 open bugs to P3 pending further review
(In reply to comment #3) > Created attachment 26644 [details] > minor change > > Actually, that second condition was not necessary I believe... might even have > caused mayhem at some point (?) andreas, should this patch be applied?