Created attachment 86273 [details] DOCX containing formatted text-box with a gradient background Problem description: LO loads the attached DOCX and does renders the gradient color of the text-box mirrored than like in MS Word (see comparison screenshot). Steps to reproduce: 1. Load the attached DOCX 2. The gradient background of the text-box is incorrect Current behavior: LO doesn't import and render the text-box's gradient background correctly Expected behavior: LO should import and render the text-box's gradient background correctly Operating System: All Version: 4.2.0.0.alpha0+ Master
Created attachment 86274 [details] Screenshot comparison between MS Word and LibreOffice
Thank you for your bug report, I can reproduce this bug running LibreOffice: Version: 4.2.0.0.alpha0+ Build ID: 164b6ce7b27c0a9ec19019e7b078b9f8f382007d TinderBox: Win-x86@39, Branch:master, Time: 2013-09-28_16:39:4 And Mircosoft Word 2007
*** Bug 73553 has been marked as a duplicate of this bug. ***
I repost here an interesting observation from Bug 73553 .................................................... Jacobo Aragunde Pérez 2014-01-13 13:12:15 UTC Created attachment 91944 [details] Test case Compare the colors of the shape contained in the attached document when you open it with MS Office and LibreOffice: the order of the first and second colors is swapped. Check the OOXML definition of the gradient with the definition of a document exported from LibO: Original document, see how the second and the third colors are equal: <a:gradFill> <a:gsLst> <a:gs pos="0"> <a:schemeClr val="accent5"/> </a:gs> <a:gs pos="50000"> <a:schemeClr val="accent1"> <a:tint val="44500"/> <a:satMod val="160000"/> </a:schemeClr> </a:gs> <a:gs pos="100000"> <a:schemeClr val="accent1"/> </a:gs> </a:gsLst> <a:lin ang="5400000" scaled="0"/> </a:gradFill> Exported document, see how the first and the third colors are equal now: <a:gradFill> <a:gsLst> <a:gs pos="0"> <a:srgbClr val="ff388c"/> </a:gs> <a:gs pos="50000"> <a:srgbClr val="005bd3"/> </a:gs> <a:gs pos="100000"> <a:srgbClr val="ff388c"/> </a:gs> </a:gsLst> <a:lin ang="5400000"/> </a:gradFill>
I could add more details now :) The reason why the gradient changes is because we don't support gradients with more than two colors in LibreOffice. You can check the API of the Gradient structure at [1], there are only two colors in it. If you check the code at [2], you will see how a gradient with >2 stops is transformed by the importer. To sum up, a proper fix for this bug would imply the implementation of a new feature: support of gradients with any number of color stops. Right now, the code in master (4.3) is able to preserve the original gradient when exporting back to .docx but it's yet unable to render the gradient correctly. [1] http://api.libreoffice.org/docs/idl/ref/structcom_1_1sun_1_1star_1_1awt_1_1Gradient.html [2] http://opengrok.libreoffice.org/xref/core/oox/source/drawingml/fillproperties.cxx#368
The rendering of the gradient has improved a bit now after commit f4a2f1e647354efb75be8c90384d6cd3e5f9b9bd (in master) and its follow-up fixes for pre-C++11 and the sd import unit test, which have been cherry-picked to the 4.3 and 4.2 branches, too. LibreOffice still has gradients with only two stops (start and end), but the OOXML import code now tries to be more clever in deciding how to map a multi-stop OOXML gradient to a LibreOffice gradient. Possibly this bug can now be resolved, or should it be kept open until LibreOffice gets proper support for gradients with an arbitrary number of stops?
Created attachment 102981 [details] screenshot in 4.2.5.2 here's a screenshot of the test file like is shown in LibO 4.2.5.2 it looks to me that the improvement in substantial. i suggest to mark it FIXED and if necessary open a followup bug report about residual issues.
I mark this as FIXED since the most obvious issue about the flipped gradient which was the focus of this report is gone.