This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6276 - Breaks and Borders, Successive Break Contexts
Summary: Breaks and Borders, Successive Break Contexts
Status: RESOLVED INVALID
Alias: None
Product: XSLFO
Classification: Unclassified
Component: XSL-FO (show other bugs)
Version: 1.1
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Anders Berglund
QA Contact: Mailing list for comments on XSL (XSl-FO)
URL: http://lists.w3.org/Archives/Public/x...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-04 15:53 UTC by Tony Graham
Modified: 2009-03-03 09:23 UTC (History)
1 user (show)

See Also:


Attachments

Description Tony Graham 2008-12-04 15:53:34 UTC
From xsl-editors:

The following situations are not explicitly described by the XSL-FO 1.1
Recommendation and no consistent behaviour could be found among the
various implementations:

Given the following FO snippet:
    <fo:block border-before-color="black"
      border-before-style="double"
      border-before-width="1pt">
      <fo:block break-before="page">
         Some text.
      </fo:block>
    </fo:block>

If the outer block is not leading in the page-reference-area (does not
start a page), what is the expected rendering? Should the border-before
lie on page n and the inner block on page n+1:
    ______________  ______________
    |            |  |            |
    |  ...       |  | Some text. |
    | Content    |  |            |
    | before     |  |            |
    | ...        |  |            |
    |            |  |            |
    | ========== |  |            |
    |            |  |            |
    |____________|  |____________|

... or should both be found on page n+1?
    ______________  ______________
    |            |  |            |
    |  ...       |  | ========== |
    | Content    |  | Some text. |
    | before     |  |            |
    | ...        |  |            |
    |            |  |            |
    |            |  |            |
    |            |  |            |
    |____________|  |____________|

In other words: if the first child of an fo:block has a forced (page)
break, should this block still produce an empty area (that here will
hold a before border) on the current page, or should it be deferred to
the next page along with its childs area(s)?


As another illustration of this issue, in the following case, and
assuming that we have a two-column page setup:
    <fo:block break-before="column" border-top="1pt solid red">
      <fo:block break-before="page" border-top="1pt solid blue">
        Some text.
      </fo:block>
    </fo:block>
Lets assume that when the outer block is reached we are inside the
first column of page n. Should (1) the red border be found at the top of
column #2 on page n, and the blue border at the top of column #1 on page
n+1? Or should (2) both borders be found at the top of column #1 on page
n+1?

If empty areas must be produced, then case (1) would win; otherwise this
would be case (2).


On a slightly different topic, there is a small uncertainty in cases
like the following:
    <fo:block break-before="page">
      <fo:block break-before="page">
        Some text.
      </fo:block>
    </fo:block>
Should an empty page be generated? In which case the outer block would
generate an empty area on page n+1, and the inner block its area(s) on
page n+2.
If not, then both blocks would generate their areas on page n+1. Both
behaviours are compliant with the Recommendation I think. But within the
FOP team we couldnt reach a consensus on which one should be
privileged.
Comment 1 Tony Graham 2008-12-18 12:24:25 UTC
The FO subgroup has considered your three cases:

1. There is nothing in the XSL 1.1 Recommendation that has an fo:block generating an empty area before jumping to the next page.

So the border-before follows the rest of the block to the next page.

2. For the same reason, both borders should go on column 1 of page n+1.

3. For the same reason: no, there should not be an empty page.

In accordance with the instructions at 
http://www.w3.org/XML/2008/01/xsl-fo-bugzilla.html#verify, please review the
proposed resolution carefully and let the Working Group know whether it's
acceptable or not.
Comment 2 Tony Graham 2009-01-13 12:44:21 UTC
Adding original poster as CC.  Response from original poster required to resolve bug report.
Comment 3 Vincent Hennebert 2009-03-02 11:07:45 UTC
Thanks for the clarification. I believe it clears the uncertainties that were still existing in that area. The bug can be closed now.

Vincent Hennebert
Comment 4 Tony Graham 2009-03-03 09:23:48 UTC
(In reply to comment #3)
> Thanks for the clarification. I believe it clears the uncertainties that were
> still existing in that area. The bug can be closed now.

Closing as "invalid" since that's the best we can do with this Bugzilla to close an issue that does not indicate a problem with the spec.