Created attachment 44751 [details] Example for incorrect pring rage detection in calc In LibreOffice calc, on default formatting, in my example I have 10 columns data in 20 rows, this document printed on 2 pages. When I select the last 5 columns and in the Format Cells dialog box, Cell Protection I tick Hide when printing, normally my data is fit in 1 page, but the libreoffice print one page with data and one blank page. Is the same case, when is select only the non-empty cells and select Hide when printing, or select this option with full column selection.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I tested the problem again (windows 7, LO 3.5 beta2), and it still exists.
I test the problem in Ubuntu 11.10 x86, with LOdev 3.5.0 Beta2 and it still exists.
@Ákos thanks for the report. You write " normally my data is fit in 1 page, " Do you know in which version that was ?
( PS pls do not touch the version field. It helps finding the versions in which the issue was first found )
In the version field now I see 3.3.2 (it's not deletetd), and probably first time I test it in versions 3.3.1 and 3.3.2.
I test it on LibreOffice 4.0.0 beta1, and the problem still exists. But with print range definition, I can solv my problem.
I test it on LibreOffice 4.3.2-2, and the problem still exists.
also the same unexpected result in 4.4.0 alpha1
I test it on LibreOffice 5.0.0.0.beta1, 32 bit, and the problem still exists.
I test it on LibreOffice 5.2.1.2, 32 bit, windows 10 64 bit, and the problem still exists.
The bug still exist in: Version: 6.1.0.0.beta2 (x64) Build ID: 0f4d2060bc90b4008fbc8e6d9a49ec7eeea60b78 CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: hu-HU (hu_HU); Calc: group threaded
Created attachment 143842 [details] Anoher example for incorrect print rage detection I add Anoher example for incorrect print rage detection as simple ODS. Due to hidden H column with text in H60, print rage detection is incorrect. Same is valid for opening XLSX files.
*** Bug 104502 has been marked as a duplicate of this bug. ***
I can reproduce with the current daily master build, but I'm wondering if this really is a bug, given that hiding columns in the middle will still show blank space where the cells would have been. (Which would make sense in particular for when you are hiding just a few cells, not whole columns.) For example, hide columns B and C, and export as PDF. You will see the blank space between columns. So Page 2 remains in the PDF export because it would have had something if the cells weren't hidden. To me, this is not a bug report, but rather an enhancement request that is asking "update print ranges when cells are hidden for printing". For the attachment 44751 [details], that would be: - once the columns are hidden, the print ranges / page breaks display should update to only show one page (columns A to E), and the rest of the columns are greyed out as if they weren't part of the print range. But I'm not sure this is a desirable change?
(In reply to Timur from comment #13) > Created attachment 143842 [details] > Anoher example for incorrect print rage detection > > I add Anoher example for incorrect print rage detection as simple ODS. > Due to hidden H column with text in H60, print rage detection is incorrect. > Same is valid for opening XLSX files. Timur, the issue you described is different as it is about hiding whole columns and rows with the right-click context menu (hidden in LO and in print), not about hiding cells for printing (shown in LO, hidden in print). It is described in Bug 104502, which was fixed.