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