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

Predictability of rendering regions on the page

Expand Messages
  • G. Ken Holman
    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
    Message 1 of 5 , Jun 3, 2005
    • 0 Attachment
      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
    • 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 2 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 3 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 4 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 5 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.