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'.

<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?" 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)

Attachment: table-body4c.xml.head.pdf
Description: Adobe PDF document



Attachment: table-body4c.xml
Description: application/text




Greetz,

AD

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to