Writer: multi-column section formatting glitch

[ajlittoz]

LO 5.4.4.2 (but also happens in previous versions), Fedora 27, Plasma desktop

In my complex and long document, I switch from 1-column main text to 4-columns sections to insert long (=many rows) tables of key/value pairs. There are several such tables, consequently, I alternate between 1-col and 4-col sections.

I chose to insert my tables in 4-col sections because I want table content to spread evenly inside the page instead of having narrow “text” surrounded by large white space.

This works fine until editing work before the table sections cause a table section to cross a page limit. This involves some hard computation in Writer about which rows should be pushed to next column(s) and which part of the table will be rejected on next page.

Sometimes, Writer gets lost in the middle of the part left on the initial page: columns are correctly reformatted but all of a sudden last columns remain blank and part of table on next page does not start in first column of section.

To complicate matters, this is not systematic. Saving and reopening document does not necessarily solve the problem. To make things worse, it happens only in big documents (I tried to prepare a 10-page sample to attach to this question but when I saved and reopened the sample, formatting was magically restored). Consequently, I can’t provide an example of this wicked demeanour.

See this screenshot to get an idea:

You’ll also notice that column content is not evenly distributed at top of second page.

My present workaround is to type Enter in the last line of the last cell before the invalid page break to cause text to spill over in next column, which triggers a formatting update, then to erase the added paragraph. I repeat this in all column bottoms, which is tedious considering the total number of tables and columns.

Can this be the result of unforeseen interaction between tables and multicolumn sections?

Have I exceeded some Writer limitation? (once again happens only on really big and complex docs)

(Refreshed 2018-03-24 because it striked again)

Sorry to upload the complete file, but it only happens on relatively big documents: document removed. Go to appandix A. This instance is real havoc ;-). Incidentally, there is another glitch I can’t solve: duplicate page number in doc licence.

EDIT 2018-03-26: removed the attached file

[dajare]

Hi @ajlittoz - (I edited just to make your screenshot “clickable”, by the way.) Interesting/nasty problem. I appreciate why you use this method. But given the annoyance … would it be better simply to divide your key/value pairs “manually” into 8-column tables, and then no need for sections/multi-columns? Or can they be “framed” (? not something I use very often, if at all, in Writer myself, so just thinking out loud). If you could upload even a “working” sample, we could try to replicate.

[PYS]

Hi @ajlittoz -

Would it be possible that the support for split sections inside tables provided by version 6 improves things (cf. release notes)?

Regards

[ajlittoz]

@PYS: my case in not a section inside a table but a table inside a section. Present feature is OK if it were bug-free.

[ajlittoz]

@dajare: manually dividing into 8-column table could be done for frozen-content tables with loss of inter-column gutter (unless playing tricks with borders as suggested in another answer). However, there is another document in work-in-progress state, where automatic multi-column reconfiguration when rows are inserted/deleted is really a full delight. With an 8-column table (which was the initial situation), it’s really a pain to balance table.

[dajare]

Hi @ajlittoz - Here’s what that appendix looks like on my system: Ubuntu 18.04 with LibO 1:6.0.2-0ubuntu1. Is that an improvement on what you’re seeing?

[ajlittoz]

@dajare: that’s exactly how it should look. Maybe it’s a matter of LO version. I’ll wait for 6.0.x to come up in my distro (Fedora). Do you also see page number 1 (i in fact because it’s roman) duplication in doc licence?

[dajare]

@ajlittoz - I’m not 100% clear on what that glitch is: but the Licence/ToC spread (if that’s the one you mean) looks fine to me: no number on page preceding ToC; ToC itself begins on page i, and Main Text begins on 1. All OK? (That’s now on home machine: little MacBook running OSX Yosemite 10.10.5 with Collabora LibO Version: 6.0.2.1.)

[ajlittoz]

@dajare: no, the glitch occurs in the final “chapter”, after appendix B.

Note on the table bad formatting: it occurs randomly; try to add/remove text begore table to cause a change of number of lines across page break to see if it happens with your LO version.

[dajare]

I’ll post this as a partial answer, mainly responding to the bit about: “Incidentally, there is another glitch I can’t solve: duplicate page number in doc licence.”

First: the initial presenting problem, the multi-column table editing problem, I think is now fixed in v. 6.0+ – here’s some added text, and the “re-flow” seemed to me to be swift and flawless:

So, on to the “doc licence page-number glitch”. I think this is behaving as expected. The page numbers here are coming from the “LicenseStart” and “License” page styles. As the documentation explains, the page number is coming from that page style. To manually set the start number, you need to follow those instructions, which are (I quote):

1. Click into the first paragraph [sic - I clicked in the Heading for p. 145, and in the first para of p. 146] of your document/section.
2. Choose Format - Paragraph - Text flow.
3. In the Breaks area, enable Insert. Enable With Page Style just to be able to set the new Page number. Click OK.

This needs to be done with both styles.

To get “normal” 0-9 digits instead of lower-case roman, modify the “LicenseStart” and “License” page styles: Page tab - Layout settings - Page numbers and choose the desired number format. It seems to have worked for me:

[ajlittoz]

Once again, apologies for too short (or lacking) description.The glitch is not in roman numbering (this is intended for this relatively independent part) but in the wrong sequence: LicenceStart page is numbered i as intended but next Licence page is i instead of ii. Licence is Next style for LicenceStart and is thus automatically invoked on “natural” page break. No need to fiddle with paragraph breaks which would disrupt text flow. I’ve checked paragraph and page styles in search of “forced” …

[ajlittoz]

(continued) breaks. There are none apart from the one in GNU FDL Title to start licence and switch to LicenceStart page style.

No matter what I do (insertion or deletion, even huge pagefuls), the page number sequence remains i, i, ii, … The scheme is the same as in the ToC (ContentsStart/Contents) where the sequence is correct or in indexes (not used here IndexStart/Index). To some extent, it is also the same as Chapter/Start/Chapter though page number is not reset.

[ajlittoz]

Despite my long experience (expertise?) with styles, I surely committed a mistake but I’ve looked for it so long that i’m now unable to see an eventual elementary error.

If I change page style break to ChapterStart in GNU FDL Title, numbering is monotonously increasing. When I change back to LicenceStart, I get two pages numbered i. The problem is then either with paragraph style GNU FDL Title or with page style LicenceStart.

[ajlittoz]

Oddly enough, if I break to page style Contents Start, I also get i,i ii, iii, … whereas the sequence is correct in the ToC.

[dajare]

Right, in that case I can confirm the “glitch”: I get two p. is in the first two pages of the license, too. It seems counter-intuitive to me to set page numbering with paragraphs … but I don’t know why the page sequence should restart with “License” when “LicenseStart” specifies it as the follow-on. But I have much to learn here! Hope this has helped in some way. And maybe seeing how I tracked with the issue (or didn’t!) will encourage some other attempts/responses.

[ajlittoz]

@dajare: thanks for your help and patience. I’ll open another question dedicated to this sequencing problem with better explanation and much shorter attached file. I still experience bad “re-flow” but I’ll wait till 6.0+ surfaces in my distro to see if it persists.