Description: Let's assumed in a new spreadsheet that A1 has a filled colour of yellow. Let also assumed that B1:D1 is filled with a grey colour. Now let's format the cells to a 45-degree angle. 1) If you do a “print preview” of this sheet, the filled colour of B1:D1 inherit the filled colour of A1 (the grey background is lost) 2) If you export the same file to a PDF file, the filled colour is preserved for all cells (A1:D1) 3) If the cells are not formatted to a 45-degree angle, the filled colour is also all preserve (A1:D1) See file attached Steps to Reproduce: Let's assumed in a new spreadsheet that A1 has a filled colour of yellow. Let also assumed that B1:D1 is filled with a grey colour. Now let's format the cells to a 45-degree angle. 1) If you do a “print preview” of this sheet, the filled colour of B1:D1 inherit the filled colour of A1 (the grey background is lost) 2) If you export the same file to a PDF file, the filled colour is preserved for all cells (A1:D1) 3) If the cells are not formatted to a 45-degree angle, the filled colour is also all preserve (A1:D1) Actual Results: Filled colour of cell B1:D1 get replaced by the filled colour of the first cell (A1) after rotating text to a 45-degree angle Expected Results: While printing, all cells should keep their actual filled colour after rotating text to a 45-degree angle. Reproducible: Always User Profile Reset: Yes Additional Info: I will upload a test file that exhibit this bug.
Created attachment 186169 [details] Cal file exhibiting the bug
Created attachment 186170 [details] Exported PDF Test file that does not exhibit the bug
I also tried this after resetting my profile and starting Libreoffice in safe mode. I know that this bug was also present in version 7.4.x Thanks for looking into this. JF
Reproduced: - Print Preview is wrong Whereas: - Preview inside Print dialog is correct - Print to file is correct - PDF export is correct Doesn't this only affect Print Preview, JF? Or did you see it when actually printing on paper? Tested on Linux: Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0d18262789fbe95eafe32bd775a9827ed99685ef CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded With same results on macOS. Back in 6.0, Print Preview would display the unrotated original colours, but no text. Version: 6.0.0.3 Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk2; Locale: en-AU (en_AU.UTF-8); Calc: group In OOo 3.3, the print preview was correct. So there's a regression (or several) somewhere along the way.
Created attachment 186189 [details] Start Center preview of example document in 7.6 Start Center document preview also does fun things with it. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0d18262789fbe95eafe32bd775a9827ed99685ef CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Maybe in relation with tdf#99391 EDITING Rotating text in a cell rotates also cell background
Bonjour Stéphane. To answer your question : "Doesn't this only affect Print Preview, JF? Or did you see it when actually printing on paper?" It affects both the print preview and what is printed (on a colour ink printer) on paper. IMHO, this is a different bug than tdf#99391. In my case, the background colour is not lost but rather overwritten by inheriting the filled colour from the first cell. Thanks again for looking into this. JF
(In reply to JF from comment #7) > It affects both the print preview and what is printed (on a colour ink > printer) on paper. I just tested printing on an Epson WF 7720 and the result is correct. So in my tests (LO 7.5.1.2 on Linux): Reproduced: - Print Preview is wrong - Start Center thumbnail is wrong Whereas: - Preview inside Print dialog is correct - Print to file is correct - PDF export is correct - Print on paper is correct
(In reply to Stéphane Guillou (stragu) from comment #4) > > Back in 6.0, Print Preview would display the unrotated original colours, but > no text. > This seems to have begun at the below commit in bibisect repository/OS bibisect-linux-64-6.1. Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one? Thanks 11aa51aeea4b95903fc44abe89214a709a566cdf is the first bad commit commit 11aa51aeea4b95903fc44abe89214a709a566cdf Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Jan 29 10:42:08 2018 +0100 source 753b35b27e3657db39f5d398a733879ef23b7c51 source 753b35b27e3657db39f5d398a733879ef23b7c51 source c4e6f6cfa1b189159245cb544959f800d126a78c source 9a03edf7f6ed1ae933ce73f26599bc4251662e9d source 07609f3ae2890ace29c249fac2fb60b0f0332af6 source c5a3cae89660164f68565ee391ed8cf931f1d4da source b28360c66bc856176ff84bc6c2516f710a7196ab source 8ed06d685bc99c61a36b8f1472883bf85e4b791a source 71053a36f3f48904c254a1d277f42d6dcdc29b04
commit 11aa51aeea4b95903fc44abe89214a709a566cdf does not exist, so you talk about 753b35b27e3657db39f5d398a733879ef23b7c51 ? That one only change the cell *borders*, so I doubt it may influence the fillings at all - but you are never safe of surprises :-/ Pls ACK if 753b35b27e3657db39f5d398a733879ef23b7c51 the one we talk about!
(In reply to Armin Le Grand from comment #10) > commit 11aa51aeea4b95903fc44abe89214a709a566cdf does not exist, so you talk > about 753b35b27e3657db39f5d398a733879ef23b7c51 ? > That one only change the cell *borders*, so I doubt it may influence the > fillings at all - but you are never safe of surprises :-/ > Pls ACK if 753b35b27e3657db39f5d398a733879ef23b7c51 the one we talk about! That was the bibisect commit, rather than the source one. raal's bibisect ended on a range, so we don't know for sure which of the commits started it, but as they are all by you, you are copied in: https://git.libreoffice.org/core/+log/e3e2f6911d6231c706ce8c77e5cd6733335d6342..753b35b27e3657db39f5d398a733879ef23b7c51
Un-Ccing developer for the moment, old regression & very high workload.