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

No.

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

No.

> 
> Either will do what I need.
> 
> I cannot, however, find any predictability in the XSL-FO 1.0 
> specification 
> ... perhaps I just cannot find it ... if it isn't there, can 
> 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-*.  

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)