Glen Mazza wrote:
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-after
and -end win. (See attachments.) Does this matter?
It looks ugly.

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



Reply via email to