On 28.07.2005 13:42:08 Andreas L Delmelle wrote: > On Jul 28, 2005, at 10:10, Jeremias Maerki wrote: > > > On 27.07.2005 23:26:48 Andreas L Delmelle wrote: > >> Indeed, doesn't look right. Given the value for the orphans property, > >> one still would reasonably expect the break to occur before the first > >> cell of the second row. > > > > ...or after the first 3 lines of the second row. > > Yes, but IIC, there isn't enough space left on the page to display > those, hence 'break before the row'.
Right. I just wanted to point out all the relevant break possibilities. > <snip /> > > These are all valid possibilities, but as a I hinted I want to discuss > > this at conceptual level not implementation level. I want to know if we > > can have a general rule that we don't allow breaks before every cell > > contributed at least one box to the combined element list. Also, Simon > > and you are talking about providing higher penalty values, but I asked > > about allowing a break at all (i.e. INFINITE penalty, or rather no > > penalty at all, only a box). Considering a penalty value p<INFINITE > > requires a decision that such breaks are possible/desirable in the > > first > > place. > > Well, if it is only the conceptual side that matters ATM, I don't see > any immediate problem with such a rule. Ok. > <snip /> > > Right, but is that rule ok or not from a conceptual view. Are there any > > cases where it might be bad? > > Definitely OK for me. I can't seem to imagine a situation where this > rule might cause undesirable effects. On the contrary, it reminds me of > a question Luca raised some time ago when implementing lists, roughly : > "Is it desirable that, due to a page-break, label and body end up on > different pages?" D'oh. I missed that. Definitely the same problem. > I didn't think it was, and I don't think this should > happen in case of tables either. The different columns in a row should > always be considered together, not one-by-one. So the first column can > never be allowed to end up in its entirety on a different page than the > second. > > Where it comes to rowspans: > In my modified example, if you move all the text in the middle column > to the first row and make that cell span two rows, things get a bit > awkward without the proposed rule anyway. (see attached PDF: the middle > cell doesn't span the two rows, and the 'second' row only has two > cells, and they're considered to be the first and second cell --while > they should actually be the first and third) Ouch. You definitely hit a bug here. The height calculation rule should have placed the two "B"s right under the "A"s (i.e. first row height = 8pt). Jeremias Maerki