Glen, no, I'm afraid the isBogus() method is necessary because it checks the parent LM. In the markers6a.xml example (for which I still have to write the checks, I just found out), the block in the third cell of the fifth row has an effective BPD of 0 and therefore fits nicely into the available stacking dimension. Therefore its BreakPoss doesn't have the nextBreakOverflows() return true. But the row in which that block and its parent cell are found has an overflow because of the first two cells which don't fit. If isBogus() doesn't check the parentLM the markers for row 5 are added to page 1 which is wrong.
I think I'll commit my patch as is tomorrow. This will solve the problem for now, but I have a feeling that I might have to do some additional work on the BreakPoss part quite soon when I get to tasks such as keeps which is quite soon now. The isBogus() method is easily removed if it turns up later that it can be handled differently and in a better way. On 06.02.2005 04:43:48 Glen Mazza wrote: > Jeremias, > > I don't see the need for the bBogus variable/isBogus() > method, because in the three or four places where the > value of this variable is actually *being used*, it is > just set to : > > bBogus = !bp1.generatesAreas(); > > So it appears you can just rely on > "!bp1.generatesAreas()" in these places > instead--perhaps just commenting the conditional that > bogus areas are being ignored--and we can worry about > getting rid of the actual bogus areas later (when > overall team grokkage in this part of the code > improves). > > Glen > > --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > > I've got a possible fix for the problem. But I don't > > know if it's not > > too much of a hack. At least it somehow feels like a > > hack. Any comments > > about the attached patch? Obviously, some javadocs > > are missing and the > > naming could probably be improved but this is just > > an idea how this > > could be fixed. > > > > IMO it would be nicer if these "bogus" areas as I > > call them wouldn't be > > constructed at all. I experimented with such an > > approach but the code > > got far too complicated with too much > > copy/paste/modify. And I also > > didn't manage to make it work. On the other side > > these special areas > > are not a big problem since there are relatively few > > of them. > > > > Still interested in opinions and ideas.... Thanks! > > Jeremias Maerki
