Description: Background fill of shapes in XLSX documents created with Microsoft Excel 2016 disappear when the document is exported in LibreOffice Calc 6.3.0.0.alpha0+ and opened in Excel 2016 Steps to Reproduce: 1. Create a new document in Microsoft Excel. 2. Insert Shapes. 3. Save the file as XLSX 4. Open the same file in LibreOffice Calc 5. Select File and Save As 6. Name the file 7. Open the exported file in Microsoft Excel 8. Compare the original file opened in Excel and the exported file opened in Excel 9. Notice, that the background fill of shapes are not visible. Actual Results: Background fill of shapes in XLSX documents created with Microsoft Excel 2016 disappear when the document is exported in LibreOffice Calc 6.3.0.0.alpha0+ and opened in Excel 2010 Expected Results: Background fill of shapes should be visible as the original file opened in Microsoft Excel 2016 Reproducible: Always User Profile Reset: No Additional Info: LibreOffice details: Version: 6.3.0.0.alpha0+ Build ID: 65438bcda46bab4f2fe6fb555f44aace45e11e5e CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: threaded Also happens in: Verzió: 4.3.0.4 Build az.: 62ad5818884a2fc2e5780dd45466868d41009ec0 But not with: Verzió: 4.2.0.4 Build az.: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Created attachment 149904 [details] Example file from Excel
Created attachment 149905 [details] The example file saved by LO 4.2
Created attachment 149906 [details] The example file saved by LO 4.3
thank you for reporting the bug. I cannot reproduce the bug in Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
I can't reproduce it in Version: 6.3.0.0.alpha0+ Build ID: c196d70337f6b755cfc4c34beda05554c6fab114 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded nor in Versión: 6.2.2.1 Id. de compilación: fcd633fb1bf21b0a99c9acb3ad6e526437947b01 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded with MSO 2010 @NISZ Team, are you sure you attached the correct file ?
Oh, the description is a bit wrong :( Instead of opening the LO-exported file in Excel, you should open it in Calc. In Excel the shapes would stay visible, but in Calc they "lose" their fill color. They are still present in the Navigator: under Drawing objects you can select them, and switching to the Properties side bar panel you can see they don't have any fill attribute set. This begun sometime between 4.2 and 4.3.
Created attachment 149978 [details] The exported file on my current local build Here setting a fill color would bring back the shape.
It seems the theme-color information is lost. If you do not use theme-colors in Excel, but use an own color, this is retained in LibreOffice. The shape has a fill and stroke color 'white' for me.
Bibisected with Linux 43max to range https://gerrit.libreoffice.org/plugins/gitiles/core/+log/160db96a882a2be8c3307e8a04beda4ae93a13c4..6069b5162281ccc88eb242991a115197d0893fb4 I don't see what it could be. There were two bad results: shapes gone and only fill gone. I targeted only fill gone, because it was older.
Bibisected with the new win32-4.3 to https://gerrit.libreoffice.org/plugins/gitiles/core/+/bc0a9076aa43a0782bcf81e55d3f84f6af0f68e8%5E!/ ooxml: Preserve shape theme attribute for solid fill Same one blamed for bug 91332 and bug 103478
*** Bug 123108 has been marked as a duplicate of this bug. ***
Still reproducible in Version: 6.3.0.0.alpha1+ Build ID: 787525a314de9c8178d0fedcd71ddbd08ec41a55 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Tamás, since you fixed bug 125346, I thought you could be interested in this issue...
@Tamás, since you fixed bug 125346, I thought you could be interested in this issue...
(In reply to Buovjaga from comment #10) > Bibisected with the new win32-4.3 to > https://gerrit.libreoffice.org/plugins/gitiles/core/+/ > bc0a9076aa43a0782bcf81e55d3f84f6af0f68e8%5E!/ > ooxml: Preserve shape theme attribute for solid fill > > Same one blamed for bug 91332 and bug 103478 In that commit, jacobo added this comment in https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml.cxx?r=ef43ee69#443 // in case the shape used the style color and the user didn't change it, // we must not write a <a: solidFill> tag. why? who knows... so the this issue is only happening when the color is not saved, if we change the color and then saved the document, the shape is displayed after the RT Removing the condition before the comment if ( nFillColor != nThemeColor || nAlpha != nThemeAlpha ) would fix the issue...
(In reply to Xisco Faulí from comment #14) > In that commit, jacobo added this comment in > https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml. > cxx?r=ef43ee69#443 > > // in case the shape used the style color and the user didn't change it, > // we must not write a <a: solidFill> tag. > > why? who knows... > The idea here was to preserve theme color info. But we still don't write out themeN.xml so reading back the actual color fails. Excel writes the shape solid fill like: <a:solidFill> <a:schemeClr val="accent2"/> </a:solidFill> and line color like: <a:ln w="38100"> <a:solidFill> <a:schemeClr val="accent6"/> </a:solidFill> </a:ln> These schemeClr "links" are preserved on XLSX export by Calc. The actual RGB values are defined in the themeN.xml which Calc unfortunately does not save. So Excel can use its default themes and show correctly the roundtripped colors based on this, but Calc cannot.
Regényi Balázs committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c1376ad6f52d04c1c29e73bc5b312744c74f8bdd tdf#124013 XLSX shape export: fix missing solidFill It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.1.0.0.alpha0+ Build ID: cd85546a2fbdade42f80fd3b6bd650791db9f32d CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11 Locale: tr-TR (en_US.UTF-8); UI: en-US Calc: threaded @Balázs Regényi, thanks for fixing this issue!!
This bug is for XLSX, but I tested also XLS, looks fine.
Regényi Balázs committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/d67809efc6b372f5c8ddfa88551fcc89efe48cdc tdf#124013 XLSX shape export: fix missing solidFill It will be available in 7.0.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 97057 has been marked as a duplicate of this bug. ***