> -----Original Message-----
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
>

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

Reply via email to