> -----Original Message----- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] >
Hi, <snip /> > 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. Ayaa... my mistake indeed! I don't even want to think about what a waste of keystrokes that means --well, if I refrain from typing all ugly names I feel like calling myself, this might begin to compensate :-) <snip /> > I probably don't get what you're targetting at but one thing disturb me > here: you may not have a Row instance. > I always seem to forget that part... *and* it seems to have come across differently than I intended: when I capitalized 'Row' here, I did *not* mean the Java instances, but it refers to a 'logical' Row --which indeed may or may not be 'physically' available as a Row instance, but the groups/sequences of GridUnits in question will be, and that always seems more important to me. Well, what can I say? The starting and ending GridUnits are the row-boundaries. My Row has more or less the same status as a GridUnit, when viewed as a virtual, one-by-one Cell. I get carried away sometimes :-) Then again, maybe this didn't come out well enough, but if part of the condition is that 'p(row) > p(column) > ...', we *should* per se also have at least TableRows and TableColumns at our disposal on which these precedences were specified. If both of them are absent in the source document the full condition would look something like: p(table) > p(body) > p(cell) and p(row) = p(column) Although it was of course a way too rough and simplified description... I immediately noticed a few errors right after the post was out --first border-before on a page after a break should be the body's/header's, not the table's, and even _that_ depends-- but even then, it seems I was still a few steps behind... > > 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) Yes, very important note indeed. > > > 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. No worries. As indicated above: it is more the 'conceptual' row that counts, so... > > The next best place where the functionality of the RowLM lies is the > TableRowIterator. You'd probably pass this one the result. ... yes, indeed. Whatever operates at 'row-level' and thus is in a position to co-ordinate layout for a sequence of GridUnits that together form a row (or a row-group). > 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. 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. 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... :-/ 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(). 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. <snip /> > > 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 ... > > "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. Ok, so they just rather quickly caught my eye, and I may have mistakenly exaggerated their weight here... :-P <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. This can also be considered true of the separate border model, 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... Cheers, Andreas
