Bug Hunting Session
Bug 39068 - PRINTING only first area with color formatted cells (background, border), same with PDFEXPORT
Summary: PRINTING only first area with color formatted cells (background, border), sam...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86 (IA32) Windows (All)
: medium minor
Assignee: Not Assigned
URL: http://wiki.documentfoundation.org/Ca...
Whiteboard:
Keywords: filter:pdf
: 98373 105552 (view as bug list)
Depends on:
Blocks: PDF-Export Print-Preview
  Show dependency treegraph
 
Reported: 2011-07-08 05:17 UTC by Dries Feys
Modified: 2019-03-20 03:50 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Test kit, see Comment 1 (45.05 KB, application/x-zip-compressed)
2011-07-08 06:09 UTC, Rainer Bielefeld Retired
Details
Examples of wrong print range detection (11.87 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-07-08 13:17 UTC, Regina Henschel
Details
file exemple of the bug (55.29 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-08-14 21:05 UTC, jean louis abegg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dries Feys 2011-07-08 05:17:54 UTC
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.
Comment 1 Rainer Bielefeld Retired 2011-07-08 06:08:07 UTC
[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.
Comment 2 Rainer Bielefeld Retired 2011-07-08 06:09:12 UTC
Created attachment 48893 [details]
Test kit, see Comment 1
Comment 3 Rainer Bielefeld Retired 2011-07-08 06:12:52 UTC
Forgot to mention: same behavior with 3.1.1 (only background tested).
Comment 4 Regina Henschel 2011-07-08 08:29:34 UTC
There is the setting "Suppress output of empty pages" in Tools > Options > Calc > Print. Do you uncheck it?
Comment 5 Kohei Yoshida 2011-07-08 08:34:45 UTC
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.
Comment 6 Rainer Bielefeld Retired 2011-07-08 10:34:47 UTC
@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.
Comment 7 Kohei Yoshida 2011-07-08 12:48:06 UTC
(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.
Comment 8 Kohei Yoshida 2011-07-08 13:01:45 UTC
Ok.  Now I got it.  I think Regina's comment confused me a bit.  Let me try to understand this a bit better.
Comment 9 Kohei Yoshida 2011-07-08 13:14:15 UTC
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.
Comment 10 Regina Henschel 2011-07-08 13:17:36 UTC
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.
Comment 11 Kohei Yoshida 2011-07-08 13:58:41 UTC
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.
Comment 12 Kohei Yoshida 2011-07-08 14:18:43 UTC
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.
Comment 13 Kohei Yoshida 2011-07-08 14:33:34 UTC
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.
Comment 14 Christoph 2011-07-09 06:29:07 UTC
(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.
Comment 15 Rainer Bielefeld Retired 2011-07-09 08:17:20 UTC
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?
Comment 16 Rainer Bielefeld Retired 2011-07-09 09:50:34 UTC
@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.
Comment 17 Kohei Yoshida 2011-07-09 10:43:07 UTC
Sorry, but I thought I already said that specification was an overkill for this!?  Why did you start it?
Comment 18 Phil Nichols 2011-12-11 09:56:51 UTC
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.
Comment 19 Björn Michaelsen 2011-12-23 13:23:02 UTC
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.
Comment 20 jean louis abegg 2014-08-14 21:05:12 UTC
Created attachment 104638 [details]
file exemple of the bug
Comment 21 jean louis abegg 2014-08-14 21:08:10 UTC
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....
Comment 22 QA Administrators 2015-09-04 02:47:40 UTC Comment hidden (obsolete)
Comment 23 Dries Feys 2015-09-04 07:25:03 UTC
Bug still present in Version: 5.0.1.2 

Initial found in 3.4, so probably an inheritence from OOo.
Comment 24 raal 2016-03-03 14:08:19 UTC
*** Bug 98373 has been marked as a duplicate of this bug. ***
Comment 25 Thomas Lendo 2016-12-27 07:38:32 UTC
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.
Comment 26 QA Administrators 2017-12-28 03:29:14 UTC Comment hidden (obsolete)
Comment 27 Thomas Lendo 2017-12-30 20:13:05 UTC
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.
Comment 28 Thomas Lendo 2018-03-19 19:14:47 UTC
*** Bug 105552 has been marked as a duplicate of this bug. ***
Comment 29 QA Administrators 2019-03-20 03:50:04 UTC
** 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