When I have overlapping regions (e.g.,...
fo:region-start/after/before/end are defined but no
margins are provided within fo:region-body to
accomodate their extents--see example below), the spec
doesn't appear to indicate which region should "win".
Judging from background-color, the maintenance version lets all side regions "win"
A side effect of doing layout of the static content after laying out the flow.
(not necessarily the correct answer),
Well, the spec is remarkably unhelpful for determining what the "correct answer" should be. However, the layout of the non-body region issomewhat better defined and the obvious overlapping effects can be controlled by the precedence property. Unless these regions overlap as well, there are two consistent behaviours: 1. the body content is consistently drawn on top of the other regions 2. the other regions are consistently drawn over the body. Both have their use cases.
while trunk lets only fo:region-afterIt looks ugly.
and -end win. (See attachments.) Does this matter?
I'd suggest to restore the behaviour of the maintenance code I expected this to be implemented this way anyway, because last time I looked regions were handled the same order as in the maintenance code). Vic, could this be an artefact of your changes?
In the long run, some FOP extensions to control stacking order could be explored.
J.Pietschmann