Bug 118920 (Additional-Blank-Pages) - [META] Additional blank pages
Summary: [META] Additional blank pages
Status: NEW
Alias: Additional-Blank-Pages
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 86126 95595 98698 132222 132231 132240 132413 134197 135025 135168 100477 113326 116479 116872 117538 133076 133975 133979 134723
Blocks: Page Page-View
  Show dependency treegraph
 
Reported: 2018-07-24 18:33 UTC by Telesto
Modified: 2020-09-18 17:42 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-07-24 18:33:08 UTC
Description:
 

Actual Results:
 

Expected Results:
 


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Telesto 2018-07-24 18:37:04 UTC
Bug 100477 comment 23

Jan-Marek Glogowski 2018-07-03 14:39:27 UTC
This is quite probably the same bug as 113326 and 116872.

And this bug is actually old. It was confirmed against 5.0.0.2 in comment 3 and never fixed, just look in the history and read the comments. BTW - 5.0 got the first scheduler patches, long before I tried to fix stuff.

Now what is actually happening in all cases: there are "really empty" pages at the end of the document due to whatever reason.

If you open the RTF document from 113326 with LO 5.4 and look at the page count in the bottom-left area of the writer status bar, you can see, that the initial document also has 6 pages. But these get reduced to 4, because the last two pages are "really empty". At least I can see this, when opening the document in a remote LO via SSH X forwarding.
Reducing always happens, if LO decides it needs to do some layouting, so it happens for the bug 116872 document, if you scroll with the keyboard.

"Really empty" means you can't click into these pages via mouse or scroll to them via keyboard, which is an invalid document state AFAIK. So just scroll to these pages via mouse and try to put the cursor in the page. Really the page, not the header or footer!

All of my (bi)bisected patches increased the performance of LO job processing.
My guess is, something schedules this cleanup job, but this depends on some layouting, which is not finished, when the cleanup job is run.

Someone want to debug writer layouting code?