Re: 'space-after' combined with 'break-after="page"'

Nancy:

Without looking at depth into the exact case you have, I read Ken's response
and I believe he is correct.
A couple other things I will point out from experience and a deep knowledge
of RenderX. 

I would always try to avoid this:

> <fo:block break-after="page"/>

Certainly this could be a break-before="page" on the following block.

> <fo:block xmlns:rx="http://www.renderx.com/XSL/Extensions" span="all"
> start-indent="0pt">

Even if there is some logic within an XSL that outputs the empty block with
a page-break, this logic could likely be moved to placing the attribute on
the following block. Side effects can lead to a slightly slower performance
inside the engine. Consider the case where content on the page just before
that block ended right at the end. Inside the formatter a new page would be
created and then this block placed down with the rule to break right after
it, causing a new page again. And then the block would be collapsed as it
has no content and the formatting engine has to delete the page it created
and go backwards (essentially ... the formatter does do things a bit
different but the explanation is close). This can be compounded by the
existence of keeps and footnotes. Using break-before is handled differently
as the page is already created and this is tested immediately, if this is
being placed at the top of a new page, the break-before is basically
"skipped".

I also try to (again if possible) avoid this:

> <fo:block/>

This is really no different than the above and can in certain instances
break keeps at higher levels in the engine. Empty blocks that do nothing at
all are necessarily collapsed, they do not end up in the area tree and there
are cases where they can break a keep condition.

I do not even use that structure when filling an empty table-cell, I always
use <fo:block><fo:inline/></fo:block>, while it is the same it is just a
habit from experience in hitting some issues.

When looking at XSL FO, I try to find structures that really do nothing or
could be done differently (like moving the break to the following block) and
attempt to architect them out of the solution. After all, if they do nothing
it would not harm you to remove them.

In 80% of the cases of behavior that is not possibly what you expect, it
will usually comes from such a structure.

Kevin Brown
RenderX