On 11.05.2005 00:52:21 Andreas L. Delmelle wrote:
<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.

Hmm, I think you got the wrong impression. It's not that I'm having
problems with the border resolution. This actually works fine by now even
if it might need some additional tweaking for calculating new
constellations in break conditions. The design of the resolution is
already prepared to easily handle the "precedence" variant. It's just a
matter of creating an additional subclass (of CollapsingBorderModel).
The data sources for the decisions are there. The real problem lies
within the effects that borders have on the generated combined elements
list after they have been resolved. I'm sorry for not making that clear
enough. Still....(read on below)

> 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...

Hmm, I actually left that away simply because I thought it would be
quite simple. I could be wrong though.

> 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

I probably don't get what you're targetting at but one thing disturb me
here: you may not have a Row instance.

> 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

(for non-break conditions)

> and pass that result to the RowLM, 

I don't use the RowLM anymore. There's only the TableLM, the
TableContentLM and the CellLM. I know I should have removed the obsolete
LMs by now. I simply was too deep in the mud to notice.

The next best place where the functionality of the RowLM lies is the
TableRowIterator. You'd probably pass this one the result.

> 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.

I can see the potential benefit by not having to take all the
influencing border sources into account, but precalculating some border
and thus optimizing the code a bit. The beauty of the current approach
IMO lies within the concentration of the calculation in one spot. I
think your approach would make the border resolution more decentralized
and therefor harder to track down in the already complex maze.

> 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.

"constant need"? There are four calls to GridUnit.resolveBorder() in the
code, one for each side. There will be a couple of additional ones once
we have figured out how to resolve (or better store) the borders for the
break conditions.

resolveBorder() calls go straight into determineWinner() calls on the
CollapsingBorderModel. It's not that awkward, is it?

> 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.

That may be an idea. At the moment each resolved border segment is
always calculated twice, for example, once coming from the start side of
one cell and once coming from the end side of the neighbouring cell on
the left. I think that is probably the one downside from my current
approach which, given approriate data strutures, could optimize the
thing a bit.

> 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....

Now you lost me. I see a border segment as identical to a GridUnits
border (not a cell's border). That's the impression I got from the spec.
Are you talking about handling column spanning here?

> Then again, it seems only *really* necessary for before- and after-borders.

Not really. If you want to be thorough you'd have to do this for the
other two sides, too, to get more optimization potential.

> 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?)

No, that's about it.

> In theory --here I go again...-- it would then be the BorderSegments that
> need information on the border specs on Table/Body/Row/(Column?)/

(column group)/ (=spanned column def, which is the only thing that is
left out ATM)

> 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.

I don't think it would have saved much. We'd certainly have a little less
computation per border segment but I think it would make the code more
complex (border resolution more distributed) which, for tables, is not
very welcome.

> Hope this helps! :-)

Well, as I said, I don't think the border resolution per se is the
problem. It's the effects into the element generation. 

Jeremias Maerki

Reply via email to