You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Vincent Hennebert <vi...@anyware-tech.com> on 2007/03/23 15:44:57 UTC
Border conditionalities and collapsing-border model, breaks on header/footer
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.
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.
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.
- 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.
- 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.
- 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.
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.
Opinions?
Thanks,
Vincent
Re: Border conditionalities and collapsing-border model, breaks on header/footer
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 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?
There's not one grid line, but two. Each can have a different border.
Same problem as above. Think grid units (=GridUnit.java hint hint)!
> 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
Jeremias Maerki
Re: Border conditionalities and collapsing-border model, breaks on header/footer
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 26, 2007, at 11:31, Vincent Hennebert wrote:
> <snip />
> And there is a remaining question raised by Andreas:
>
> <snip/>
> [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
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
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 xsl-editors@.
And there is a remaining question raised by Andreas:
<snip/>
[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...
>
>> <snip />
>>>> - 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 ;-)
<snip/>
>>>> - 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
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 23, 2007, at 18:21, Vincent Hennebert wrote:
[Jeremias: ]
>> <snip />
>> http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that.
<snip />
>> 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...
> <snip />
>>> - 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
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
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
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: Border conditionalities and collapsing-border model, breaks on header/footer
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 23, 2007, at 15:44, Vincent Hennebert wrote:
> Table headers and footers:
> <snip />
> 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