[Bug 6278] New: Border-resolution in the collapsing-border model

[b***@wiggum.w3.org]

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

Summary: Border-resolution in the collapsing-border model
Product: XSLFO
Version: 1.1
Platform: All
URL: http://lists.w3.org/Archives/Public/xsl-
editors/2007AprJun/0000
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: XSL-FO
For the (cells of the) first row of a table, border-before on the
fo:table and applicable fo:table-column objects play into border
resolution. When the table is broken accross several pages, do they also
play for the first row of each page? Or only the very first row of the
table? We agreed upon yes. This means that if
border-conditionality="retain" on fo:table, then it will appear on each
page (if it wins in the border resolution), which would be the same
behavior as in the separate-border model.

But if the fo:table-header is not omitted at page breaks, how should
border resolution be performed? Technically, the areas generated by the
table-cell children of fo:table-header are /replicated/ on each new
page, so they would have the is-first trait set to true. So assuming
that the conditionality of the fo:table's border-before is "discard",
should it play or not in the border resolution of table-headers on the
second and following pages?

[b***@wiggum.w3.org]

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


Tony Graham <***@MenteithConsulting.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Blocks| |6281

[b***@wiggum.w3.org]

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


Tony Graham <***@MenteithConsulting.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com




--- Comment #1 from Tony Graham <***@MenteithConsulting.com> 2009-01-13 12:44:54 ---
Adding original poster as CC since response will be required when a solution is
proposed.

[b***@jessica.w3.org]

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


Edward Jiang <***@att.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@att.net
AssignedTo|***@gmail.com |***@MenteithConsult
| |ing.com




--- Comment #2 from Edward Jiang <***@att.net> 2010-06-03 15:19:23 ---
Hi Vincent,

