Bug 35449 - Paragraph properties of directly formatted text cause wrong reflow in large TABLES at "Print Layout"
Summary: Paragraph properties of directly formatted text cause wrong reflow in large T...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
: 126797 (view as bug list)
Depends on:
Blocks: Print-Preview
  Show dependency treegraph
Reported: 2011-03-19 09:23 UTC by nochschneller
Modified: 2019-12-09 18:07 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

1 table with just 1 line, 2 columns over many pages (28.49 KB, application/vnd.oasis.opendocument.text)
2011-03-19 09:23 UTC, nochschneller

Note You need to log in before you can comment on or make changes to this bug.
Description nochschneller 2011-03-19 09:23:16 UTC
Created attachment 44617 [details]
1 table with just 1 line, 2 columns over many pages

Hello, first I know that tables are not thought to be used in writer this way. But it's possible to do so and also hints at the internet recommend to use large tables to get independent columns for your document.

The attachment contains a file consisting one table with just one line and two columns. This table goes over many pages and footnotes are set. Since this table got longer and longer problems appeared at page break. The Document is fine at "Web Layout", but gets problems at "Print Layout".

At "Print Layout" it seems that text is cut of at end of random pages, also the number of Page Count is less than it should be. Pressing Ctrl + A you see that the text get marked and the marking runs out of page. This also causes high CPU-usage, and even can freezes the window.
Switching to "Web Layout" brings the whole written text back and everything works fine.

If the problem not totally accrues after opening the document, it will accrue after switching from "Web Layout" to "Print Layout" (watch Page Count!).

This behaviour was tested on Windows XP and Ubuntu-Linux (10.04 32bit and 10.10 64bit),with LibreOffice 3.3.1 and OpenOffice 3.2.1 as well.

My opinion:
This problem causes big confusion by users, even because it appears different at PCs with more or less power. 
If it should be impossible to implement a good working "Page Layout" with large tables, there might be at least a warning that tells the user that there will be problems. It could hint him to "Web Layout" or to different possibility’s like using boxes or marginalia, if this is adequate to his goal.

I hope you see what I mean, if there are any questions I'm willing to help.
Comment 1 Björn Michaelsen 2011-12-23 11:43:32 UTC Comment hidden (obsolete)
Comment 2 nochschneller 2012-01-17 05:48:17 UTC
This Bus still exists. You have to download the example-file, not only open as read-only.
Switching to "Web Layout" and back to "Print Layout" will afford the bug clearly.
Comment 3 sasha.libreoffice 2012-01-20 08:52:27 UTC
@ nochschneller@onlinehome.de
Version is where bug first time found, not current version of LibO

reproduced in LibO 3.5.0 beta 3 on Fedora 64 bit and Windows XP 32 bit
Steps to reproduce:
1. Start attachment
after file loaded we see that it takes 17 pages and on most pages table take only half page.
2. place cursor somewhere on second page.
table becomes on whole page and document takes 12 pages
Comment 4 Alec Kojaev 2012-08-05 13:53:53 UTC Comment hidden (obsolete)
Comment 5 A (Andy) 2013-04-30 21:20:47 UTC
for me not reproducible with LO (Win7 Home, 64bit)

Does this issue still persist for you with the latest release of LO?
Comment 6 Alec Kojaev 2013-04-30 21:28:36 UTC
Still reproducible with the test document attached to this bug on LO build 400m0 (Ubuntu 12.10, 32-bit).
Comment 7 A (Andy) 2013-04-30 22:15:07 UTC Comment hidden (obsolete)
Comment 8 Urmas 2013-05-01 02:01:04 UTC
Yes, it is still an issue in 4.0.3/Windows.
Comment 9 sasha.libreoffice 2013-05-02 08:21:10 UTC
More detailed description of bug (Fedora 64bit):

Initially document contains 10 pages. Second page ends with line:
Nun tritt folgendes Problem1 auf: Wird das Dokument gespeichert
Before clicking on it, let see on page 9. When I palace text cursor on last line in table and press down-arrow on keyboard, cursor moves incorrectly (part of text is hidden outside of cell and cursor moves on this hidden text outside of table and even outside of page).
After clicking on second page document size becomes 12 pages. Problem with last page disappears

Version and Version
All the same, but clicking on second page not repairs text. Document remains 10 pages size ans problem with last page present.
Comment 10 QA Administrators 2016-01-17 20:02:13 UTC Comment hidden (obsolete)
Comment 11 Alec Kojaev 2016-01-18 18:58:31 UTC
The bug still persists in LibreOffice version build 1:5.0.4~rc2-0ubuntu1~trusty1 on Ubuntu 14.04 x86_64.

Behavior as observed right now for example document attached to the bug:

1. When opened, document contains 17 pages. In the end of page 2 the first column ends with words "Wird das Dokument gespeichert". Visual inspection confirms that on many pages (in fact, on almost all pages) the text fills less than 1/2 of available vertical space.

2. Adding a paragraph end after the quoted words _decreases_ number of pages to 12. All pages (except the last one) are now filled to the end of available vertical space.

3. Removing the paragraph end inserted on step 2 leaves the number of pages at 12 and all pages except the last one filled.

Expected behavior:

- The document should have been 12 pages from the start.
Comment 12 Timur 2016-01-19 18:04:41 UTC
We don't know how the document was created. Looks like pasted from web.
One-line two-column large table is different, this is not it.
I think this bug should remain open only if recreated from scratch.

Workaround: we get 12 pages with Row Height-Fit to size or simple click on Adjust table row on a row boundary (page 2).
Comment 13 Alec Kojaev 2016-01-19 18:20:46 UTC
@Timur: And in what way is the process by which the document was created is relevant? I have a 200-page document, created in 2010 and still modified from time to time, where this bug strikes all the time, should I reenter it from scratch for LibreOfiice to display it as expected?

Of course, there is a workaround. Any modification that changes table height fixes it. The problem is, this should be done to every large table in the document every time it is opened.
Comment 14 QA Administrators 2017-03-06 13:50:54 UTC Comment hidden (obsolete)
Comment 15 Timur 2017-03-06 16:44:44 UTC
Knowing how the document is created is important for few things, to know whether it's reproducible, or if the fault is on conversion, or on old version etc. 
But here, even if we save this ODT with current master 5.4+, on reopen we get similar look, rows are decreased.
Comment 16 QA Administrators 2018-11-16 03:42:27 UTC Comment hidden (obsolete)
Comment 17 Timur 2018-11-16 08:38:13 UTC
Unlike before (10 or 17 pages), document in 6.2+ in Windows has 12 pages. The number of pages depends on the right column lines, seen with Toggle Formatting Marks.
Switching Web-Normal layout, number looks the same 12 but layout changes, page 2 is empty (before "Jedoch kann das Problem").
I think the cause is direct formatting of table text. So we may keep this one open. Although I'm not an optimist to have a dev working on this bug. 
Bug 86909 is similar but not the same, it has settings.
Comment 18 Timur 2019-12-09 18:04:28 UTC
*** Bug 126797 has been marked as a duplicate of this bug. ***
Comment 19 Timur 2019-12-09 18:07:17 UTC
Another example Attachment 152466 [details] from bug 126797.
It shows from 4 to 7 to 11 to 31 to whatever pages in different Lo.
If table text selected and cleared direct formatting, then 65 pages.