RE: Predictability of rendering regions on the page

[Dropping non-W3C lists to which I am not subscribed.]

> From: [email protected] On Behalf Of G. Ken Holman
> Sent: Friday, 03 June, 2005 9:17
> To: XSL Editors; XSL-FO W3C; XSL-FO-Yahoo List
> Subject: Predictability of rendering regions on the page
>=20
> To XSL-FO vendors and specification writers,
>=20
> c/o: XSL Editors, W3C XSL List, Yahoo XSL List
>=20
> I'm seeing inconsistent implementation of the order of the=20
> rendering of=20
> regions on the page, and I'm looking for predictability.
>=20
> As part of the UBL stylesheets for the past two years I've=20
> been painting=20
> the background of a printed form using XSL-FO in the before=20
> region whose=20
> extent is the length of the page, then flowing my form=20
> content in the body=20
> region whose margin-top is 0pt, thus composing a completed=20
> form and content=20
> in the resulting page image.  This technique allows me to=20
> have continuation=20
> pages with different XSL-FO-based backgrounds and have the=20
> line items in=20
> the flow trigger the pagination.
>=20
> It has worked well because my form box drawing and form content never=20
> collide ... it is just black on nothing and the nothing shows=20
> the "other"=20
> black without a problem.
>=20
> I'm now looking at using this successful technique for more elaborate=20
> backgrounds drawn with shading and images, and then=20
> overlapping flowed=20
> content using coloured text to achieve certain effects.
>=20
> What I would like is to be guaranteed that I can draw the background=20
> formatting objects before drawing the flowed formatting objects.
>=20
> Does XSL-FO 1.0 dictate that the perimeter regions are=20
> rendered before the body region?

No.

>=20
> Does XSL-FO 1.0 dictate that the static content is rendered=20
> before the flowed content?

No.

>=20
> Either will do what I need.
>=20
> I cannot, however, find any predictability in the XSL-FO 1.0=20
> specification=20
> ... perhaps I just cannot find it ... if it isn't there, can=20
> the XSL-FO 1.1 specification dictate this?

I don't think it should.  That is getting to close to
specifying a processing model.  XSL-FO tries to avoid
that and instead specifies constraints that should hold
for the composed result.

I'd think a better way to accomplish this would be to
use the z-index property, but I note z-index is not
applicable to region-*. =20

So your request should be for the XSL FO SG to consider
adding z-index to the list of properties applicable to
the region-* FOs in XSL 1.1.  [I have no idea what the
SG members will think of this.]

paul
(just speaking for myself)