Created attachment 189070 [details] Example file Attached user made file contains two sheets and a macro used to set print properties (print range, print settings) and to print the whole spreadsheet. When the macro is run, the resulting print contains an empty page in place of the second sheet. 1. Open attached file 2. Press the Print button on the first sheet -> Second sheet is not printed, only an empty page. This is "fixed" if the Tools - Options - Calc - Print - Print only selected sheets is disabled. The problematic behavior seems to happen only with the macro, not from the Print dialog or from the CLI --convert-to pdf call. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e60ef8651cfb30335471d1622e58c13eebc7d58b CPU threads: 15; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded Seems to have started in 4.4. Before that the first sheet was exported. Bibisect range from windows-4.4 repo: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=e1386e32a85eb5c6b4294a8ca3e4461b92707fc3..e62764108a1832e746f68768c29eaa90606903a7 of which, this seems suspicious: https://cgit.freedesktop.org/libreoffice/core/commit/?id=0b793116deaf35ce67245c1106e5ed5a722c7560 author David Tardon <dtardon@redhat.com> 2014-06-19 16:57:03 +0200 committer David Tardon <dtardon@redhat.com> 2014-06-19 17:14:48 +0200 commit 0b793116deaf35ce67245c1106e5ed5a722c7560 (patch) rhbz#1111216 allow to export an empty sheet to PDF https://bugzilla.redhat.com/show_bug.cgi?id=1111216
Created attachment 189071 [details] First sheet printed to PDF I use the PDF24 virtual printer, and that shows 2 documents that it can save, for the two sheets. This is the first one, looks good.
Created attachment 189072 [details] Second sheet printed to PDF The second sheet results in an empty page. Before 4.4 the PDF24 did not show this document at all.
Tested with CUPS' print to pdf printer-driver-cups-pdf, set as default printer via File > Printer Settings...; which will output by default in ~/PDF. Reproduced that I'm getting two separate files without the content's of the second sheet: one page of sheet 1's contents, one empty page. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: beaea2e992912b4747d790070b26371f557b1f57 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded In OOo 3.3, I also get just the first sheet, but no emtpy second document. So is this really a regression? 0b793116deaf35ce67245c1106e5ed5a722c7560 made it possible to export the second empty sheet, but it must have been considered to be empty before that. (In reply to Gabor Kelemen (allotropia) from comment #0) > The problematic behavior seems to happen only with the macro, not from the > Print dialog or from the CLI --convert-to pdf call. Alternatively, you can select both sheet tabs with Shift + Click, and both pages will have content. In a way, it's consistent with the setting... Are macros supposed to ignore in-app active selection? Or should this be fixed by moving the active selection in the macro instead? I guess oSheet.createCursorByRange() is already doing that in the macro...
Dear Gabor Kelemen (allotropia), This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Gabor Kelemen (allotropia), Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp