Created attachment 130333 [details] enhanced geometry and image of it Open attached pptx document. It contains three shapes of type "bevel" and an image of these shapes, created by PowerPoint 2010. You will notice that the left and top part of the bevel has wrong colors. (1) The left part should be lighter than the top part. The left part has attribute value "lighten" and the top part has attribute value "lightenLess" according the presetShapeDefinitions.xml from the spec. (2) The "lighten" and the "lightenLess" parts have wrong colors in case the basic fill color (in the middle) has a low luminance. Such case is the right shape. When you examine the colors and look at their HSL-values, you can see, that PowerPoint does not only increase the luminance in this cases, but reduce the saturation in addition. LO misses this.
Confirmed in - Version: 5.4.0.0.alpha0+ Build ID: 9a30cb2161506e003f14592d83075ab9d30516c1 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group - Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Created attachment 130344 [details] How it looks in MSO
I think, the new part with dBrightness in /core/svx/source/customshapes/EnhancedCustomShape2d.cxx and /core/svx/source/svdraw/svdopath.cxx is totally wrong. It applies fixed, unexplained factors to the colors, which are already adjusted based on the values stored in nColorData according to the various mso_spt... shape types. But the old part, inherit from OpenOffice is wrong too. You see the difference best with a dark fill color. Look at the "lighten" part. You can notice, that it has less saturation in PowerPoint than in OpenOffice. Microsoft has described the calculation to be used in https://msdn.microsoft.com/en-us/library/hh745894%28v=office.12%29.aspx?f=255&MSPPError=-2147217396. So the correct calculation would be: for lighten: resultColor = 0.6 * fillcolor + 0.4 * 255 for lightenLess: resultColor = 0.8 * fillcolor + 0.2 * 255 for darken: resultColor = 0.6 * fillcolor + 0.4 * 0 for darkenLight: resultColor = 0.8 * fillcolor + 0.4 * 0 If I examine the colors in the image with a paint-application, I see exactly these result (besides rounding). I see no need to switch to HSV for the calculations.
I know how to fix the wrong calculation in case of type ooxml. But I want to discuss, whether a more general solution wouldn't be better, see http://nabble.documentfoundation.org/ODF-TC-issue-2049-custom-shape-enhancement-tt4205306.html
The proposed patch in https://gerrit.libreoffice.org/33337 fixes the wrong calculation. But I think, that the current design is not good. The information about lighten and darken belongs to the enhanced geometry. Such information should not be transported via the class SdrPathObj, because such objects are used in various places in the code, not only for enhanced geometry.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=852b29b091eeb4d4b9521b082b522c37a2a6ec16 tdf#105266 Make LIGHTEN and DARKEN follow MS specification It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hello Regina, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
It is fixed in Version: 5.4.0.0.alpha0+ Build ID: eb7b03b052ffe8c2c577b2349987653db6c53f76 CPU threads: 4; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-26_22:34:18 Locale: de-DE (de_DE); Calc: group
per comment 8, verified, hence change of status.