Loading ...
Sorry, an error occurred while loading the content.

Re: [XSL-FO] Predictability of rendering regions on the page

Expand Messages
  • Mike Trotman
    I remember asking about this in Oct 2003 - as FOP also renders regions in a different order than XEP. I was also asking about absolute positioning. XEP renders
    Message 1 of 5 , Jun 3, 2005
    • 0 Attachment
      I remember asking about this in Oct 2003 - as FOP also renders regions
      in a different order than XEP.

      I was also asking about absolute positioning.

      XEP renders the overlaps in the order from bottom up: body, after, end,
      start, before (and start origin for absolute position at page 0,0)
      FOP renders the overlaps in the order from bottom up: body, before,
      after, start, end (and starts origin for absolute position at region 0,0)

      Do you know what the correct origin for absolute positioning should be -
      is it relative to the page,
      or relative to the region?

      Mike

      G. Ken Holman wrote:

      >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?
      >
      >Does XSL-FO 1.0 dictate that the static content is rendered before the
      >flowed content?
      >
      >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?
      >
      >Below is a test that shows Antenna House and RenderX producing different
      >results. Either one of these packages has a problem, or both are
      >acceptable and the specification doesn't say one way or the other.
      >
      >Thanks for any guidance anyone can give!
      >
      >. . . . . . . . . . Ken
      >
      ><?xml version="1.0" encoding="utf-8"?><!--region-overlap.fo-->
      ><!DOCTYPE root [ <!ENTITY % pages SYSTEM "pages.ent"> %pages; ]>
      ><root xmlns="http://www.w3.org/1999/XSL/Format">
      >
      ><layout-master-set>
      > <simple-page-master master-name="frame"
      > page-height="297mm" page-width="210mm"
      > margin-top="15mm" margin-bottom="15mm"
      > margin-left="15mm" margin-right="15mm">
      > <region-body region-name="frame-body"/>
      > <region-before region-name="before" extent="8in"/>
      > </simple-page-master>
      ></layout-master-set>
      >
      ><page-sequence master-reference="frame">
      > <static-content flow-name="frame-body">
      > <block font-size="20pt" font-weight="bold" color="black">
      > XXXXXXXXXXXXXX
      > </block>
      > </static-content>
      >
      ><flow xmlns="http://www.w3.org/1999/XSL/Format" flow-name="before"
      > font-family="Times" font-size="20pt" font-weight="bold">
      >
      > <block color="white">This is a test</block>
      >
      > <block>AX: The before region, with the white flow, is being rendered
      >second.</block>
      > <block>XEP: The before region, with the white flow, is being rendered first,
      >the body region, with the black static content, is being rendered
      >second.</block>
      >
      ></flow>
      ></page-sequence>
      >
      ><page-sequence master-reference="frame">
      > <static-content flow-name="before">
      > <block font-size="20pt" font-weight="bold" color="white">
      > XXXXXXXXXXXXXX
      > </block>
      > </static-content>
      >
      ><flow xmlns="http://www.w3.org/1999/XSL/Format" flow-name="frame-body"
      > font-family="Times" font-size="20pt" font-weight="bold">
      >
      > <block color="black">This is a test</block>
      >
      > <block>AX and XEP: The before region, with the white static content, is
      >being rendered second after the body region, with the black flowed content,
      >rendered first.</block>
      >
      ></flow>
      ></page-sequence>
      ><page-sequence master-reference="frame">
      > <static-content flow-name="before">
      > <block font-size="20pt" font-weight="bold">
      > XXXXXXXXXXXXXX
      > </block>
      > </static-content>
      >
      ><flow xmlns="http://www.w3.org/1999/XSL/Format" flow-name="frame-body"
      > font-family="Times" font-size="20pt" font-weight="bold">
      >
      > <block>This is a test</block>
      >
      ></flow>
      ></page-sequence>
      ></root>
      >
      >--
      >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
      >
      >
      >
      >
      >Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >Message Scanned by ClamAV on datalucid.com
      >
      >



      --
      No virus found in this outgoing message.
      Checked by AVG Anti-Virus.
      Version: 7.0.322 / Virus Database: 267.5.2 - Release Date: 03/06/2005


      Message Scanned by ClamAV on datalucid.com
    • Eliot Kimber
      ... When absolute=absolute, the block-container is positioned relative to its nearest ancestor reference area. For a block container that has no ancestor block
      Message 2 of 5 , Jun 3, 2005
      • 0 Attachment
        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,
        etc.).

        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.

        Cheers,

        Eliot

        --
        W. Eliot Kimber
        Professional Services
        Innodata Isogen
        9390 Research Blvd, #410
        Austin, TX 78759
        (512) 372-8155

        ekimber@...
        www.innodata-isogen.com
      • G. Ken Holman
        ... Drat! This is quite necessary for what I need to accomplish. ... Good point, I can see that to be true. ... Yes, of course ... I just had not considered
        Message 3 of 5 , Jun 3, 2005
        • 0 Attachment
          At 2005-06-03 16:16 -0400, Paul Grosso wrote:
          > > From: xsl-editors-request@... 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
          > > ...
          > > 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.

          Drat! This is quite necessary for what I need to accomplish.

          > > 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.

          Good point, I can see that to be true.

          >XSL-FO tries to avoid
          >that and instead specifies constraints that should hold
          >for the composed result.

          Yes, of course ... I just had not considered ordering to be related to
          processing.

          >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-*.

          Indeed.

          >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.]

          I hope the SG members do consider this worthwhile as it would bring
          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.

          >paul
          >(just speaking for myself)

          Thank you, Paul, for your opinion and for bringing light to an aspect of my
          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
        • Mike Trotman
          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
          Message 4 of 5 , Jun 4, 2005
          • 0 Attachment
            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
            absolute-position property.
            I was using position='absolute' (expecting to get the same behaviour in
            each package)
            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
            packages
            I solved the problem by using region-before - when the 'absolute'
            offsets gave the same result in both packages.


            Mike

            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,
            >etc.).
            >
            >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.
            >
            >Cheers,
            >
            >Eliot
            >
            >
            >



            --
            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
          Your message has been successfully submitted and would be delivered to recipients shortly.