First of all, all the members of XSL-FO working group feel so sorry that we
haven't get back to you with a complete and final answer to the email you sent
back in 2007. I believe part of the problem we're dealing with here is that
some of the questions and explanations in your email
(http://lists.w3.org/Archives/Public/xsl-editors/2007AprJun/0000) are not quite
clear and straightforward to us.

Let's take the 2 paragraphs you sent for "Border-resolution in the
collapsing-border model" for example:

| For the (cells of the) first row of a table, border-before on the
| fo:table and applicable fo:table-column objects play into border
| resolution. When the table is broken accross several pages, do they
| also
| play for the first row of each page? Or only the very first row of the
| table? We agreed upon yes. This means that if
| border-conditionality="retain" on fo:table, then it will appear on
| each
| page (if it wins in the border resolution), which would be the same
| behavior as in the separate-border model.

| But if the fo:table-header is not omitted at page breaks, how should
| border resolution be performed? Technically, the areas generated by
| the
| table-cell children of fo:table-header are /replicated/ on each new
| page, so they would have the is-first trait set to true. So assuming
| that the conditionality of the fo:table's border-before is "discard",
| should it play or not in the border resolution of table-headers on the
| second and following pages?

According to my understanding, first of all, border resolution only happens
during the "collapse" mode. Assuming we are talking about all the problems here
during the "collapse" model. And, please notice that XSL-FO shares the same
"border conflict resolution" rule as CSS
(http://www.w3.org/TR/CSS2/tables.html#border-conflict-resolution, hereinafter
"resolution").

Now let's take a look of your question here using following diagram:

+------------------+===resolved by rule===+
! ! ! \
! ! ! !
! 1st Page Header1 ! 1st Page Header2 ! !
! ! ! !
+------------------+----------------------! !
! other rows ! other rows ! !
+------------------+----------------------+ !
!
<<<< Page Break >>>> > Single fo:table
!
+------------------+ *Border in Question* + !
! ! ! !
! ! ! !
! 2nd Page Header1 ! 2nd Page Header2 ! !
! ! ! !
! ! ! /
+------------------+----------------------+

So we are mainly discussing the second page's border marked as *Border in
Question* in the diagram here, am I correct?

If I understand your logic correct, I tried to paraphrase your idea here:

Presumption:

1. fo:table has "border-before" property set
2. fo:table has "border-before" property's "conditionality" sub property set to
"retain"
3. fo:table-column for 2nd column in diagram has "border-before" property set
too
4. fo:table-header has a fo:table-cell that has "border-before" property set
too

Now, the question lies in 2 aspects here, both are concerned with the *Border
in Question*.

1. On the 2nd page, does the "border-before" property of fo:table will be still
taken into consideration for resolution or not?

2. On the 2nd page, does the "border-before" property of fo:table-cell for the
fo:table-header's 2nd column will be still taken into consideration for
resolution or not?

Is this rewrite correct?

Also, my final question regarding the term "separate-border model" in your
email. Do you mean the model by just the model in "non-collapse" mode?

Sincerely,
Edward
Member of XSL-FO working group

[b***@jessica.w3.org]

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





--- Comment #3 from Vincent Hennebert <***@gmail.com> 2010-08-02 10:49:05 ---
(In reply to comment #2)

Hi Edward,

Thanks for your answer. Actually the problem must be broken down into two
sub-cases:

1. "table-omit-header-at-break" property set to "true"

+------------------+===resolved by rule===+
! ! ! \
! ! ! !
! 1st Page Header1 ! 1st Page Header2 ! !
! ! ! !
+------------------+----------------------! !
! row 1 ! row 1 ! !
+------------------+----------------------+ ! > Single fo:table
!
<<<< Page Break >>>> !
!
+------------------+ *Border in Question* + !
! row 2 ! row 2 ! !
+------------------+----------------------+ /

Assumptions:
1. fo:table has "border-before" property set;
2. fo:table has "border-before" property's "conditionality" sub-property set to
"retain"

Question regarding the resolution of *Border in Question*:
On the 2nd page, will the "border-before" property of fo:table be taken
into consideration for resolution or not?

In other words: must the "border-before" property of fo:table play into
resolution for the very first row of the table only, or, according to the value
of the "conditionality" sub-property, also for the first row on every new page?

That question can be equally worded by replacing "fo:table" with
"fo:table-column".

It seems natural to answer yes. But then comes the second question:

2. table-omit-header-at-break property set to "false"

+------------------+===resolved by rule===+
! ! ! \
! ! ! !
! 1st Page Header1 ! 1st Page Header2 ! !
! ! ! !
+------------------+----------------------! !
! other rows ! other rows ! !
+------------------+----------------------+ !
!
<<<< Page Break >>>> > Single fo:table
!
+------------------+ *Border in Question* + !
! ! ! !
! ! ! !
! 2nd Page Header1 ! 2nd Page Header2 ! !
! ! ! !
! ! ! /
+------------------+----------------------+

Assumptions:
1. fo:table has "border-before" property set;
2. fo:table has "border-before" property's "conditionality" sub-property set to
"discard"

Question regarding the resolution of *Border in Question*:
On the 2nd page, will the "border-before" property of fo:table still be taken
into consideration for resolution or not?

The description of fo:table, section 6.7.3 of the XSL-FO 1.1 Recommendation,
says the following:
"The content of the fo:table-header and fo:table-footer, unless omitted as
specified by the "table-omit-header-at-break" and
"table-omit-footer-at-break"
properties, shall be repeated for each normal block-area generated and
returned
by the fo:table formatting object."

If "repeated" means "cloned", then *Border in Question* must be set to the same
value as the "resolved by rule" border. If "repeated" means "generated", then
*Border in Question* will be resolved the same way as it is in case #1.


By "separate-border model", I mean the border model applied when
"border-collapse" property has been set to "separate".

Thanks,
Vincent

[b***@jessica.w3.org]

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





--- Comment #4 from Edward Jiang <***@att.net> 2010-08-12 16:35:43 ---
Hi Vincent,

Thank you for your reply. As we discussed on the XSL working group, we believe
that it's not a "clone". the properties of the top edge *border-in-question*
needs to be re-evaluated after the pagination.

In terms of the property "table-omit-header-at-break" [1], the XSL-FO 1.1
stands that:

==
The "table-omit-header-at-break" property specifies if a table whose first area
is not at the beginning of an area produced by the table should start with the
content of the fo:table-header formatting object or not.
==

So we believe the FO Processor needs to generate border based on the new
context again, not just "clones" the behavior of the border rendered in last
page.

[1] XSL-FO 7.28.18, http://www.w3.org/TR/xsl11/#table-omit-header-at-break

[b***@jessica.w3.org]

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





--- Comment #5 from Vincent Hennebert <***@gmail.com> 2010-08-27 10:42:33 ---
(In reply to comment #4)

Hi Edward,

Thanks, I think that solves the issue.

Regards,
Vincent

[b***@jessica.w3.org]

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


Tony Graham <***@MenteithConsulting.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED




--- Comment #6 from Tony Graham <***@MenteithConsulting.com> 2010-08-27 10:53:02 ---
Original poster has stated that previous response solves the issue.

DOES NOT require new erratum for XSL 1.1.