Hi This Bug is in LO 4.4.5.2 and LO 5.0.0.5 under W7 64bit. Steps to reproduce: - Create a new Calc file - Mark Cell A1 to B10 and choose borders: all borders. - So, all marked cells are bordered -> Go to print preview -> looks ok. - Mark Cell A1 to B100 and choose borders : all borders. - So, all marked cells are bordered -> Go to print preview -> shows "no data" (German: "Keine Daten") Have a look at the screenshots for understanding. Cheers Ralf
Created attachment 117797 [details] Print preview OK
Created attachment 117798 [details] PRint preview wrong
Reproducible with Version: 5.1.0.0.alpha1+ Build ID: 6b7354ae66db40246a09e00aa876443057655a43 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-19_01:05:16 and LibreOffice 3.5.0 Build ID: d6cde02
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Still present in LO 5.1.5.2
Win10 1511 64bit, still the same behavior
And also the same with LO 5.2.1.2
The user has several options to get the wanted Printout: 1. Define a Print Range or 2. Place data in the last cell wanted (Space Character in B100). Empty cells are empty, even when they are formatted. What is the wanted behaviour for cases like this when no Print Range is defined? Image a Calc sheet were a complete column is formatted. Should all ~20.000 paper sheets be printed? As long as this target is not defined this bug is UNCONFIRMED.
Hi The wanted beahavior for this case should of course be: 2 or 3 pages with exact 2x100 bordered, empty cells. The same as in the Case with 2x10 bordered, empty cells. There is not "no Data", there is Data (bordered cells). I hobe this is clear enough? Cheers Ralf
Tried to reproduce: it seems that 85th row is problem.You can select all columns and exclude 85th row selecting it and set no border.No Data in Print Preview disappeared.Also, Preview is ok when any cell before 86th row is set bordered. Reproduced in 5.1.6.2 ,5.4.0.0.alpha0+
(In reply to Zineta from comment #10) > Tried to reproduce: it seems that 85th row is problem.You can select all > columns > and exclude 85th row selecting it and set no border.No Data in Print Preview > disappeared.Also, Preview is ok when any cell before 86th row is set > bordered. > Reproduced in 5.1.6.2 ,5.4.0.0.alpha0+ Confirmed. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 2fd88ab1cbb4690a770ca2ca5d66157ec4906a2e CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on January 12th 2016 Arch Linux 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
removing the borders from row 85 and then reinsert the borders give me a preview of two pages Version: 6.2.0.0.alpha0+ Build ID: e5c8f2ba40223b67c7205b6f06da3aa344ed0e97 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group threaded
I tested, reinserting the borders was not successful, behavior is the same in new daily Version: 6.2.0.0.alpha0+ (x64) Build ID: 7119184f4b5441600f7b3eae7ec6771c094bbb7f CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-07-23_05:38:07 Locale: bs-BA (bs_BA); Calc: group threaded Set border from A1 to F100 Print Preview shows only columns where 85th cell is with no border. But when only A85 with no border and added G85 cell with border shows all columns.(moved to right: instead A85-F85 with border B85-G85 )
Dear ralf.krapf, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro 6.4+
In 7.2 it shows "No data" in Print Preview with any number of cells with borders but without data bug 142278 looks as dupe of this bug
Still present in LO 7.3.3.2
Repro Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: daf30c29be67b8b8fa361b0efd1a6cdbe087b6f8 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: CL threaded
Related source line in /sc/source/core/data/attarray.cxx: // size (rows) of a range of attributes after cell content where the search is stopped // (more than a default page size, 2*42 because it's as good as any number) const SCROW SC_VISATTR_STOP = 84; SCROW nAttrSize = mvData[nEndPos].nEndRow + 1 - nAttrStartRow; if ( nAttrSize >= SC_VISATTR_STOP ) break; // while, ignore this range and below
And dropping that is not a good idea, see https://gerrit.libreoffice.org/c/core/+/153256/comment/4c28a8d1_d10e4d88/
Reproduce this bug: Calc (LO 7.6): Show only 84 rows in the Print Preview Excel (Office 2019): Show all 100 rows tdf46738 test file: Calc (LO 7.6): Show only 7 rows, and 3 columns (adjusted to the last data cell) Excel (Office 2019): Show all rows and columns (regardless of the position of the last data cell) In my opinion, you should either display all rows in the Print Preview, as Excel does (unless, of course, it applies to all rows), or only display the last row and column of data (then, for example, you can print the required part of the empty cells by writing a space in the last cell).
Czeber László Ádám committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/87ca7d2f146be2c309fc6fd36f9154f3ea4e4bd8 tdf#93315 sc: Only 84 empty row show in the Print Preview It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.