-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
On 10.05.2005 20:41:19 Simon Pepping wrote:
Hi guys,
For starters: my vote is +1.
I agree with Simon, and also very much feel like we're on the right track
with this. Sure, it will *still* take some work...
snip /
Jeremias, what do you mean with complexity in certain areas? Tables
only, or are there other complexities that you perceived as
overwhelming?
No, it's mainly the complexity of the collapsed border model ...
Yes, I've been thinking and reading up on that stuff, and somehow it seems a
bit --a tiny bit-- simpler if you try to figure out
'collapse-with-precedence' first, since you have to decide on a purely
numerical basis, so it may facilitate translation into an algorithm. The
'Eye Catching' question could then be solved as a scenario with fixed
precedence values for the different styles, plus a factor for the widths,
etc.
Still, after a look at the code and the Wiki, I had the impression that this
path hadn't yet been taken into consideration, so hopefully this offers some
relief...
Starting with the simplest case, a rough description:
p(table) p(body) p(row) p(column) p(cell) means
table-border for
border-start of the first GridUnit in a Row
border-end of the last GridUnit in a Row
border-before of all GridUnits in the first Row of a (sub)page
border-after of all GridUnits in the last Row of a (sub)page
row-border for
border-before of all GridUnits not in the first Row of a (sub)page
border-after of all GridUnits not in the last Row of a (sub)page
column-border for
border-start for all GridUnits except when first in a Row
border-end for all GridUnits except when last in a Row
body-borders and cell-borders are overruled
Mind the Capitals, and what I have already mentioned in a previous
post --about doing part of the resolving at row-level-- begins to make a bit
more sense now. When the BodyLM is initialized, you can already decide
between 'table' and 'body' borders and pass that result to the RowLM, that
passes that result OR its own border-specs to its GridUnits, and the
GridUnits ultimately only have to decide between the relevant 'row'-borders,
'column'-borders and their own... I think one would have a hard time getting
closer to the meaning of 'collapsing' than this approach.
What seemed a bit awkward while I was browsing through the relevant code was
the constant need to pass the 'side' of the GridUnit around when resolving
the border :-/ Still, that seems more like a consequence of delaying the
entire border-resolving process until the level of the GridUnit is reached.
Also, I was juggling with the idea of creating a BorderSegment object that
operates in conjunction with the GridUnit, but 'in between and over' Rows as
it were... Instead of having a GridUnit 'resolve its own borders', the
BorderSegments 'resolve themselves' at the appropriate time. In essence,
those segments need to know nothing about 'before' or 'after', 'start' or
'end', they just pick the right border spec from the given set. What gave me
this idea, was Simon's example, where you need information about the
GridUnits for the full two rows --to know how many segments there are, how
they are distributed and which sets of border-specs are relevant for each of
the segments.
When the first row is finished, we would have two unfinished segments of
after-borders. Make these available to the next row as preliminary
before-border segments, which it can then resolve with its own. Next, we
already know that this row contains three cells, so we need some sort of
distribution method here --i.e. calculations based on relevant GridUnit
IPD?-- to give an indication as to which segment(s) need to be split into
how many parts
Then again, it seems only *really* necessary for before- and after-borders.
The border-specs for the vertical border segments could be made available to
a GridUnit through the Column (? via the Row's column list: end-border of
previous GridUnit = the resolved start-border of the current GridUnit's
Column --Or am I thinking too linear --too LRTB, maybe?)
In theory --here I go again...-- it would then be the BorderSegments that
need information on the border specs on Table/Body/Row/(Column?)/Cell for at
most two cells at the same time. I don't know if, in practice, this idea
would save much compared to what you currently have... but it somehow seems
attractive, especially in combination with the approach of resolving in
different stages.
Hope this helps! :-)
Cheers,
Andreas
