On 12.05.2005 22:00:54 Andreas L. Delmelle wrote: <snip/> > I get carried away sometimes :-)
Happens to me all the time. This stuff gets so complicated. <snip/> > > 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. > > Partly agreed. The more I think about the starting and ending GridUnits as > row-boundaries, the more it seems like much of the logic I saw 'moving up' > to the row-level would ultimately have to end up in the GridUnit anyway. > Same for the Body, so, very much like it is now. > > Still, I believe we can keep the calculation in one central spot, only split > it up a bit, and steer the parts of that calculation from above (or below, > depending on the view), so that certain parts get executed less frequently. That would be good. I thought about doing something like that but decided to get the functionality done before going into optimization. > i.e. something like TableRowIterator.resolveBorders() on the one hand > finishes the previous row's GridUnit's after-border segments --if any-- and > triggers preparatory work for the next row's GridUnits' resolveBorders(), > while the GridUnits at their end do the same for the before-borders for the > next row (or after-borders of the body/table on breaks), so the next time > the row-iterator arrives at resolveBorders() etc. --and that last call could > also be forced from a break-situation, in the middle of a real 'physical' > row, in order to finish the after-borders of the table/body/footer on the > break, which is the only situation in which the table and body borders > become more relevant. > > This kind of interaction doesn't strike me as increasing complexity that > much. Good, glad to have a hand to help. :-) > Quite on the contrary, since the resolving of the borders also happens > at row-level, which seems to be an attractive place to deal with breaks, as > we should have access to all related border segments in one spot. > Although I may be missing some very nasty consequences here... :-/ There are a few. I'd appreciate if you would invest the time to investigate this. The more people know about this, the better. > I'll > think it over a bit more first, but IMO, possibly having to decide between 5 > or 6 sets of border-specs for the segments of, say 10 grid-units is making > matters more complex than > - rule out 3 or 4 sets once, for all 10 of them > - decide between 2 sets, one GridUnit at a time > ... > - decide between 2 sets, > or possibly finish up in case of a break, one at a time > > One immediate constraint that strikes me is that we would, strictly > speaking, have no definite values for the border-widths of the after-border > segments of a row's GridUnits after the first pass, since the border-widths > for these segments could still be altered by the call to > TRIter.resolveBorders() that would be made between the current row and the > next row (or break)... Ultimately, we would only have a full idea on the > effective settings of a segment after the *last* GridUnit it belongs to has > called resolveBorders(), or *after* an effective break has triggered > TRIter.resolveBorders(). yep. > Can we give the border-resolution a head-start, say create a 'buffer' of > resolved border-specs for up to five rows ahead of the main layout? Hmm... > maybe a bit ambitious... Two iterators running synchronously, but the > 'heavy' one only starts after the 'light' one has reached five, from that > point on, alternate between the two iterators until the first one runs out > of rows, use up the buffer...? Now, that seems interesting, *if* at all > manageable of course. At any rate, you can already look ahead with the TableRowIterator as much as you like. What it's currently missing is a GC mechanism for the rows that are not needed anymore. Means we still have potential problems on long tables. <snip/> > > > 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? > > > > Sorry, I must have been getting a bit sleepy. Picture the same table > upside-down to begin with... But indeed, it's much better to just have one > segment per side of a GridUnit, since the number of them on the before and > after side is obviously a constant for every row. (--Where *was* my head > at?) > > Anyway, I guess my real point was that, IIC, in a collapsing model, one > GridUnit's after-border segment can be the very same object/instance as the > corresponding before-border segment of the GridUnit immediately below (or a > Body's after-border segment on breaks). The table-components literally > 'share' a border-segment... In a way, the segments can be said to exist > independently from the GridUnits, a segment *belongs to* one or two > GridUnits and the other table-components. That's true. This has a particular implication since I'm calculating every border segment twice ATM. > This can also be considered true of the separate border model, Here I disagree. Per border segment you have two potentially different half-border specifications. If you can hold that in that separate data structure, then it's ok again. > but there, > 'resolving' means 'adding to' rather than 'comparing precedence and possibly > replacing'. I guess you could also see it as active (collapsing) vs. passive > (separated) border segments. In the collapsing model, the borders are > 'alive', which seems to be exactly the part that is causing the headaches... Sort of, although I don't like the analogy with active and passive because it introduces more terms in an already complicated environment. Andreas, if you would like to take a stab at the collapsed border resolution, then please do. I'll leave it aside for the moment and will concentrate on implementing or fixing the rest of the important features for table layout (BPD/height props, breaks, keeps, etc.). I hope I wasn't disrespectful by snipping out and not replying to parts of your post. I get the gist of what you have in mind and I think it's at least a way to improve performance (even though we still don't know how fast/slow the current code is). Concerning the collapsing borders and their implication for the combined element generation, I urge you to play through the RowBorder2 example in the Wiki so you see all the problems involved. TableStepper.getNextStep() is also certainly a key point in the whole discussion. Jeremias Maerki
