- From: <bugzilla@jessica.w3.org>
- Date: Thu, 03 Jun 2010 15:19:23 +0000
- To: xsl-editors@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6278 Edward Jiang <ejiang@att.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ejiang@att.net AssignedTo|alb.w3c@gmail.com |Tony.Graham@MenteithConsult | |ing.com --- Comment #2 from Edward Jiang <ejiang@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 -- 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.
Received on Thursday, 3 June 2010 15:19:25 UTC