<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - [META] Additional blank pages on file-open" href="https://bugs.documentfoundation.org/show_bug.cgi?id=118920#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - [META] Additional blank pages on file-open" href="https://bugs.documentfoundation.org/show_bug.cgi?id=118920">bug 118920</a> from <a class="email" href="mailto:telesto@surfxs.nl" title="Telesto <telesto@surfxs.nl>"> Telesto</a> <pre><a class="bz_bug_link bz_status_NEW " title="NEW - Report builder generates empty pages" href="show_bug.cgi?id=100477#c23">Bug 100477 comment 23</a> 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 <a href="show_bug.cgi?id=118920#c3">comment 3</a> 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 <a class="bz_bug_link bz_status_NEW " title="NEW - 6-page DOCX shows 10 pages in Writer" href="show_bug.cgi?id=116872">bug 116872</a> 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>