How do I prevent orphans and widows in a table over column breaks

[ptoye]

I have a table which is split across 2 columns. The paragraph properties of the text in the table say that orphans and widows should be at least 2 lines long, but it’s splitting the table cells across the columns and producing orphans and widows.

Is there any way of stopping this?

I’ve tried setting the table properties to prevent breaks. This gets rid of the orphans & widows, but it also keeps text which should be split together. Also, it loses the descenders when the bottom line of text coincides with the bottom of the text area (this looks like a bug to me).

[Edited 17/12/19] Here’s an example of what goes wrong.LO table issues.odt

[ajlittoz]

Have you tried in Table>Properties, Textflow tab to enable only table split without enabling row split?

With such a setting, cells are not split but this could generate a large white space between rows (as they are laid out in their entirety of a page).

What do you mean by “but it also keeps text which should be split together” ? Is this a matter of synchronising content between columns?

[ptoye]

I need to keep the rows of the table synchronised - that’s why it’s a table - but not between the columns. The basic reason is that I’m producing some output on landscape paper, and want the table in two columns to avoid wasting a lot of space. I’m getting some odd results at the moment, and have to stop work today. I’ll post a small example tomorrow.

[ajlittoz]

Using an answer instead of a comment because of limited space in a comment.

Your document uses 2-column sections. Within these section you insert a 2-column table. This creates a complicated context.

Internally, the table is built as if the section had an infinite length. This gives the full height of the table. The table is then split in order to try to balance height in section columns.

Your section 1 exhibit this behaviour with a split at line closest to mid-height. Notice that portions of the table are not equal in their respective columns.

In section 2, you have a shorter table and the algorithm splits the table closest to mid-height too. Once this is done, text is laid out, without consideration for orphan/widow because split decision is already made.

I think there is a complex interaction between two split criteria: the one in paragraph text flow and the one in table text flow. In my opinion, the table criterion takes precedence over the paragraph because the table is the “outermost object” to be formatted in the page. The paragraph is contained therein and is laid out within the limits of the table and its cells.

Section 3 is a bit different. Space remaining at the bottom of the page would be sufficient if the table were split exactly at its middle. However since lines must be shown in their entirety, first column is cut shorter than the middle, which leaves a taller second column. This second column meets the bottom of the page. Since split decision is already made, there is no reason to split again (for a few pixels only) otherwise you probably enter an infinite decision loop. Because margins are a strict no-print zone, text is clipped and descenders disappear.

Note: I met such a clipping with frames extending too far in their container.

Weird behaviour: if I play with the section 2 table properties (split and break attributes), the table displays either as single rows in separate columns or full table in first column. Restoring the attributes does not revert to initial formatting (even with Tools>Update>Page Formatting) ! I must add content in a cell and remove it to cause a real page formatting update.

I noticed this strange behaviour in a complex document of mine with same characteristics: 6-8 columns section with a 3-column table. Editing this table is a deep nightmare with sometimes full columns becoming empty (content flushed to next column), spurious page breaks or uneven columns. The cure is always add-then-remove content. However, this will not solve the widow/orphan issue.

[ptoye]

Thanks. That’s a very full analysis, and I really appreciate the time you must have taken to do it.

You’ve managed to explain what’s happening, but unfortunately it doesn’t help to find a solution - and I suspect there isn’t one. I think that I will give up trying to format this particular document the way I want it.

[ajlittoz]

You’re welcome.

IMHO, orphan/widow controls are ineffective in a table, at least within a sub-page section, because we don’t really meet a page boundary.

[keme]

It looks like table content is “once removed” from page level, so the page break does not “touch” it, in the logic of Writer document structure. As far as I can tell, it is not possible to make it work for table contents, nor for frames, nor simulate it with conditional styles.

A possible workaround may be to use a page setup with columns, and insert a section with columns into that. Section content exists on “page level”, so widows/orphans are caught in the cases I have looked at.

See attachment. It is just a quick mockup ; I haven’t tested it thoroughly. Also I am not at my usual computer so I used OpenOffice Writer. For this kind of work it should be the same in LO Writer, but I haven’t confirmed that it actually is.The approach may work in some settings, and make a total mess in others. See what you can make of it.

[ptoye]

Hmmm. I can’t work out how you produced the attachment so can’t comment…

See my comment to @ajlittoz above.

[keme]

I can’t work out how you produced the attachment

1. Menu Format - Columns to format the page to two columns
2. Menu Insert - Section then set the section to also have two columns. (See the Columns tab in the section dialog.)

Columns will automatically “reflow” to balance the content, but you can control that to some degree by inserting a column break.

Where you would normally use a new table row, with this approach you need a new section instead.

[ptoye]

Thanks. I was already using sections ( should I have mentioned that?) as there’s also 1-column text. See the example I posted above for that. I’ve just found out (the help files don’t seem to say anything) that you can have sections within sections, so your solution should work.

The loss of descenders at the bottom of the page is very worrying. I don’t know if it will happen with your idea. But it looks like a bug anyway.

[Added later]Once I’d worked out how to put a section within a section, I found that the columns for the inner section don’t fall within the columns for the outer one - they span the entire page, which I suppose is logical-ish. So that solution doesn’t work. I’d have to work out the width of each outer section column and how to split it up into the original table columns which aren’t even equally-sized. And keep it consistent if I want to adjust it later, which seems a real pain.