Bug 78558 - FILEOPEN: Excel chart with transparent background imported over blue frame
Summary: FILEOPEN: Excel chart with transparent background imported over blue frame
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: Other All
: high major
Assignee: Not Assigned
Keywords: bibisected, filter:xls, regression
Depends on:
Reported: 2014-05-11 16:35 UTC by Tom Williams
Modified: 2018-06-13 08:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Original ODS spreadsheet used to generate other test case files. (32.43 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-05-11 16:36 UTC, Tom Williams
Original ODS spreadsheet saved as MS Excel 2003 file. (10.50 KB, application/vnd.ms-excel)
2014-05-11 16:37 UTC, Tom Williams
Original ODS spreadsheet saved as MS Excel 2007/2010 XML file. (8.86 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2014-05-11 16:37 UTC, Tom Williams
Screen shot of Calc displaying original ODS spreadsheet. (163.78 KB, image/png)
2014-05-11 16:38 UTC, Tom Williams
Screen shot of Calc displaying MS Excel 2003 spreadsheet. (162.31 KB, image/png)
2014-05-11 16:39 UTC, Tom Williams
Screen shot of MS Excel 2007 security violation message (45.22 KB, image/png)
2015-09-05 16:07 UTC, Tom Williams
Simple transparent chart created and saved in Excel 2013. Calc adds a blue background (13.84 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-09-05 20:48 UTC, Luke
Simple transparent chart created and saved in Excel 2013. Calc adds a blue background (31.50 KB, application/vnd.ms-excel)
2015-12-23 08:15 UTC, Luke
Generated in Excel 2010, saved in old xsl format (40.50 KB, application/ms-excel)
2016-05-22 12:00 UTC, Regina Henschel

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Williams 2014-05-11 16:35:32 UTC
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 on Ubuntu 14.04 Linux (64-bit) and then I was able to recreate it in Calc on Windows XP SP3.

Attached are screen shots and some test files.
Comment 1 Tom Williams 2014-05-11 16:36:53 UTC Comment hidden (obsolete)
Comment 2 Tom Williams 2014-05-11 16:37:23 UTC Comment hidden (obsolete)
Comment 3 Tom Williams 2014-05-11 16:37:52 UTC Comment hidden (obsolete)
Comment 4 Tom Williams 2014-05-11 16:38:30 UTC Comment hidden (obsolete)
Comment 5 Tom Williams 2014-05-11 16:39:03 UTC Comment hidden (obsolete)
Comment 6 Tom Williams 2014-05-11 16:39:59 UTC
I almost forgot to mention, Calc and Calc load the MS Excel 2007/2010 spreadsheet just fine and the transparent background is preserved.
Comment 7 sophie 2014-06-04 13:46:06 UTC
Hi, confirmed with, and 4.3.0. Didn't find a duplicate. Change version, set as New - Sophie
Comment 8 Luke 2014-09-04 01:37:53 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2015-09-04 02:49:38 UTC Comment hidden (obsolete)
Comment 10 Tom Williams 2015-09-05 16:05:54 UTC Comment hidden (obsolete)
Comment 11 Tom Williams 2015-09-05 16:07:13 UTC Comment hidden (obsolete)
Comment 12 Luke 2015-09-05 20:48:19 UTC Comment hidden (obsolete)
Comment 13 Luke 2015-12-22 04:49:46 UTC
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:
While the transparent uses:

The importer likely needs an equivalent to this:
Comment 14 Luke 2015-12-23 08:15:12 UTC
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".
Comment 15 Luke 2015-12-23 08:36:36 UTC
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.
Comment 16 Luke 2015-12-23 11:56:04 UTC
This bug is a regression that was never bibisected. 
Version (Build ID: e183d5b) correctly opens attachment 118447 [details]
Comment 17 Luke 2015-12-23 12:06:19 UTC
Version (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.
Comment 18 Luke 2015-12-23 12:19:15 UTC
Version (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24) : good
Version: Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155: bad
Comment 19 Luke 2015-12-27 10:46:22 UTC
Armin, any idea what could be causing this? Could is be related to Issue 121334? 
Comment 20 Armin Le Grand 2015-12-31 11:28:36 UTC
Hi Luke,
thanks for mentioning, I will check asap - which means it may take some days around new year's eve :-)
Comment 21 Christian Lohmaier 2016-01-20 13:39:47 UTC
bibisected to the range 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
Comment 22 Luke 2016-01-21 09:48:44 UTC
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:
is true for OLE equations but false for OLE charts. Do you have any idea why? Could this be the source of the problem?
Comment 23 Christian Lohmaier 2016-01-21 13:04:36 UTC
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
Comment 24 Luke 2016-01-23 02:17:36 UTC
So PPT with OLE formulas and XLSX with charts both evaluate to true at:
Any idea why XLS charts are false
Comment 25 Armin Le Grand 2016-01-24 12:49:19 UTC
give me some time to check...
Comment 26 Armin Le Grand 2016-01-25 10:16:27 UTC
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...
Comment 27 Regina Henschel 2016-05-22 12:00:46 UTC
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.
Comment 28 Armin Le Grand 2016-05-25 08:15:03 UTC
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.
Comment 29 QA Administrators 2017-09-01 11:20:26 UTC Comment hidden (obsolete)
Comment 30 Tom Williams 2017-09-03 17:46:00 UTC
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.
Comment 31 Luke 2018-06-06 07:31:32 UTC
This regression was fixed by


SOSAW080: Added first bunch of basic changes to helpers

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!
Comment 32 Armin Le Grand 2018-06-06 08:03:00 UTC
Good news! Sorry that in the transition something may break from time to time - the office *is* complex - sigh :-)
Comment 33 Tom Williams 2018-06-06 13:00:56 UTC
Thanks! In which LibreOffice release will we get the fix?
Comment 34 Armin Le Grand 2018-06-13 08:24:42 UTC
Should be fixed where it is broken - in master only AFAIK