Is it expected behaviour that a page area with coloured, though empty cells isn't printed? We have an issue with an user who created colour-coded spreadsheet, but when he wants to print it, only the headers got printed. When printing from ms Excel, everything is fine. When I enter dummy characters in the ignored pages, everything is printed as well. Easy to reproduce when creating a large spreadsheet with many colours and only text at the top.
[Reproducible] with "LibreOffice 3.4.1RC1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:103)]". Only first area with cell background or cell border will be printed or exported to PDF. Sample documents in attached test kit have been created by simply formatting empty cells with background or cell border. "sample2.ps" is a print with Dell PS Printer, PDFs from native LibO PDF export. @Kohei: Please feel free to reassign if it’s not your area.
Created attachment 48893 [details] Test kit, see Comment 1
Forgot to mention: same behavior with 3.1.1 (only background tested).
There is the setting "Suppress output of empty pages" in Tools > Options > Calc > Print. Do you uncheck it?
Well, the current logic is that, cell colors are not considered data, while cell borders are. So, if you have a sheet that only have cell colors but no other data, that sheet is considered empty. But I don't have a strong opinion on this, and would be willing to treat cell colors as data, in fact, I prefer to do that just to be consistent with cell borders. Other than that, Regina's workaround should work for now. I'll work on this for 3.5 & may backport to 3.4.x if it makes sense.
@Regina: No suppression of empty pages selected. @Kohei: It seems your comment does not match with my observations, please see a) my observations are equal for borders and background b) A completely really empty sheet will not print at all, but if backgrounds (or borders) have been defined only the first formatted area will be printed (and visible in preview), the following one will not be printed. I can live with printed and not printing empty formatted cells, but I can't find any reason for printing first (green) area and suppressing the second one. I would have expected that all or nothing will be printed Please do not modify any intended behavior before that has been discussed. I prefer printing pages with (also little) content with all borders/ background, but suppressing print of pages without "real" cell contents. But is that really common sense? I will soon start a Specification together with Design and UX, we will see what arguments we get.
(In reply to comment #6) > @Kohei: > It seems your comment does not match with my observations, please see > a) my observations are equal for borders and background > b) A completely really empty sheet will not print at all, but if backgrounds > (or borders) have been defined only the first formatted area will be > printed (and visible in preview), the following one will not be printed. > I can live with printed and not printing empty formatted cells, but I > can't find any reason for printing first (green) area and suppressing > the second one. I would have expected that all or nothing will be printed What do you mean by "the first formatted area"? > I will soon start a Specification together with Design and UX, we will see what > arguments we get. No way. Why do you think a specification is necessary for this tiny bug report!? Let's not jump the gun here. Over-using of a spec would only increase the work amount for no gain. Apparently we have a mis-communication here and I don't fully understand the nature of the bug just yet. Let's take care of that first.
Ok. Now I got it. I think Regina's comment confused me a bit. Let me try to understand this a bit better.
Ok. I'm not entirely sure if Rainer's test document matches the original bug reported by Dries Feys. Dries, could you attach a sample document to demonstrate your problem here? I prefer an Excel document so that I can compare what Excel and Calc do differently in order to understand your point better. Also, this is an issue with printing, I presume? I don't want to confuse that with PDF since exporting to PDF is entirely another beast and has its own code path and quirks. So I need to make sure this is purely a printing issue.
Created attachment 48904 [details] Examples of wrong print range detection If you change to View>Prage Break Preview you can see, that the automatic print range detection has only detected the first style. Playing around with my attached document, you will find some curios detection problems: Set all borders to B85:D85 on sheet '84rows': 84 rows are detected, 85 rows not detected. Remove borders from D85:E85 on sheet 'contact': The detected area is reduced to column A:C. Remove borders from E85:G85 on sheet 'overlap': The detected range is reduced to column A:E. Therefore I see the problem not in printing empty cells. That is handled well with setting "Suppress output of empty pages". But the problem is the automatic print range detection on an empty sheet.
So, this is a combination of two separate issues. 1) Sheets with only cell colors are not printed unless the printing of empty sheets is enabled, either in the Calc Print option page or in the printing dialog. 2) Even with the printing of empty sheets is enabled, Calc's automatic range detection fails to detect correct printing ranges.
My preferred solutions to the two issues are 1) treat sheets with only cell colors as non-empty sheets just like we do with sheets with only borders. IMO this makes perfect sense. 2) this is a bug and let's fix it.
Since Rainer's concerned about my proposal 1), let me CC Christoph and see his take on this. @Christoph, what's your opinion on treating sheets with only cell colors as non-empty sheets? Does that have a usability implication? I personally don't, but you may see it differently.
(In reply to comment #12) > My preferred solutions to the two issues are > > 1) treat sheets with only cell colors as non-empty sheets just like we do with > sheets with only borders. IMO this makes perfect sense. I'm fine with that. Although we will (in any case) run into issues for certain users - e.g. people who remove "hard formatted cells" (e.g. red background) via re-coloring (e.g. white background). That would add "invisible" data to the pages. Please keep the current default for "Include output of empty pages". > 2) this is a bug and let's fix it. Okay. @ Rainer: As far as I understand the issues, I think Kohei's proposal is sufficient. The main issue is - from an UX perspective - what is "data" (a.k.a. not empty)) and what is the opposite. Note: I thought there is a spec for 2.3 were they changed the behavior for Calc, but it doesn't contain helpful information for our case.
All discussions have shown lots of problems and obscurities what have to be cleared before a fix for this bug can be done. for such clearings I started a specification. Here the question is: If a page from a sheet will be printed, is it expected that some cells with only formatting contents will be printed, others will not? Following definition from Help (see specification), nothing of a sheet with only borders and backgrounds should be printed. I believe that this is quite nearby Reginas "Problems with automatic print range detection" definition. Further Information / Questions ------------------------------- I can't see any differences between treatment of cell borders and and treatment of cell backgrond, so I do not understand the differences mentioned in Comment 5 and others. Additionally I am talking about printing multiple pages from 1 sheet with various cells with or without "real contents" and only "formatting contents". How empty sheets (only containing formatting) should be printed of course is a related question, but that can not be discussed before we have an agreement concerning the single sheet problem. For all that see specification draft from a.m. URL! So here please only discuss problems concerning single sheet spreadsheets. I saw several comments like "I can live with" and "Seems perfect", what all is no argument without a "real life user scenario". @Kohei: In Comment 11 you mention an option "printing of empty sheets". I can't find that, only options "print empty Pages" (or suppress...), what's something completely different. Can me help to find that option?
@Regina: I added you in Spec with role "UX" @David: I added you in Spec with role "Cocumentation" @Christoph: I added you in Spec with role "Design" @All: Please feel free to remove if you do not want to be involved.
Sorry, but I thought I already said that specification was an overkill for this!? Why did you start it?
Related is this: Given cells with background color, but the cells are formatted with protection to "hide when printing", the text of the cell is not printed but the background color is printed. This is true regardless of the setting of the "tools\options\calc\print\suppress output of empty pages" item. I believe the background color of a cell should be a property of the cell and it should be printed or not printed when the cell is printed or not printed. The cell may be printed or not, but it is not correct to print some parts of the cell and not others. I believe the CELL should have properties of: content (text, for example) background color border etc. If a CELL is protected from printing with "hide when printing", no property of that cell should be printed - including the background color. If a CELL has background color but no text content and no border, then the cell is not null and it should be printed unless the "hide when printing" property is set. If all of the cells on a page have no content, no background color and no border, or were marked as "hide when printing" then that page would be elgible to be print-suppressed depending up the "suppress output of empty pages" setting. I believe thinking about cell(s) this way would clear up all of these inconsistencies when printing.
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Created attachment 104638 [details] file exemple of the bug
Comment on attachment 104638 [details] file exemple of the bug simple 120x260 coloured cells + line borders ask for preview, print or export to pdf, you'll obtain an almost empty page....
** 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.0.0.5 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Bug still present in Version: 5.0.1.2 Initial found in 3.4, so probably an inheritence from OOo.
*** Bug 98373 has been marked as a duplicate of this bug. ***
Original OOo bug is https://bz.apache.org/ooo/show_bug.cgi?id=85076 (Calc won't print/preview documents containing only cell borders). Set version to "inherited from OOo" as mentioned in comment #22.
** 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
Still reproducible in Version: 6.1.0.0.alpha0+ Build-ID: 38f5e768b0f858f8f990a8f297396821c75d45dc CPU-Threads: 4; BS: Linux 4.10; UI-Render: Standard; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-29_01:09:09 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded (In reply to Regina Henschel from comment #4) > There is the setting "Suppress output of empty pages" in Tools > Options > > Calc > Print. Do you uncheck it? This option seems to have no effect in attachment 104638 [details]. Print preview looks identical with and without this option activated. (In reply to Kohei Yoshida from comment #11) > So, this is a combination of two separate issues. > > 1) Sheets with only cell colors are not printed unless the printing of empty > sheets is enabled, either in the Calc Print option page or in the printing > dialog. > > 2) Even with the printing of empty sheets is enabled, Calc's automatic range > detection fails to detect correct printing ranges. Both still true.
*** Bug 105552 has been marked as a duplicate of this bug. ***
Dear Dries Feys, 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 https://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
Dear Dries Feys, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug