[Bug 6267] New: [XSLFO] Tables, space-start and border-separation

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6267

           Summary: [XSLFO] Tables, space-start and border-separation
           Product: XSLFO
           Version: 1.1
          Platform: PC
               URL: http://lists.w3.org/Archives/Public/xsl-
                    editors/2008JanMar/0003
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSL-FO
        AssignedTo: alb.w3c@...
        ReportedBy: Tony.Graham@...
         QAContact: xsl-editors@...


The XSL-FO 1.1 Recommendation gives some details about how the
border-separation property for tables should be handled, but it is not
clear in my opinion where the half of it associated to the table should
lie.

As a picture is still the simplest way to illustrate the problem, please
have a look at the following example and the attached picture (see below
for the formulas):
    <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
      <fo:layout-master-set>
        <fo:simple-page-master master-name="page"
          page-height="10cm" page-width="15cm" margin="1cm">
          <fo:region-body background-color="#ffc000"/>
        </fo:simple-page-master>
      </fo:layout-master-set>
      <fo:page-sequence master-reference="page" font-size="12pt">
        <fo:flow flow-name="xsl-region-body">
          <fo:table width="100%" table-layout="fixed"
            border-collapse="separate"
            border-separation="8pt" border="4pt solid black">
            <fo:table-column number-columns-repeated="2"
              column-width="proportional-column-width(1)"/>
            <fo:table-body>
              <fo:table-row>
                <fo:table-cell border="4pt solid black">
                  <fo:block>Cell 1</fo:block>
                </fo:table-cell>
                <fo:table-cell border="4pt solid black">
                  <fo:block>Cell 2</fo:block>
                </fo:table-cell>
              </fo:table-row>
            </fo:table-body>
          </fo:table>
        </fo:flow>
      </fo:page-sequence>
    </fo:root>

So, in the attached picture, which version is correct?

First, in section 4.4.1, “Stacked Block-areas”, the graphic shows
a space-start trait but it is explained nowhere how its value should be
computed. From the graphic we can infer the following formula:
    space-start = start-indent − border-start − padding-start
Still, it is not clear whether we are referring to traits or properties
for border and padding. If I’m correct the padding-start property always  
directly maps to the padding-start trait. But this may not be the case
for border-start, see below. So, let’s assume the following:

    (1) space-start(trait) = start-indent − border-start(trait) −
padding-start

(Let’s note that Section 4.2.2 does not define any trait called
start-indent, so this is always the property which will be used.)

Then Section 4.2.3, “Geometric Definitions”, states that, for
block-level areas, “the allocation-rectangle extends [...] outside the
content-rectangle in the inline-progression-direction by an amount equal
to the end-indent, and in the opposite direction by an amount equal to
the start-indent.”

For simplicity, let’s assume that the writing direction never changes.
Given a block-area B, let’s call xa the offset of the start-edge of its
allocation rectangle from the start-edge of the content-rectangle of its
closest ancestor reference-area. Likewise, let’s call xc the offset of
the start-edge of its content-rectangle.

Section 4.2.3 states that:
    (2) xa = xc − start-indent

Then Section 4.4.1 states that:
        xa = start-indent + start-intrusion-adjustment
             − border-start − padding-start − space-start
Since this section is all about traits, let’s assume we have the
following:
    (3) xa = start-indent + start-intrusion-adjustment
             − border-start(trait) − padding-start
             − space-start

But since space-start can be inferred from start-indent thanks to
equation (2), we can simplify (3) into the following:
        xa = start-indent + start-intrusion-adjustment
             − border-start(trait) − padding-start
             − (start-indent − border-start(trait) −
padding-start)
which will simplify into the following:
        xa = start-intrusion-adjustment
and
        xc = start-intrusion-adjustment + start-indent
which means that if start-indent = 0, then the start-edge of B’s
content-rectangle will coincide with the start-edge of the
content-rectangle of the closest ancestor reference-area.

Buth then, why having kept the formula in its original, unsimplified
form?


Now about tables. Section 6.7.3, “fo:table” says that in the separate
border model the border of the table is composed of half the value of
the border-separation property plus the border as specified by the
property. Which would mean that the border-start(trait) would, in this
particular case, be different from the border-start(property):
    border-start(trait) = border-start(property) +
border-separation.inline-progression-dimension / 2

That’s why it seems important to me to know whether we are speaking of
traits or properties in the formulas above. If both formulas use the
same value (trait or property), then we have the result #1 on the
attached picture. If formula (1) uses the trait and formula (3) uses the
property, then the simplification will give:
    xa = start-indent + start-intrusion-adjustment
         − border-start(property) − padding-start
         − (start-indent − border-start(trait) −
padding-start)
       = start-intrusion-adjustment + border-separation.i-p-d / 2
Leading to result #2 in the attached picture, which is a sensible
result.

And if formula (1) uses the property and formula (3) the trait, we get
result #3 which is probably less likely to be expected.


Finally, Section 6.7.3, “fo:table” and Section 6.7.10, “fo:table-cell”
mention the “table grid boundary line”, but it is unclear where this
line should actually lie, especially with respect to the table padding.
There seems to be an inconsistency since Section 6.7.3 states that “the
first [border component], which is placed with the inside edge
coincident with the outermost table grid boundary line, has the width of
half the value for the ‘border-separation’ property”. And Section 6.7.10
states that “the first [border component], which is placed with the
outside edge coincident with the table grid boundary line, has the width
of half the value for the border-separation trait”. Then where shall the
padding be placed? The only consistent way to resolve this issue in my
opinion is to make the padding coincide with the table outermost grid
boundary line. See the attached picture as an illustration (where
case #1 from above has been selected). It might be helpful to add an
indication with this respect in the Recommendation.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6267





--- Comment #1 from Tony Graham <Tony.Graham@...>  2008-12-04 14:20:13 ---
Created an attachment (id=608)
 --> (http://www.w3.org/Bugs/Public/attachment.cgi?id=608)
Background separation alternatives.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6267





--- Comment #2 from Tony Graham <Tony.Graham@...>  2008-12-04 14:20:49 ---
Created an attachment (id=609)
 --> (http://www.w3.org/Bugs/Public/attachment.cgi?id=609)
Table grid boundary line.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6267


Tony Graham <Tony.Graham@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[XSLFO] Tables, space-start |space-start
                   |and border-separation       |




--- Comment #3 from Tony Graham <Tony.Graham@...>  2008-12-18 11:58:11 ---
The second part of the original message, concerning tables, is now Bug #6319.

The summary of this message was "Tables, space-start and border-separation" and
is now "space-start".

The proposed resolution for space-start is:

---------------------------------------------------------
In the definition of properly stacked, in 4.4.1, replace the second and
third bullet points of condition 1 with:

================
* the start edge of its allocation-rectangle is parallel to the
start-edge of the content-rectangle of R (where R is the closest
ancestor reference-area of B), and offset from it inward by a distance
equal to the block-area's start-indent plus its
start-intrusion-adjustment (as defined below), minus its border-start,
padding-start, and start-edge margin values, and

* the end-edge of its allocation-rectangle is parallel to the end-edge
of the content-rectangle of R, and offset from it inward by a distance
equal to the block-area's end-indent plus its end-intrusion-adjustment
(as defined below) minus its border-end, padding-end, and end-edge
margin values.

By "start-edge margin" or "end-edge margin" value, we mean the value of
margin-left, margin-right, margin-top or margin-bottom, depending on
which corresponds to the start-edge or end-edge directions.
================


In the subsequent diagrams in 4.4.1, remove the references to
"Space-start" and "Space-end".


In section 4.2.3, remove the word "Spaces" from the green background of
the first two diagrams.
---------------------------------------------------------

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.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6267


Tony Graham <Tony.Graham@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vhennebert@...




--- Comment #4 from Tony Graham <Tony.Graham@...>  2009-01-13 12:44:01 ---
Adding original poster as CC.  Response from original poster required to
resolve bug report.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6267





--- Comment #5 from Vincent Hennebert <vhennebert@...>  2009-01-15 11:29:24 ---
(In reply to comment #3)

> The second part of the original message, concerning tables, is now Bug #6319.
>
> The summary of this message was "Tables, space-start and border-separation" and
> is now "space-start".
>
> The proposed resolution for space-start is:
>
> ---------------------------------------------------------
> In the definition of properly stacked, in 4.4.1, replace the second and
> third bullet points of condition 1 with:
>
> ================
> * the start edge of its allocation-rectangle is parallel to the
> start-edge of the content-rectangle of R (where R is the closest
> ancestor reference-area of B), and offset from it inward by a distance
> equal to the block-area's start-indent plus its
> start-intrusion-adjustment (as defined below), minus its border-start,
> padding-start, and start-edge margin values, and
>
> * the end-edge of its allocation-rectangle is parallel to the end-edge
> of the content-rectangle of R, and offset from it inward by a distance
> equal to the block-area's end-indent plus its end-intrusion-adjustment
> (as defined below) minus its border-end, padding-end, and end-edge
> margin values.
>
> By "start-edge margin" or "end-edge margin" value, we mean the value of
> margin-left, margin-right, margin-top or margin-bottom, depending on
> which corresponds to the start-edge or end-edge directions.
> ================

This does not seem to solve the uncertainty I'm afraid. The border-start is
already taken into account in the computation of the offset (“... start-indent
+ start-intrusion-adjustment, minus border-start...”). Would that mean that the
border should now be counted twice? This is very unlikely to match users
expectations I think.

The following re-writing of the second bullet point seems to be enough
actually:
“the start edge of its allocation-rectangle is parallel to the start-edge of
the content-rectangle of R (where R is the closest ancestor reference-area of
B), and offset from it inward by a distance equal to the block-area's
start-intrusion-adjustment (as defined below)”
and likewise for the second bullet.

Then formula (3) can be re-written like this:
(3a) xa = start-intrusion-adjustment
and combined with formula (2) (again in the simplified conditions where there
is no change of writing direction nor reference-orientation):
    xc = start-indent + start-intrusion-adjustment

In the common case where there is no start-indent nor
start-intrusion-adjustment, this means that the start-edge of the
content-rectangle coincides with the start-edge of the content rectangle of its
nearest ancestor reference area. Roughly speaking, the area's padding-start and
border-start ‘stick out’ in the margin, which is what most XSL-FO renderers
already implement, and matches user expectations.

This would mean that in the case of tables with the separate border model, the
first possibility in the attached image would be retained, since according to
section 6.7.10 half of the border-separation is associated to the cells'
borders, so lies inside the content-rectangle of the table.

> In the subsequent diagrams in 4.4.1, remove the references to
> "Space-start" and "Space-end".
>
>
> In section 4.2.3, remove the word "Spaces" from the green background of
> the first two diagrams.
> ---------------------------------------------------------
>
> 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.

Thanks,
Vincent Hennebert


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6267


Liam R E Quin <liam@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liam@...
         AssignedTo|alb.w3c@...           |Tony.Graham@MenteithConsulti
                   |                            |ng.com




--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.