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).
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.
Created attachment 193838 [details] attachment 193837 [details] - exported to PDF Export to PDF - note green page border on first, otherwise blank page.
I saw this with: Version: 24.2.0.2 (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: 24.8.0.0.alpha0+ (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.
Reproduced in: Version: 24.8.0.0.alpha1+ (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 6.0.0.3, but not in LO 5.0.0.5 -> regression.
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? Thanks 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 https://git.libreoffice.org/core/+/d6913850585eae90ea9179129fe7b60a2a4305ad tdf#93009 SwViewShell: fix printing of comments on the margin
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.