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 Jeremias Maerki <de...@greenmail.ch> on 2005/05/03 15:14:50 UTC
Collapsing border model
I've just realized I probably made a big mistake interpreting collapsing
border model. While going through the specs to reread everything about
the outer table border I carefully reread the following passages:
XSL-FO 1.0, 6.7.2, Trait Derivation:
"If the value of the "border-collapse" property is "collapse" or
"collapse-with-precedence" the border is determined, for each segment,
at the cell level."
So far I've based everything on being determined, for each segment, at
the segment level as it seems. I even had the part about "cell level"
highlighted in my print-out and still got it wrong. Damn me!
But I think I know why I got it wrong:
XSL-FO 1.0, 6.7.10, Trait Derivation:
"If the value of the border-collapse trait is "collapse", the border for
each side of the cell is determined by, for each segment of a border,
selecting, from all border specifications for that segment, the border
that has the most "eye catching" border style..."
Obviously sounded too much like a per-segment thing.
Under the new light, this means a totally different thing. Looking at my
(buggy) example [1] this means that the segment where the arrow points
should actually be the same broad red border as the one next to it on
the right side.
That also means that it's making the whole border resolution a lot more
complicated. If you started with the upper left cell and tried to
determine the after border you can end up taking the after border
specification from the cell on the right side of the cell. I'll have to
think about how to implement this in an efficient way, first.
But before I turn everything upside-down again, can please someone
confirm that I was really wrong before and got it right now? Thanks a
lot.
[1] http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel
Jeremias Maerki
PS: Can someone please beat me?
Re: Collapsing border model
Posted by Jeremias Maerki <de...@greenmail.ch>.
Thanks everyone for helping me with this.
On 05.05.2005 20:43:58 Simon Pepping wrote:
> Jeremias,
>
> At first sight I agree with Andreas' interpretation in his reply to
> this message, which I think is the same as your original
> interpretation. Thinking on, however, I see that there may be a
> problem with spanned cells. Is that what you are aiming at?
Yes, exactly.
> The cell level, means the level of the spanned cell. This suggests
> indeed that each side of a spanned cell must be treated as a whole.
> However, the spec says precisely:
>
> > "If the value of the "border-collapse" property is "collapse" or
> > "collapse-with-precedence" the border is determined, for each segment,
> ^^^^^^^^^^^^^^^^
> > at the cell level."
Yes, but it's the "cell level" part that made think twice. I now
interpret the "each segment" part in the way that each segment has to be
taken to get at the candidates for a non-segmented cell border.
> and
>
> > "If the value of the border-collapse trait is "collapse", the border for
> > each side of the cell is determined by, for each segment of a border,
> ^^^^^^^^^^^^^^^^
> > selecting, from all border specifications for that segment, the border
> > that has the most "eye catching" border style..."
At the moment I'm not sure what to think. There are parts of this
sentence that let me run on one direction, others let me run in the
opposite direction.
> Moreover, the term 'cell level' is rather vague, and certainly not the
> same as 'per cell'.
>
> That seems to mean that the determination is done per segment indeed,
> which agrees with your original interpretation. Note that the spec
> does not define the notion of a segment, nor does the CSS2 spec. But I
> take it to mean the side of a grid unit.
Let's hope so.
> Your Wiki example shows a result that is probably undesirable, a
> spanned cell with vastly different border segments. But apparently the
> spec does not protect the user from specifying such a border
> arrangement.
...if the original interpretation was correct.
> Probably it is not possible to define resolution of collapsing border
> specifications per cell. Consider the following example:
>
> +--------+----------------+--------+
> | | | |
> | | | |
> | | | |
> | | | |
> +--------+-------+--------+--------+
> | | |
> | | |
> | | |
> | | |
> +----------------+-----------------+
>
> On the border between rows 1 and 2 each segment is part of two cell
> borders. Conflicting border specifications can only be resolved per
> segment, not per cell.
Actually, I think it could but the implications are dreadful. Actually,
so far this is the one reason in all this that urges me to believe that
the original interpretation was indeed correct.
> Note also this remark in the spec (6.7.3 fo:table) about the
> background of spanned cells: "A cell that is spanned may have a
> different background in each of the grid units it occupies." This is
> somewhat similar to the spec allowing different segments on a side of
> a spanned cell.
But that's because you have backgrounds on various levels (rows, columns,
column groups, row groups). If you specify the background on a spanned cell
it fills all the occupying grid units. You have no means to directly specify
a background (at least on cell level) for each of the occupying grid
unit.
Again, thanks for helping me here. I guess it's best to just leave it
like it is right now. It's a lot better than nothing even if the
interpretation turns out to be wrong at one point. It also leaves the
whole thing simpler. These are, after all, only nits but with a big
impact on the complexity. And BTW, a XEP trial version matches more or
less my original interpretation even though I found some diffences on
start and end borders.
Jeremias Maerki
RE: Collapsing border model
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Simon Pepping [mailto:spepping@leverkruid.nl]
>
Hi Simon,
> At first sight I agree with Andreas' interpretation in his reply to
> this message, which I think is the same as your original
> interpretation. Thinking on, however, I see that there may be a
> problem with spanned cells. Is that what you are aiming at?
Aah, yes! I knew there was something I was overlooking...
>
> The cell level, means the level of the spanned cell. This suggests
> indeed that each side of a spanned cell must be treated as a whole.
> However, the spec says precisely:
>
> > "If the value of the "border-collapse" property is "collapse" or
> > "collapse-with-precedence" the border is determined, for each segment,
Indeed, and as you point out below --and I also recall from reading the CSS2
spec-- that segment is actually meant to be the 'intersection between a row
and a column', such that a row- and column-spanning cell can have different
borders and backgrounds for each of the grid-units it occupies.
<snip />
> Moreover, the term 'cell level' is rather vague, and certainly not the
> same as 'per cell'.
>
> That seems to mean that the determination is done per segment indeed,
> which agrees with your original interpretation. Note that the spec
> does not define the notion of a segment, nor does the CSS2 spec. But I
> take it to mean the side of a grid unit.
>
> Your Wiki example shows a result that is probably undesirable, a
> spanned cell with vastly different border segments. But apparently the
> spec does not protect the user from specifying such a border
> arrangement.
>
> Probably it is not possible to define resolution of collapsing border
> specifications per cell. Consider the following example:
>
> +--------+----------------+--------+
> | | | |
> | | | |
> | | | |
> | | | |
> +--------+-------+--------+--------+
> | | |
> | | |
> | | |
> | | |
> +----------------+-----------------+
>
> On the border between rows 1 and 2 each segment is part of two cell
> borders. Conflicting border specifications can only be resolved per
> segment, not per cell.
Yes and no. Ultimately this problem always poses itself, even in very basic
table-grids, for the first cell's after-border, you might have to wait until
the before-border for the first cell below it is known... (to be able to
fully and correctly resolve the after-borders for the cells in one row, we
need the before-border info for the cells in the next row as well)
The only thing that seems quite impossible (to me, maybe in error) is that
there would be different borders on two sides of the same gridline. In
Jeremias' example this would mean that IF the entire before-border of the
spanning cell has to be the thick red border, THEN this border-style would
also be applicable to the after-border of *both* cells immediately above.
(and suddenly I think I see what Jeremias meant by 'ending up taking the
after-border of the cell to the right...' in his OP)
OTOH, as Jeremias just pointed out in his reply, IF borders are specified at
the cell-level, and the cell spans multiple columns/rows, then that border
would be a candidate for _all_ the relevant segments --not only the first
grid-unit it occupies. If it is dominant over all the others you would end
up with a uniform border on all segments.
Cheers,
Andreas
Re: Collapsing border model
Posted by Simon Pepping <sp...@leverkruid.nl>.
Jeremias,
At first sight I agree with Andreas' interpretation in his reply to
this message, which I think is the same as your original
interpretation. Thinking on, however, I see that there may be a
problem with spanned cells. Is that what you are aiming at?
The cell level, means the level of the spanned cell. This suggests
indeed that each side of a spanned cell must be treated as a whole.
However, the spec says precisely:
> "If the value of the "border-collapse" property is "collapse" or
> "collapse-with-precedence" the border is determined, for each segment,
^^^^^^^^^^^^^^^^
> at the cell level."
and
> "If the value of the border-collapse trait is "collapse", the border for
> each side of the cell is determined by, for each segment of a border,
^^^^^^^^^^^^^^^^
> selecting, from all border specifications for that segment, the border
> that has the most "eye catching" border style..."
Moreover, the term 'cell level' is rather vague, and certainly not the
same as 'per cell'.
That seems to mean that the determination is done per segment indeed,
which agrees with your original interpretation. Note that the spec
does not define the notion of a segment, nor does the CSS2 spec. But I
take it to mean the side of a grid unit.
Your Wiki example shows a result that is probably undesirable, a
spanned cell with vastly different border segments. But apparently the
spec does not protect the user from specifying such a border
arrangement.
Probably it is not possible to define resolution of collapsing border
specifications per cell. Consider the following example:
+--------+----------------+--------+
| | | |
| | | |
| | | |
| | | |
+--------+-------+--------+--------+
| | |
| | |
| | |
| | |
+----------------+-----------------+
On the border between rows 1 and 2 each segment is part of two cell
borders. Conflicting border specifications can only be resolved per
segment, not per cell.
Note also this remark in the spec (6.7.3 fo:table) about the
background of spanned cells: "A cell that is spanned may have a
different background in each of the grid units it occupies." This is
somewhat similar to the spec allowing different segments on a side of
a spanned cell.
Regards, Simon
On Tue, May 03, 2005 at 03:14:50PM +0200, Jeremias Maerki wrote:
> I've just realized I probably made a big mistake interpreting collapsing
> border model. While going through the specs to reread everything about
> the outer table border I carefully reread the following passages:
>
> XSL-FO 1.0, 6.7.2, Trait Derivation:
> "If the value of the "border-collapse" property is "collapse" or
> "collapse-with-precedence" the border is determined, for each segment,
> at the cell level."
>
> So far I've based everything on being determined, for each segment, at
> the segment level as it seems. I even had the part about "cell level"
> highlighted in my print-out and still got it wrong. Damn me!
>
> But I think I know why I got it wrong:
>
> XSL-FO 1.0, 6.7.10, Trait Derivation:
> "If the value of the border-collapse trait is "collapse", the border for
> each side of the cell is determined by, for each segment of a border,
> selecting, from all border specifications for that segment, the border
> that has the most "eye catching" border style..."
>
> Obviously sounded too much like a per-segment thing.
>
> Under the new light, this means a totally different thing. Looking at my
> (buggy) example [1] this means that the segment where the arrow points
> should actually be the same broad red border as the one next to it on
> the right side.
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Collapsing border model
Posted by Jeremias Maerki <de...@greenmail.ch>.
As I have proven a few times now I'm not without flaws. :-) That's where
we need peer-review. Thanks for looking into this.
On 03.05.2005 21:03:49 Simon Pepping wrote:
> I am afraid I just followed your interpretation. I will try to read
> the spec more independently and more critically.
Jeremias Maerki
Re: Collapsing border model
Posted by Simon Pepping <sp...@leverkruid.nl>.
I am afraid I just followed your interpretation. I will try to read
the spec more independently and more critically.
Regards, Simon
On Tue, May 03, 2005 at 03:14:50PM +0200, Jeremias Maerki wrote:
> I've just realized I probably made a big mistake interpreting collapsing
> border model. While going through the specs to reread everything about
> the outer table border I carefully reread the following passages:
>
> XSL-FO 1.0, 6.7.2, Trait Derivation:
> "If the value of the "border-collapse" property is "collapse" or
> "collapse-with-precedence" the border is determined, for each segment,
> at the cell level."
>
> So far I've based everything on being determined, for each segment, at
> the segment level as it seems. I even had the part about "cell level"
> highlighted in my print-out and still got it wrong. Damn me!
>
> But I think I know why I got it wrong:
>
> XSL-FO 1.0, 6.7.10, Trait Derivation:
> "If the value of the border-collapse trait is "collapse", the border for
> each side of the cell is determined by, for each segment of a border,
> selecting, from all border specifications for that segment, the border
> that has the most "eye catching" border style..."
>
> Obviously sounded too much like a per-segment thing.
>
> Under the new light, this means a totally different thing. Looking at my
> (buggy) example [1] this means that the segment where the arrow points
> should actually be the same broad red border as the one next to it on
> the right side.
>
> That also means that it's making the whole border resolution a lot more
> complicated. If you started with the upper left cell and tried to
> determine the after border you can end up taking the after border
> specification from the cell on the right side of the cell. I'll have to
> think about how to implement this in an efficient way, first.
>
> But before I turn everything upside-down again, can please someone
> confirm that I was really wrong before and got it right now? Thanks a
> lot.
>
>
> [1] http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel
>
> Jeremias Maerki
>
> PS: Can someone please beat me?
>
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Collapsing border model
Posted by Jeremias Maerki <de...@greenmail.ch>.
Whatever helps. Thanks!
On 04.05.2005 04:14:51 Peter B. West wrote:
> Jeremias Maerki wrote:
> >
> > PS: Can someone please beat me?
>
> Stick, riding crop, whip, rope, chain or plain old bare knuckles?
>
> Peter
> --
> Peter B. West <http://cv.pbw.id.au/>
> Folio <http://defoe.sourceforge.net/folio/> <http://folio.bkbits.net/>
Jeremias Maerki
Re: Collapsing border model
Posted by "Peter B. West" <li...@pbw.id.au>.
Jeremias Maerki wrote:
>
> PS: Can someone please beat me?
Stick, riding crop, whip, rope, chain or plain old bare knuckles?
Peter
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/> <http://folio.bkbits.net/>
RE: Collapsing border model
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev.jeremias@greenmail.ch]
>
> I've attached the picture and an FO file I wrote today to mimic that
> picture.
Apologies. Damn *me* now for not having tried this with a decent browser...
of course IE will let you down.
More feedback probably tomorrow.
Cheers,
Andreas
Re: Collapsing border model
Posted by Jeremias Maerki <de...@greenmail.ch>.
I've attached the picture and an FO file I wrote today to mimic that
picture.
BTW, the pictures worked fine for me the whole day. They are all here:
http://people.apache.org/~jeremias/fop/
Alternatively, if you log into cvs.apache.org you can cd into
/x1/home/jeremias/public_html/fop to get them.
On 03.05.2005 19:40:39 Andreas L. Delmelle wrote:
> > -----Original Message-----
> > From: Jeremias Maerki [mailto:dev.jeremias@greenmail.ch]
> >
>
> Hi,
>
> <snip />
>
> BTW: Am I the only one who has trouble viewing the pictures on the wiki
> page? (It seems to be the only one with which I have problems. The other
> table-related pages show up nicely...)
>
> > That also means that it's making the whole border resolution a lot more
> > complicated. If you started with the upper left cell and tried to
> > determine the after border you can end up taking the after border
> > specification from the cell on the right side of the cell.
>
> Are you talking about what our current implementation *would* end up taking
> as after border, or what *should* be taken as after border according to the
> spec?
*should* :-(
> In the latter case, if you mean 'start/end', I'm game, but I don't see how
> the 'after' border of the first cell to the right of a given cell could
> influence the 'after' border of that cell... If the "border is determined,
> for each segment, at the cell level" that seems to mean a decision at the
> cell level between:
>
> - table
> - body (header / footer)
> - column
> - row
> - neighbouring cells
> * start ~ border-end of first cell to the left
> * end ~ border-start of first cell to the right
> * before ~ border-after of first cell above
> * after ~ border-before of first cell below
> - the cell itself
>
> for each of the border segments: start - before - end - after
>
> One optimistic note: all of the above options can't be an option at the same
> time for one and the same cell... and the decision between row borders and
> table borders, for instance, could already be resolved at row level, such
> that, when the borders are determined at cell level, the cell only needs to
> query the row, column and neighbouring cells (not reach back up to the body
> and table).
Got to think that through first. It might speed things up a little.
> > But before I turn everything upside-down again, can please someone
> > confirm that I was really wrong before and got it right now? Thanks a
> > lot.
>
> If I could only see the images...
>
>
> Cheers,
>
> Andreas
Jeremias Maerki
RE: Collapsing border model
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev.jeremias@greenmail.ch]
>
Hi,
<snip />
BTW: Am I the only one who has trouble viewing the pictures on the wiki
page? (It seems to be the only one with which I have problems. The other
table-related pages show up nicely...)
> That also means that it's making the whole border resolution a lot more
> complicated. If you started with the upper left cell and tried to
> determine the after border you can end up taking the after border
> specification from the cell on the right side of the cell.
Are you talking about what our current implementation *would* end up taking
as after border, or what *should* be taken as after border according to the
spec?
In the latter case, if you mean 'start/end', I'm game, but I don't see how
the 'after' border of the first cell to the right of a given cell could
influence the 'after' border of that cell... If the "border is determined,
for each segment, at the cell level" that seems to mean a decision at the
cell level between:
- table
- body (header / footer)
- column
- row
- neighbouring cells
* start ~ border-end of first cell to the left
* end ~ border-start of first cell to the right
* before ~ border-after of first cell above
* after ~ border-before of first cell below
- the cell itself
for each of the border segments: start - before - end - after
One optimistic note: all of the above options can't be an option at the same
time for one and the same cell... and the decision between row borders and
table borders, for instance, could already be resolved at row level, such
that, when the borders are determined at cell level, the cell only needs to
query the row, column and neighbouring cells (not reach back up to the body
and table).
> But before I turn everything upside-down again, can please someone
> confirm that I was really wrong before and got it right now? Thanks a
> lot.
If I could only see the images...
Cheers,
Andreas