See attachment fo.fo - the input trunk.pdf - the output generated with svn trunk code maint.pdf - the output generated with 0.20.5 (how it should look like)
Created attachment 15550 [details] input
Created attachment 15551 [details] output with svn code in branch trunk
Created attachment 15552 [details] output with maint branch (as expected)
Initial analysis: there seems to be a descrepancy between the reported element list and what the addAreas() stage is writing out to the page. I suspect that space-before is not handled properly in list-items. I'll investigate further. BTW, Nils' example shows again that we have another point to attend to: Our current nominal text box is much bigger than it was for 0.20.5. I've seen this before and I think we're approaching the time when this needs to be fixed.
It is as I suspected. ListItemLM currently doesn't generate the glues for space-before and space-after. I've written a test case: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/test/layoutengine/testca ses/list4.xml I'll try to look at this shortly.
Maybe I should also mention the following showing up on System.err 03.07.2005 23:22:12 org.apache.fop.fo.flow.Table bind:: The collapsing border model on an fo:table is currently not supported by FOP:: 03.07.2005 23:22:12 org.apache.fop.fo.flow.Table bind::
Nils, the warning message was to be expected. The default of the "border-collapse" property is "collapse" and the implementation of the collapsing border model is incomplete. The warning is simply there to remind you not to expect nicely drawn borders in this mode. border-collapse="separate" works fine, though, but it obviously needs to be specified explicitely.
> the warning message was to be expected. The default of the "border-collapse" > property is "collapse" and the implementation of the collapsing border model > is incomplete. The warning is simply there to remind you not to expect nicely > drawn borders in this mode. border-collapse="separate" works fine, though, but > it obviously needs to be specified explicitely. ok, thanks for the explanation. Problem is that docbook-xsl creates tons of fo:table without applying a central property-set (there's one but it's not used everywhere) where I could override border-collapse. If the border-collapse=collapse won't be supported in the near future maybe we could add a switch that allows to flip the default explicitly /globally to 'separate'? Thanks
The situation is now improved here. The missing glues are now produced but if there are shrink and stretch possibilities the spaces are currently not adjusted, i.e. differing .minimum/.optimum/.maximum values on space-before and space-after may produce undesirable results. Changes: http://svn.apache.org/viewcvs?rev=225133&view=rev http://svn.apache.org/viewcvs?rev=225135&view=rev http://svn.apache.org/viewcvs?rev=225147&view=rev http://svn.apache.org/viewcvs?rev=225249&view=rev http://svn.apache.org/viewcvs?rev=225250&view=rev
Fixed in FOP 0.94 and probably earlier versions
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed