Created attachment 133531 [details] Example file from LO 5.3 The gradient property of the data series in charts is not preserved when the file is saved as DOCX in LibreOffice Writer. Steps to reproduce: 1. Create an empty text document in LibreOffice Writer 2. Insert a Chart 3. Change the Data Series Transparency property to Gradient 4. Save the file as DOCX 5. Reopen the file either in LibreOffice Writer or Microsoft Word 2013 Actual results: The gradient disappears Expected results: The gradient should be preserved
Created attachment 133532 [details] Example file saved from LO 5.3
Created attachment 133533 [details] Docx in Word 2013 and odt in LO 5.3 side by side
Confirmed in - Version: 5.4.0.0.alpha1+ Build ID: 74d2e606fd3605fe0a585f596eaa215ae4e20d18 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; Locale: en-US (ca_ES.UTF-8); Calc: group - Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 In previous versions the chart wasn't exported at all.
** 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
Created attachment 155040 [details] Extended example file In reality this can be a more widespread problem. Based on the original file, it is possible to set this gradient transparency for paragraph (although that does not work in odt either), page, frame, drawing object and most chart components: background, data series, data point (originally this bug was about that), legend, title, axis title. On OOXML export all these are lost, although do not cause invalid XML error, only a waste of time.
Created attachment 155041 [details] The extended example file saved to docx Gradient settings are now gone.
From the proposed patch, "It is possible in ODF to set a gradient type transparency for several objects: paragraph background, page background, shape and frame background and most of the chart components. In OOXML it is not possible to use/save that, only a simple transparency expressed as a percentage value. To avoid user confusion and possible waste of work time a centrally manageable configuration key is introduced to disable this UI option in OOXML-heavy environments. Default setting is true so it means no change compared to current feature set." In MSO each gradient stop has its own transparency value, whereas our color has no transparency. So you need the transparency gradient on import from OOXML. Perhaps instead of totally disabling it, it would be better to restrict the kind of the transparency gradient to the kind as the color gradient and only allow setting the transparency value.
(In reply to Regina Henschel from comment #7) > From the proposed patch, "It is possible in ODF to set a gradient type > transparency for several objects: paragraph background, page background, > shape and frame background and most of the chart components. In OOXML it is > not possible to use/save that, only a simple transparency expressed as a > percentage value. To avoid user confusion and possible waste of work time a > centrally manageable configuration key is introduced to disable this UI > option in OOXML-heavy environments. Default setting is true so it means no > change compared to current feature set." > > In MSO each gradient stop has its own transparency value, whereas our color > has no transparency. Hi Regina Thanks for the review. This is not a straightforward area, so help thinking about it is much appreciated. My understanding so far is that in MSO the solid color fill can have a transparency which is expressed as a percentage value. This is interoperable in LO when we select a color on Area -> Color and set a percentage transparency value on the Transparency tab. It is also possible to set a Transparency value for a Gradient type fill in MSO, and that could be imported/exported, but the export currently does not work. > So you need the transparency gradient on import from > OOXML. This is only about not setting something that cannot be exported anyways. Import would be a different beast... I mean bug. > Perhaps instead of totally disabling it, it would be better to > restrict the kind of the transparency gradient to the kind as the color > gradient and only allow setting the transparency value. What I'd like disable here is, to my understanding: the gradient of the transparency, which is nonexisting in OOXML. Not the gradients transparency, which is similarly to the color fills transparency a percentage value and could be transformed to the Transparency spinbox of the Transparency tab.
Created attachment 155120 [details] Example document with color and gradient transparency
Created attachment 155121 [details] Screenshot of the exported example document in LO master and word - with color transparency
Created attachment 155122 [details] Screenshot of the exported example document in LO master and word - with gradient transparency
Created attachment 155124 [details] Column area with gradient transparency If the MSO document has transparency on the stop, then it is currently correctly imported as a solid color in the gradient itself and parallel a transparency gradient for the transparency of the original stop. It is correct, that this transparency is not exported currently. But for that problem the solution should be to fix the export.
Hi Balázs, what are you going to implement? The proposed configuration key or will you fix export of transparency?
(In reply to Regina Henschel from comment #13) > Hi Balázs, what are you going to implement? The proposed configuration key > or will you fix export of transparency? I will fix the export of gradient transparency. :)
I already have a working patch for this bug, but more time is needed for the optimization.
OK, then I will stop my efforts there. Can you put the patch into Gerrit already now and set me for review? Nevertheless, some results of my investigations are in https://lists.freedesktop.org/archives/libreoffice/2019-October/083643.html and https://gerrit.libreoffice.org/#/c/81165/
(In reply to Regina Henschel from comment #16) > OK, then I will stop my efforts there. Can you put the patch into Gerrit > already now and set me for review? > > Nevertheless, some results of my investigations are in > https://lists.freedesktop.org/archives/libreoffice/2019-October/083643.html > and https://gerrit.libreoffice.org/#/c/81165/ Thank you very much for the helping. Of course, I will push the patch into gerrit, maybe tomorrow.
I have written bug 128345 to separate the case of solid fill. It makes sense to separate it despite the attachment [2019-10-18 13:03 UTC, Gabor Kelemen], because it is a problem with ordinary shapes too. Balázs Varga: Can you please test your patch on a chart in Calc? It crashes for me, if I only build oox. And building totally needs some time.
Balázs Varga: With a full build, it is OK now. The import of the transparency gradient is missing. Will you do it in the same patch?
Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef43ee69a355c0eda49d2f62540fbcf1299a59d2 tdf#108065 tdf#128609 OOXML chart export: fix transparent color gradient It will be available in 6.4.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.