Re: FO: padding within list problem (really FOP)

 >> It means fo:block, fo:block-container (except for positioning bugs)
 >> and fo:table-cell (with even more caveats). I don't think it would

Why don't they say so more explicitly

Umm, the full range from "this space is too small to fit longer
explanations" to, well, laziness. Take a pick...

Reading "only implemented for blocks", I either think of "all
block-level elements" as defined in the formatting model, or of
<fo:block> (ok, and container).

There aren't that much block level FOs. Actually the spec lists
only two in section 6.5 "Block-level Formatting Objects", specifically
fo:block and fo:block-container. Of course, what really counts is
the definition of the %block parameter entity, because this is the
content model of fo:flow, and it expands to fo:block,
fo:block-container, fo:table-and-caption, fo:table and fo:list-block.
Further FOs allowed at the block level are the more technical FOs
fo:multi-switch, fo:multi-properties, fo:wrapper, fo:retrieve-marker
and fo:float. FOP doesn't do much with them except for the
retrieve-marker (using fo:wrapper at the block level isn't recommended
because this causes sourious warnings).

It works very well for fo:table for me - strange. Just tested it again
by adjusting and changing values for padding-bottom - definitely
interpreted, and correctly on top of it.

It does not work for fo:list-*,

Not impelemented. The fo:list-* handling code is, well, somewhat
incomplete.

however, and also not for fo:table-row.

I'm not sure whether padding even makes much sense for table rows. This
ought to conflict with common expectations if the row and the table
cells therein also have borders.

>> The biggest problem is actually that space-before/after is forced.

What do you mean?

Display of space-before/after is by default conditional, i.e. the space
is omitted at the begin of a reference area. For example space-before
shouldn't be rendered at the beginning of a page or of a table cell.
FOP reserves the space nevertheless, i.e. it behaves like MS Word, which
probably explains why this misfeature doesn't cause more complaints.
Usually it's not hard to work around this, or at least the space isn't
substantial enough to disturb the visual layout, but it can lead to
major complications in the XSLT in some circumstances.