Summary: | Inserted blank page has page border of subsequent (non-blank, styled) page | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Eyal Rozenberg <eyalroz1> |
Component: | Printing and PDF export | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | normal | CC: | raal, stephane.guillou, vmiklos |
Priority: | medium | Keywords: | bibisected, bisected, implementationError |
Version: | 5.3.0.3 release | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=160686 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 103378, 108576, 118920 | ||
Attachments: |
Document for which exporting triggers the bug
attachment 193837 - exported to PDF |
Description
Eyal Rozenberg
2024-04-24 13:47:27 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.
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. |