I’ll might look into adding some kind of sorting to the fo-tree. Actually, what i did in the project i’m working on was exactly the same J Before converting my HTML-layers into fo:block-container, i performed a merge sort on the array holding the layers to be written. Writing the fo:block-containers in “z-index order” then produces the desired result. Anyway, i think i might look into adding the z-index feature to FOP, as i don’t like my own workaround ..
Also, why is it that the z-index property isn’t also a property on the fo:block-container, but only on fo:block?
Well, here are some thoughts. As no doubt you have already gathered from Section 4.9.6 of the spec and also 5.4.5 most of the work is in the renderer. Take into account that areas presented to the renderer are in a hierarchical structure, _and_ also that areas can be relatively positioned or might be fixed. It sure looks to me at first glance like z-index may require two passes, with actual rendering occurring on the second pass, and the first pass being used to create a different area hierarchy, ordered by stacking layer, with positional calculations already carried out.
This is the hard part and I don't think it will be exactly trivial but it should be fun.
Inspection of the code should inform you readily as to how the property is made known to FOP and how you would ensure that
1) inheritance according to 5.4.5 happens properly; and
2) a z-index property on FO x is placed on generated areas as a trait of the same name, so that it is available to the renderer.
Any further questions and we'll be happy to help.