Bug 160809 - Inserted blank page has page border of subsequent (non-blank, styled) page
Summary: Inserted blank page has page border of subsequent (non-blank, styled) page
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, implementationError
Depends on:
Blocks: PDF-Export Writer-Styles-Page Additional-Blank-Pages
  Show dependency treegraph
Reported: 2024-04-24 13:47 UTC by Eyal Rozenberg
Modified: 2024-05-27 13:51 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Document for which exporting triggers the bug (63.78 KB, application/vnd.oasis.opendocument.text)
2024-04-24 13:49 UTC, Eyal Rozenberg
attachment 193837 - exported to PDF (21.69 KB, application/pdf)
2024-04-24 13:51 UTC, Eyal Rozenberg

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2024-04-24 13:47:27 UTC
Consider the soon-to-be-attached document. It has a single page, with the Left Page style. Never mind what you think of that style and its behavior - as things are defined right now, this page triggers the insertion of a blank page before it. You can see the blank page if you switch to Book View (e.g. via the bottom-of-window toolbar buttons).

Now, if I export the document to PDF, and enable "export automatically inserted blank pages" in the dialog, I get a two-page document beginning with... not quite a blank page, but rather a blank page plus a green page border, like the Left Page style has defined; other features of the Left Page style are not applied (which is intended behavior).
Comment 1 Eyal Rozenberg 2024-04-24 13:49:22 UTC
Created attachment 193837 [details]
Document for which exporting triggers the bug

Exporting this to PDF results in a PDF with the blank page having a green page order.
Comment 2 Eyal Rozenberg 2024-04-24 13:51:16 UTC
Created attachment 193838 [details]
attachment 193837 [details] - exported to PDF

Export to PDF - note green page border on first, otherwise blank page.
Comment 3 Eyal Rozenberg 2024-04-24 13:52:13 UTC
I saw this with:

Version: (X86_64) / LibreOffice Community
Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f
CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US

and also seeing this with:

Version: (X86_64) / LibreOffice Community
Build ID: ffccbf4762a9ae810bcdd21c41fccdd436e7bfc9
CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3
Locale: he-IL (en_IL); UI: en-US

But note that I don't get this with just _any_ PDF with Left Page style applied to the first page. Can't quite pin down what makes this one trigger the problem.
Comment 4 Stéphane Guillou (stragu) 2024-05-23 05:39:13 UTC
Reproduced in:

Version: (X86_64) / LibreOffice Community
Build ID: 101b08fe1ec77ffe8c1a9b2b8f9f20884269a1ed
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Interestingly, it only happens if exporting while on Single-page View or Multi-page View. If exporting while on Book View, the first page has no margin.

Also in, but not in LO -> regression.
Comment 5 raal 2024-05-23 14:29:50 UTC
This seems to have begun at the below commit in bibisect repository/OS bibisect-linux-64-5.2.
Adding Cc: to Miklos Vajna ; Could you possibly take a look at this one?
 ffc455187da1a8fdffac3733f347e8093f650a82 is the first bad commit
commit ffc455187da1a8fdffac3733f347e8093f650a82
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Fri Dec 8 02:27:38 2017 +0100

    source d6913850585eae90ea9179129fe7b60a2a4305ad

tdf#93009 SwViewShell: fix printing of comments on the margin
Comment 6 Miklos Vajna 2024-05-27 13:51:02 UTC
Yes, I can reproduce the bug. Here are the events I see:

- seems this was ~always like this
- 978033d5ed9f93f2d5d9a1ba44acf6b37bc13bfe (SwViewShell::DLPrePaint2: fix missing clipping for the non-buffered case, 2015-07-03) started to set a clip region that went too far, but as a side effect, this use-case started to work
- d6913850585eae90ea9179129fe7b60a2a4305ad (tdf#93009 SwViewShell: fix printing of comments on the margin, 2015-12-22) fixed the bad clip region, so comments printed on the margin were completely lost on printing

So in short, this never really worked, there was a window in time between 2015-07-03 and 2015-12-22 where this seemed to work, but only at the cost of losing comments on printing (in margin mode), which was quite bad.

The original double-buffer commit could be reverted in theory (at the end opengl and later skia went down a different route), but reverting the comment loss fix to get this bug working is not a great idea, I would say.

I agree that this is a bug and it's worth fixing, though. Adjusting keywords accordingly.