When I open an Excel spreadsheet I created in Calc that has a chart with a transparent background in Calc, the background appears blue and transparent. If I open the same spreadsheet in MS Excel, the background is transparent, as desired. This problem is related to bug #64224, which has been fixed and IS working correctly. Here are the steps to recreate the problem: 1) Create a spreadsheet in Calc 2) Add a bar chart with a transparent background 3) Save the spreadsheet as a MS Excel 2003 file 4) Close the spreadsheet in Calc 5) Open the newly created spreadsheet in Calc 6) Verify the transparent background is blue I first encountered this in Calc 4.2.3.3 on Ubuntu 14.04 Linux (64-bit) and then I was able to recreate it in Calc 4.2.4.2 on Windows XP SP3. Attached are screen shots and some test files.
Created attachment 98860 [details] Original ODS spreadsheet used to generate other test case files.
Created attachment 98861 [details] Original ODS spreadsheet saved as MS Excel 2003 file.
Created attachment 98862 [details] Original ODS spreadsheet saved as MS Excel 2007/2010 XML file.
Created attachment 98863 [details] Screen shot of Calc 4.2.3.3 displaying original ODS spreadsheet.
Created attachment 98864 [details] Screen shot of Calc 4.2.3.3 displaying MS Excel 2003 spreadsheet.
I almost forgot to mention, Calc 4.2.3.3 and Calc 4.2.4.2 load the MS Excel 2007/2010 spreadsheet just fine and the transparent background is preserved.
Hi, confirmed with 4.1.6.1, 4.2.4.2 and 4.3.0. Didn't find a duplicate. Change version, set as New - Sophie
With a current 4.4.0.0.alpha0+ build, the MS Excel 2003 file is still not opening properly in Calc or MS OneDrive. I think this might be a export issue. The .XLSX transitional OOXML file is opening perfectly.
** 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
Ok, I conducted some tests using LibreOffice Calc 4.4.2.2 on Ubuntu 15.04 Linux and Calc 4.4.5.2 on Windows XP. I'm not able to run LibreOffice 5 yet, so I can't test there yet. With that being stated, I found the following: *) When I save the original ODS spreadsheet as an Excel (XLS) file in Calc 4.4.2.2 on Linux, the background color of the chart changed from blue to white when I open the Excel version in Calc. The same happens when I open this version in Calc 4.4.5.2 on Windows XP. When I open this version in MS Excel 2007, the chart appears with a transparent background. *) When I save the original ODS spreadsheet as an Excel (XLS) file in Calc 4.4.5.2 on Windows XP, the background color of the chart was white when I open the Excel version in Calc. When I open the Excel version in MS Excel 2007, a security violation message appears. If I allow Excel to try to recover the data, the columns are shown but the chart is gone. I'll attach a screen shot of the security warning I get in MS Excel 2007. I'll try LibreOffice 5.0, when I can get access to it. Thanks!
Created attachment 118436 [details] Screen shot of MS Excel 2007 security violation message This message appears when I try to open the Excel (XLS) spreadsheet I saved in LibreOffice Calc 4.4.5.2 on Windows XP in MS Excel 2007.
Created attachment 118447 [details] Simple transparent chart created and saved in Excel 2013. Calc adds a blue background This is not an export issue. The importer is adding a blue background. If you take any spreadsheet with an opaque background, save it as XLS (in Calc or Excel). Then reopen it in Calc and Edit the chart -> "Format Chart Area" -> Area -> Fill -> None the result is a BLUE background. The XLS importer adds a blue background behind all XLS charts. To verify this, see the attached file. It a simple XLS chart with no background. Note how Calc adds a blue background. With regards to the original spreadsheet, attachment 98860 [details] , Calc is now changing the background to opaque white, hiding the underlying import bug. This file is also not a valid XLS file and cannot be opened in Excel. I opened Bug 93949 to track this regression.
I used mso-dumper to compare an XLS chart with a working solid background against the same chart with a transparent background. The solid uses: <a:solidFill><a:srgbClr.val="FFFF00"/></a:solidFill></a:spPr> While the transparent uses: <a:noFill/></a:spPr> The importer likely needs an equivalent to this: http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e2292b3cdd032edff21f0016b7f61e9bb420699
Created attachment 121514 [details] Simple transparent chart created and saved in Excel 2013. Calc adds a blue background Note the blue background is behind the "Chart Area". If you go to Edit (Chart) -> Format Chart Area -> Area The fill is correctly set to "none". However if you do not enter the Chart module(no Edit), and right click on chart Area -> Area The fill is incorrectly set to "Color:Tango Sky Blue".
The XLSX importer always sets the chart's frame area fill to: None The XLS importer always sets the chart's frame area fill to: Color:Tango Sky Blue This incorrect default is likely the source of the bug.
This bug is a regression that was never bibisected. Version 3.6.7.2 (Build ID: e183d5b) correctly opens attachment 118447 [details]
Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89) correctly imports the test case attachment 121514 [details]. The chart is render correctly and the OLE container's Area:Fill setting is None.
Version 4.0.6.2 (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24) : good Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155: bad
Armin, any idea what could be causing this? Could is be related to Issue 121334? http://cgit.freedesktop.org/libreoffice/core/commit/?id=7c486ba2574486f886612b8c4c130c55acd7d93e
Hi Luke, thanks for mentioning, I will check asap - which means it may take some days around new year's eve :-)
bibisected to the range 358b60b3b172968a7605b428af01df456d7669b2..bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0 http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=358b60b3b172968a7605b428af01df456d7669b2..bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0 so the mentioned commit is not to blame (although there is http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a29c5bedda700a86b46e3c3cd9c9e1ce1d4f278 that mentions no fill and no line objects that might be related). bibisected with the 42all repo (http://dev-downloads.libreoffice.org/bibisect/linux/bibisect-42all.tar.xz ¹): git bisect start # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00 # bad: [793dbf6f80f497dfe587d560d6257f42a24273f6] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d git bisect bad 793dbf6f80f497dfe587d560d6257f42a24273f6 # bad: [793dbf6f80f497dfe587d560d6257f42a24273f6] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d git bisect bad 793dbf6f80f497dfe587d560d6257f42a24273f6 # good: [8092559c5013969ebda017d79200463b9b975038] source-hash-fd84daf696a368c2c7561b5253b32a63ecdeca4a git bisect good 8092559c5013969ebda017d79200463b9b975038 # bad: [0270ef1b76a6de423b30f7927362cc01c1a0fc38] source-hash-b1f7dd66b898b03cb4bd8d434b6370310ea95946 git bisect bad 0270ef1b76a6de423b30f7927362cc01c1a0fc38 # good: [aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1] source-hash-358b60b3b172968a7605b428af01df456d7669b2 git bisect good aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1 # bad: [63ac4ab9665db60fac1e1813c9c80da52b2e87c6] source-hash-66e39940d763586060c4bcc8c3cd213495c40b79 git bisect bad 63ac4ab9665db60fac1e1813c9c80da52b2e87c6 # bad: [ec9e268ce152176463e07e09901e4a99d65d86ee] source-hash-1b14676b5f95dd51d6266a6ab7bd713a5ddcff2f git bisect bad ec9e268ce152176463e07e09901e4a99d65d86ee # bad: [92245e9ab5788297a91fd0d557529f07bbb1c5df] source-hash-a16a4006e40bdb2cb4671846295fe2bf5a856e68 git bisect bad 92245e9ab5788297a91fd0d557529f07bbb1c5df # bad: [496201d16aa967dcd3dd168068b22bbcb2c1463f] source-hash-e75ddb91c3d52ea9e6939325118cf906d971c41e git bisect bad 496201d16aa967dcd3dd168068b22bbcb2c1463f # bad: [d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5 git bisect bad d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2 # bad: [7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b] source-hash-bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0 git bisect bad 7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b # first bad commit: [7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b] source-hash-bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0 [1] some of the revisions need symlinks in ./opt/ure/lib ln -s libreg.so libreg.so.3 ln -s libjvmfwk.so libjvmfwk.so.3 ln -s libjvmaccess.so libjvmaccess.so.3 ln -s libstore.so libstore.so.3
Armin, If I'm following the code correctly, it looks like you moved the XFILL_NONE property from graphicproperties.cxx to svdoole2.cxx. I ran the debugger on the test case here and at i119287. The if condition at: http://opengrok.libreoffice.org/xref/core/svx/source/svdraw/svdoole2.cxx#1481 is true for OLE equations but false for OLE charts. Do you have any idea why? Could this be the source of the problem?
see also https://bz.apache.org/ooo/show_bug.cgi?id=125222 (cf https://bz.apache.org/ooo/show_bug.cgi?id=119287#c12 "I used the wrong Issue ID in the commit, sorry.") That one is supposed to have the fix for the regression (blue background instead of no background) identified as caused by https://svn.apache.org/viewvc?view=revision&revision=1344740 ) - unfortunately it is already applied for LO http://cgit.freedesktop.org/libreoffice/core/commit/?id=d07778f62ed386672a60ef7570a89b5fa109e026
Armin, So PPT with OLE formulas and XLSX with charts both evaluate to true at: http://opengrok.libreoffice.org/xref/core/svx/source/svdraw/svdoole2.cxx#1481 Any idea why XLS charts are false
give me some time to check...
AFAIR this was by purpose - I have added Regina on cc, she was involved in discussing for which OLEs we may have a background and for which not. Historically, all OLEs had a fixed background, but unfortunately not by setting attributes for background, but implicitely in the code. When starting to allow to have fill attributes for all objects (graphics, oles, ...) this was in the way. Since no attr were ever set, this has to be corrected at load time to have transparence at all, else fill attributes for the frame would be useless and never visible. Correction is to set to 'no fill'. For charts, AFAIR, we decided to keep a default background fill since these look ugly in Calc when the Calc grid shows through, thus this would be no progress from the old behaviour. Let's see what Regina can remember...
Created attachment 125225 [details] Generated in Excel 2010, saved in old xsl format I think it is an error in the import filter of xsl. If I set the fill explicitly to "no fill" or to "color"&"transparency100%", in both cases the chart gets a blue background. You can test it with the attached file. I have tested a chart generated with a current LO52 too, again with the settings "no fill" and the setting "color and transparency 100%", and saved in xsl format. Same behavior; opening the file in Excel 2010, the background is transparent in both cases; opening in LibreOffice the background is blue in both cases.
I am not sure if Excel2010 allows setting BG/Fill for OLE/Chart at all, but in aqny case it needs to be set at import. Not setting will fallthrough to the default attributes which is the mentioned blue. So when it allows to set colors/Fill it should be set. Is this done at import in the current version? If yes, setting to 'XFILL_NONE' if this is not imported (or identified as there is no fill) needs to be adeed. If no, complete support for importing evtl. fill needs to be added, minimally XFILL_NONE has to be set.
** 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.4.1 or 5.3.6 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-20170901
Yesterday, I opened the "Simple transparent chart created and saved in Excel 2013" attachment in LibreOffice Writer 5.4.1 (64-bit) on newly configured Windows 10 system and the blue background *was* added to the chart.
This regression was fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=6c14c27c SOSAW080: Added first bunch of basic changes to helpers Armin, I'm pleased to report that your hard work cleaning up the graphics framework is resulting in some long standing issues being fixed. Thank you!
Good news! Sorry that in the transition something may break from time to time - the office *is* complex - sigh :-)
Thanks! In which LibreOffice release will we get the fix?
Should be fixed where it is broken - in master only AFAIK