Re: Border conditionalities and collapsing-border model, breaks on header/footer
On Mar 26, 2007, at 11:31, Vincent Hennebert wrote: And there is a remaining question raised by Andreas: [me:] If the table is broken across several pages and the header shall be replicated, do border-before for table and table-column play again in border- resolution for the second and following headers? [Andreas:] YES! Not only border-before even, I think, but that is open for interpretation. The column's border-before *and* after need to be considered for each body, header/footer that appears on a given page. One could also argue that the column's span the entire table for each page, so the column's border-after does not need to be considered for the header's last row, for instance. Interesting point of vue. I think it can be summarized by the attached picture. Jeremias' position corresponds to 1., and I suspect this is the more common understanding. Andreas' is 2., but I'm afraid you'll be alone ;-) Mine's tends to be 3., although I'm ok with 1. If there is no other comment I'll go with 1. 1. is also fine with me. As I said, it's open for interpretation, and I would agree that option 1. is what the largest part of our audience will expect. In a way, in the majority of use-cases option 2. /almost/ gives the same result as 1. It would only give slightly different results if the column's after- border is different from the before-border. I think you'll have to look hard for cases where people specify different border-specs for the two opposite sides, but as you say: nothing prevents people from achieving weird effects. :-) Cheers, Andreas
Re: Border conditionalities and collapsing-border model, breaks on header/footer
Hi, Thanks for your inputs, Andreas and Jeremias. The whole thing suddenly makes sense when you think in terms of area tree instead of fo tree... Still, I think it's not obvious by reading the spec and I'll probably ask for clarification on [EMAIL PROTECTED] And there is a remaining question raised by Andreas: [me:] >> If the table is broken across several pages and the header shall be >> replicated, do >> border-before for table and table-column play again in border-resolution >> for the second and following headers? [Andreas:] > YES! Not only border-before even, I think, but that is open for > interpretation. The column's border-before *and* after need to be > considered for each body, header/footer that appears on a given page. > > One could also argue that the column's span the entire table for each > page, so the column's border-after does not need to be considered for > the header's last row, for instance. Interesting point of vue. I think it can be summarized by the attached picture. Jeremias' position corresponds to 1., and I suspect this is the more common understanding. Andreas' is 2., but I'm afraid you'll be alone ;-) Mine's tends to be 3., although I'm ok with 1. If there is no other comment I'll go with 1. > Apart from that, there is the tiny note, of course, that we're talking > about hypothetical situations, in which border-conditionality is > overridden for all table-elements. > The default value being "discard" makes the interplay between > border-collapse and border-conditionality actually much simpler than it > seems at first... > >> - when we break at a grid line, should the two rows meeting a the line count in border resolution? Or only the row before for the border-after at the end of the page, and the row after for the border-before at the beginning of the following page? I would go with that latter. >>> >>> That's right. >> >> Fine (that means that the border may potentially be different at the >> bottom of the previous page and at the top of the next page). > > Only if you have no header/footer. If there is a repeated header/footer, > then the border will neatly be the same for all pages. If you have no > header or footer, then overriding border-*-width.conditionality on the > table or table-body is enough to prevent weird effects. Still, nothing prevents users from trying to achieve those weird effects ;-) - when we break at a grid line, should the entire border appear on each page, or the higher half at the bottom of the first page, and the lower half at the top of the following page? I would also go with that latter. >>> >>> No, the entire border has to be painted. This is >>> BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See >>> the BorderProps class. >> >> So the grid line at the page break would have two borders, one at the >> bottom of the page, one at the top of the next page? >> That's fine for me, but again I think it's specified nowhere. > > Hmm... not exactly. Think of the part of the table on one page as an > independent subgrid, that has nothing to do anymore with the preceding > or following subgrid. It is the gridline which is split in two, and each > of the new gridlines will have one fully resolved border. In a sense the > border is duplicated, yes... :/ I'm ok with that now :-) Thanks, Vincent
Re: Border conditionalities and collapsing-border model, breaks on header/footer
On Mar 23, 2007, at 18:21, Vincent Hennebert wrote: [Jeremias: ] http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. The image should help you understand. An example: take the before border of the first cell of a table header. The elements that influence the resolved borders are: table, column-groups if applicable, the column, table-header, the first row in the table-header and the cell itself. All the borders of these elements have to be combined. That's what's already (!) implemented in CollapsingBorderModelEyeCatching (for border-collapse="collapse") That doesn't tell anything regarding page breaks!? Hèhè, that always tends to happen with references to CSS. :-) If the table is broken across several pages and the header shall be replicated, do border-before for table and table-column play again in border- resolution for the second and following headers? YES! Not only border-before even, I think, but that is open for interpretation. The column's border-before *and* after need to be considered for each body, header/footer that appears on a given page. One could also argue that the column's span the entire table for each page, so the column's border-after does not need to be considered for the header's last row, for instance. Apart from that, there is the tiny note, of course, that we're talking about hypothetical situations, in which border-conditionality is overridden for all table-elements. The default value being "discard" makes the interplay between border- collapse and border-conditionality actually much simpler than it seems at first... - when we break at a grid line, should the two rows meeting a the line count in border resolution? Or only the row before for the border-after at the end of the page, and the row after for the border-before at the beginning of the following page? I would go with that latter. That's right. Fine (that means that the border may potentially be different at the bottom of the previous page and at the top of the next page). Only if you have no header/footer. If there is a repeated header/ footer, then the border will neatly be the same for all pages. If you have no header or footer, then overriding border-*- width.conditionality on the table or table-body is enough to prevent weird effects. Do we agree that those two latter cases are not described by the spec? As far as I remember, yes, since XSL-FO refers almost entirely to CSS (which, because of its correlation with HTML, has no concept of page- breaks). This still leaves some room for the implementors FTM... - when we break at a grid line, should the entire border appear on each page, or the higher half at the bottom of the first page, and the lower half at the top of the following page? I would also go with that latter. No, the entire border has to be painted. This is BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See the BorderProps class. So the grid line at the page break would have two borders, one at the bottom of the page, one at the top of the next page? That's fine for me, but again I think it's specified nowhere. Hmm... not exactly. Think of the part of the table on one page as an independent subgrid, that has nothing to do anymore with the preceding or following subgrid. It is the gridline which is split in two, and each of the new gridlines will have one fully resolved border. In a sense the border is duplicated, yes... :/ Cheers, Andreas
Re: Border conditionalities and collapsing-border model, breaks on header/footer
On 23.03.2007 18:21:09 Vincent Hennebert wrote: > Jeremias Maerki a écrit : > > On 23.03.2007 15:44:57 Vincent Hennebert wrote: > >> Guys, > >> > >> I've again stumbled upon uncertainties regarding the handling of > >> conditional borders in the collapsing-border model, and breaks inside > >> headers/footers. I'd like to have your opinions on these: > >> > >> > >> Table headers and footers: > >> Headers and footers are generated only once, and replicated on each > >> page. This means that cells in headers and footers only generate one > >> area, with the is-first and is-last traits set. Border- and > >> padding-conditionality don't apply here. > > > > Conditionality still applies but because there's a header or footer > > Why would conditionality apply? Every area from headers would have > is-first set. Ignore that comment. You got it right. I was just not confortable with your using "don't apply" because that's used in the spec to say whether a feature applies to a certain element. No problem here. Move on. > > serving as fence, the cell borders and paddings don't get discarded. > > Different wording, but essentially, yes. > > > >> Or perhaps that the border-before of the table should still be > >> considered? I mean, for the first header it would come into play, and > >> for following headers it also would only if conditionality=retain. > >> I think I'll go that way as it more closely matches the behavior of the > >> separate border-model. > > > > There's no table border in the collapsing border model when we're > > talking about areas. All levels of borders inside a table are merged. In > > the end, all you have are cell borders, nothing else. > > I know, the question is for the border-before of (the first row of) the > header: for the very first header, border-before on table and > table-columns play in the border resolution. Should they also for the > headers on the following pages? Yes, of course. The collapsing model is explained in terms of grid units and that maps into the area tree rather than the FO tree, so all elements need to be considered on all pages. > > > > Only in separate border model do you have separate borders on the table > > and on the cells. > >> Table body(-ies): > >> There are several uncertainties: > >> - should the border-before of the table and table-columns be considered > >> or not: do we consider that those borders only apply to the very first > >> (or last) row of the table? Or also to the first (last) row on each > >> page? The question remains whether there are headers/footers or not. > >> I would say yes. > > > > http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. The > > image should help you understand. An example: take the before border of > > the first cell of a table header. The elements that influence the > > resolved borders are: table, column-groups if applicable, the column, > > table-header, the first row in the table-header and the cell itself. All > > the borders of these elements have to be combined. That's what's already > > (!) implemented in CollapsingBorderModelEyeCatching (for > > border-collapse="collapse") > > That doesn't tell anything regarding page breaks!? The whole spec is a little thin on how exactly page breaking is done. > If the table is > broken across several pages and the header shall be replicated, do > border-before for table and table-column play again in border-resolution > for the second and following headers? Or only for the first one? That's > the same question as above actually. And that also applies to the first > row from the table-body on each page, when header should be omitted at > page breaks. Yes, same question, same answer. > > >> - when we break /within/ a cell, should the following row come into play > >> for computing the border-after? As the row hasn't even been reached > >> yet, I'd say no. > > > > Right. That's the case in CollapsingBorderModelEyeCatching when > > currentCell is not null, and otherCell is null. > > Fine. > > > >> - when we break at a grid line, should the two rows meeting a the line > >> count in border resolution? Or only the row before for the > >> border-after at the end of the page, and the row after for the > >> border-before at the beginning of the following page? > >> I would go with that latter. > > > > That's right. > > Fine (that means that the border may potentially be different at the > bottom of the previous page and at the top of the next page). Do we > agree that those two latter cases are not described by the spec? No again, this is specified in terms of grid units which maps on the area model. You seem to think in terms of the FO tree. > > >> - when we break at a grid line, should the entire border appear on each > >> page, or the higher half at the bottom of the first page, and the > >> lower half at the top of the following page? > >> I would also go with that latter. > > > > No, the entire border has to be pai
Re: Border conditionalities and collapsing-border model, breaks on header/footer
On Mar 23, 2007, at 18:18, Andreas L Delmelle wrote: Sorry, only now reading Jeremias' answers, and noticed that I got the picture wrong here: - when we break at a grid line, should the entire border appear on each page, or the higher half at the bottom of the first page, and the lower half at the top of the following page? I would also go with that latter. Agreed again. I don't agree with painting only half the border on the first page, but I do agree that there is only one border to consider for each page... You should definitely NOT view them as two halves of the same border. Cheers, Andreas
Re: Border conditionalities and collapsing-border model, breaks on header/footer
Jeremias Maerki a écrit : > On 23.03.2007 15:44:57 Vincent Hennebert wrote: >> Guys, >> >> I've again stumbled upon uncertainties regarding the handling of >> conditional borders in the collapsing-border model, and breaks inside >> headers/footers. I'd like to have your opinions on these: >> >> >> Table headers and footers: >> Headers and footers are generated only once, and replicated on each >> page. This means that cells in headers and footers only generate one >> area, with the is-first and is-last traits set. Border- and >> padding-conditionality don't apply here. > > Conditionality still applies but because there's a header or footer Why would conditionality apply? Every area from headers would have is-first set. > serving as fence, the cell borders and paddings don't get discarded. > Different wording, but essentially, yes. > >> Or perhaps that the border-before of the table should still be >> considered? I mean, for the first header it would come into play, and >> for following headers it also would only if conditionality=retain. >> I think I'll go that way as it more closely matches the behavior of the >> separate border-model. > > There's no table border in the collapsing border model when we're > talking about areas. All levels of borders inside a table are merged. In > the end, all you have are cell borders, nothing else. I know, the question is for the border-before of (the first row of) the header: for the very first header, border-before on table and table-columns play in the border resolution. Should they also for the headers on the following pages? > > Only in separate border model do you have separate borders on the table > and on the cells. >> Table body(-ies): >> There are several uncertainties: >> - should the border-before of the table and table-columns be considered >> or not: do we consider that those borders only apply to the very first >> (or last) row of the table? Or also to the first (last) row on each >> page? The question remains whether there are headers/footers or not. >> I would say yes. > > http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. The > image should help you understand. An example: take the before border of > the first cell of a table header. The elements that influence the > resolved borders are: table, column-groups if applicable, the column, > table-header, the first row in the table-header and the cell itself. All > the borders of these elements have to be combined. That's what's already > (!) implemented in CollapsingBorderModelEyeCatching (for > border-collapse="collapse") That doesn't tell anything regarding page breaks!? If the table is broken across several pages and the header shall be replicated, do border-before for table and table-column play again in border-resolution for the second and following headers? Or only for the first one? That's the same question as above actually. And that also applies to the first row from the table-body on each page, when header should be omitted at page breaks. >> - when we break /within/ a cell, should the following row come into play >> for computing the border-after? As the row hasn't even been reached >> yet, I'd say no. > > Right. That's the case in CollapsingBorderModelEyeCatching when > currentCell is not null, and otherCell is null. Fine. >> - when we break at a grid line, should the two rows meeting a the line >> count in border resolution? Or only the row before for the >> border-after at the end of the page, and the row after for the >> border-before at the beginning of the following page? >> I would go with that latter. > > That's right. Fine (that means that the border may potentially be different at the bottom of the previous page and at the top of the next page). Do we agree that those two latter cases are not described by the spec? >> - when we break at a grid line, should the entire border appear on each >> page, or the higher half at the bottom of the first page, and the >> lower half at the top of the following page? >> I would also go with that latter. > > No, the entire border has to be painted. This is > BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See > the BorderProps class. So the grid line at the page break would have two borders, one at the bottom of the page, one at the top of the next page? That's fine for me, but again I think it's specified nowhere. >> Tables and breaks: >> - do breaks on headers and footers make sense? Obviously not, excepted >> perhaps a break-before on the header's first row, or a break-after on >> the footer's last row. But as the same effect can be achieved by >> putting the breaks on the fo:table object, I think breaks on >> headers/footers should be entirely discarded. > > Yes, breaks in headers and footers make no sense and should be ignored. Great. > >> Opinions? >> Thanks, >> Vincent > > Jeremias Maerki Thanks, Vincent
Re: Border conditionalities and collapsing-border model, breaks on header/footer
On Mar 23, 2007, at 15:44, Vincent Hennebert wrote: Table headers and footers: Or perhaps that the border-before of the table should still be considered? I mean, for the first header it would come into play, and for following headers it also would only if conditionality=retain. I think I'll go that way as it more closely matches the behavior of the separate border-model. Yes, absolutely agreed! Table body(-ies): There are several uncertainties: - should the border-before of the table and table-columns be considered or not: do we consider that those borders only apply to the very first (or last) row of the table? Or also to the first (last) row on each page? The question remains whether there are headers/footers or not. I would say yes. I think you need to view the columns as 'separate' entities for each body, header and footer: they all need to consider border-before and - after of the columns. - when we break /within/ a cell, should the following row come into play for computing the border-after? As the row hasn't even been reached yet, I'd say no. This also goes in the direction of conclusions drawn in previous discussions about this topic, IIRC. I'd agree with this one too. If the break would fall right between two rows, you would also not consider the next row's before borders when collapsing. - when we break at a grid line, should the two rows meeting a the line count in border resolution? Or only the row before for the border-after at the end of the page, and the row after for the border-before at the beginning of the following page? I would go with that latter. Good choice, see above. - when we break at a grid line, should the entire border appear on each page, or the higher half at the bottom of the first page, and the lower half at the top of the following page? I would also go with that latter. Agreed again. The border-after of the last row on a page is merged either with the table's after border (if retained) or the footer's before border. Tables and breaks: - do breaks on headers and footers make sense? Obviously not, excepted perhaps a break-before on the header's first row, or a break- after on the footer's last row. But as the same effect can be achieved by putting the breaks on the fo:table object, I think breaks on headers/footers should be entirely discarded. I see no explicit restriction prohibiting explicit breaks in header or footer, but I'd also be inclined to ignore them with a warning. Cheers, Andreas
Re: Border conditionalities and collapsing-border model, breaks on header/footer
BTW, don't forget to use the Wiki as resource. Simon and I documented various cases (including the tricky ones) here: http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder2 http://people.apache.org/~jeremias/fop/KnuthBoxesForTablesWithBorders.pdf (The PDF has multiple examples, the last page shows the simplified approach which does not take interaction between body and headers into account when resolving borders) On 23.03.2007 16:54:37 Jeremias Maerki wrote: > > On 23.03.2007 15:44:57 Vincent Hennebert wrote: > > Guys, > > > > I've again stumbled upon uncertainties regarding the handling of > > conditional borders in the collapsing-border model, and breaks inside > > headers/footers. I'd like to have your opinions on these: > > > > > > Table headers and footers: > > Headers and footers are generated only once, and replicated on each > > page. This means that cells in headers and footers only generate one > > area, with the is-first and is-last traits set. Border- and > > padding-conditionality don't apply here. > > Conditionality still applies but because there's a header or footer > serving as fence, the cell borders and paddings don't get discarded. > Different wording, but essentially, yes. > > > Or perhaps that the border-before of the table should still be > > considered? I mean, for the first header it would come into play, and > > for following headers it also would only if conditionality=retain. > > I think I'll go that way as it more closely matches the behavior of the > > separate border-model. > > There's no table border in the collapsing border model when we're > talking about areas. All levels of borders inside a table are merged. In > the end, all you have are cell borders, nothing else. > > Only in separate border model do you have separate borders on the table > and on the cells. > > > > Table body(-ies): > > There are several uncertainties: > > - should the border-before of the table and table-columns be considered > > or not: do we consider that those borders only apply to the very first > > (or last) row of the table? Or also to the first (last) row on each > > page? The question remains whether there are headers/footers or not. > > I would say yes. > > http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. The > image should help you understand. An example: take the before border of > the first cell of a table header. The elements that influence the > resolved borders are: table, column-groups if applicable, the column, > table-header, the first row in the table-header and the cell itself. All > the borders of these elements have to be combined. That's what's already > (!) implemented in CollapsingBorderModelEyeCatching (for > border-collapse="collapse") > > > - when we break /within/ a cell, should the following row come into play > > for computing the border-after? As the row hasn't even been reached > > yet, I'd say no. > > Right. That's the case in CollapsingBorderModelEyeCatching when > currentCell is not null, and otherCell is null. > > > - when we break at a grid line, should the two rows meeting a the line > > count in border resolution? Or only the row before for the > > border-after at the end of the page, and the row after for the > > border-before at the beginning of the following page? > > I would go with that latter. > > That's right. > > > - when we break at a grid line, should the entire border appear on each > > page, or the higher half at the bottom of the first page, and the > > lower half at the top of the following page? > > I would also go with that latter. > > No, the entire border has to be painted. This is > BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See > the BorderProps class. > > > Tables and breaks: > > - do breaks on headers and footers make sense? Obviously not, excepted > > perhaps a break-before on the header's first row, or a break-after on > > the footer's last row. But as the same effect can be achieved by > > putting the breaks on the fo:table object, I think breaks on > > headers/footers should be entirely discarded. > > Yes, breaks in headers and footers make no sense and should be ignored. > > > > > Opinions? > > Thanks, > > Vincent > > > > Jeremias Maerki Jeremias Maerki
Re: Border conditionalities and collapsing-border model, breaks on header/footer
On 23.03.2007 15:44:57 Vincent Hennebert wrote: > Guys, > > I've again stumbled upon uncertainties regarding the handling of > conditional borders in the collapsing-border model, and breaks inside > headers/footers. I'd like to have your opinions on these: > > > Table headers and footers: > Headers and footers are generated only once, and replicated on each > page. This means that cells in headers and footers only generate one > area, with the is-first and is-last traits set. Border- and > padding-conditionality don't apply here. Conditionality still applies but because there's a header or footer serving as fence, the cell borders and paddings don't get discarded. Different wording, but essentially, yes. > Or perhaps that the border-before of the table should still be > considered? I mean, for the first header it would come into play, and > for following headers it also would only if conditionality=retain. > I think I'll go that way as it more closely matches the behavior of the > separate border-model. There's no table border in the collapsing border model when we're talking about areas. All levels of borders inside a table are merged. In the end, all you have are cell borders, nothing else. Only in separate border model do you have separate borders on the table and on the cells. > > Table body(-ies): > There are several uncertainties: > - should the border-before of the table and table-columns be considered > or not: do we consider that those borders only apply to the very first > (or last) row of the table? Or also to the first (last) row on each > page? The question remains whether there are headers/footers or not. > I would say yes. http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. The image should help you understand. An example: take the before border of the first cell of a table header. The elements that influence the resolved borders are: table, column-groups if applicable, the column, table-header, the first row in the table-header and the cell itself. All the borders of these elements have to be combined. That's what's already (!) implemented in CollapsingBorderModelEyeCatching (for border-collapse="collapse") > - when we break /within/ a cell, should the following row come into play > for computing the border-after? As the row hasn't even been reached > yet, I'd say no. Right. That's the case in CollapsingBorderModelEyeCatching when currentCell is not null, and otherCell is null. > - when we break at a grid line, should the two rows meeting a the line > count in border resolution? Or only the row before for the > border-after at the end of the page, and the row after for the > border-before at the beginning of the following page? > I would go with that latter. That's right. > - when we break at a grid line, should the entire border appear on each > page, or the higher half at the bottom of the first page, and the > lower half at the top of the following page? > I would also go with that latter. No, the entire border has to be painted. This is BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See the BorderProps class. > Tables and breaks: > - do breaks on headers and footers make sense? Obviously not, excepted > perhaps a break-before on the header's first row, or a break-after on > the footer's last row. But as the same effect can be achieved by > putting the breaks on the fo:table object, I think breaks on > headers/footers should be entirely discarded. Yes, breaks in headers and footers make no sense and should be ignored. > > Opinions? > Thanks, > Vincent Jeremias Maerki
