This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From xsl-editors@w3.org: 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?
Adding original poster as CC since response will be required when a solution is proposed.
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
(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
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
(In reply to comment #4) Hi Edward, Thanks, I think that solves the issue. Regards, Vincent
Original poster has stated that previous response solves the issue. DOES NOT require new erratum for XSL 1.1.