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.


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

Jeremias Maerki

Reply via email to