RE: Predictability of rendering regions on the page
- At 2005-06-03 16:16 -0400, Paul Grosso wrote:
> > From: xsl-editors-request@... On Behalf Of G. Ken HolmanDrat! This is quite necessary for what I need to accomplish.
> > 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
> > ...
> > Does XSL-FO 1.0 dictate that the perimeter regions are
> > rendered before the body region?
> > Does XSL-FO 1.0 dictate that the static content is rendered
> > before the flowed content?
> > I cannot, however, find any predictability in the XSL-FO 1.0Good point, I can see that to be true.
> > 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 avoidYes, of course ... I just had not considered ordering to be related to
>that and instead specifies constraints that should hold
>for the composed result.
>I'd think a better way to accomplish this would be toIndeed.
>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 considerI hope the SG members do consider this worthwhile as it would bring
>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.]
predictability to my real-world requirement of overlapping regions.
Having included XSL Editors on this list, I hope this note is sufficient to
the task of requesting such a feature.
>paulThank you, Paul, for your opinion and for bringing light to an aspect of my
>(just speaking for myself)
request of which I was unaware.
. . . . . . . . . . Ken
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman mailto:gkholman@...
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
- Thanks Eliot.
That clarifies things a lot.
As both packages only supported one meaning of 'absolute' when I was
trying it I obviously never looked closely at the details of the
I was using position='absolute' (expecting to get the same behaviour in
but it looks like the older version of XEP ignored the 'absolute' value
and used 'fixed'
(and possibly FOP only supported 'absolute' as the behaviour with
'fixed' never seemed to work)?
As I was looking for a specification that rendered the same in both
I solved the problem by using region-before - when the 'absolute'
offsets gave the same result in both packages.
Eliot Kimber wrote:
>Mike Trotman wrote:--
>>Do you know what the correct origin for absolute positioning should be -
>>is it relative to the page,
>>or relative to the region?
>When absolute=absolute, the block-container is positioned relative to
>its nearest ancestor reference area. For a block container that has no
>ancestor block containers, its nearest reference area will be the area
>for the page region that contains it (e.g., region-body, region-before,
>When absolute=fixed, the block-container is positioned relative to the
>edges of the page (including any page margins, if specified).
>Older versions of XEP only supported absolute=fixed. I believe that 4.x
>supports absolute=absolute as well as fixed.
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.6.1 - Release Date: 03/06/2005
Message Scanned by ClamAV on datalucid.com