Description: First of all, my use for gradients isn't decorative. In my chart, I'd like to have the area of an interval of years in a different colour. I thought about placing a rectangle on top of this part of my chart, but I was looking for a more elegant solution, so I thought about testing gradients, hoping to be able to precisely set the position where the second colour starts. I have two problems, though: 1. I can't set 2 increments, as the minimum is 3 (I need to find out about this issue and possibly write a separate report). 2. After setting the angle to 90 degrees, choosing two colours and clicking on "OK", my preferences are overruled and I keep getting a black, gray and white background with an angle of 0 degrees. Steps to Reproduce: 1. I create a chart. 2. I click on "Format Wall". 3. I set an angle of 90 degrees. 4. I choose two colours. 5. I click on OK. Actual Results: 1. The degree is reset to 0. 2. Instead of the colours I chose, I get black, gray and white. Expected Results: My settings for degree and colours should be kept. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.3.2 (X86_64) / LibreOffice Community Build ID: 29d686fea9f6705b262d369fede658f824154cc0 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-GB Calc: CL threaded
Created attachment 191098 [details] Video showing the issue with gradients
Created attachment 191099 [details] My Calc document
Reproducible: Version: 7.6.3.2 (X86_64) / LibreOffice Community Build ID: 29d686fea9f6705b262d369fede658f824154cc0 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5589659829f8a1cef8ca1c8a468732105bbe231b CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Seems that changing the angle for any standard gradient, produce this result. Regression from Version: 7.5.9.1 (X86_64) / LibreOffice Community Build ID: 2f04f73a0f4ebfe9735ca11da23d6ed8f830fe34 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Hallo As a workaround: (works for me) 1. I create a chart. 2. I click on "Format Wall". 3. I set an angle of 90 degrees. 4. I choose two colours. #additional: 5. click on »add« button, and there on »ok« 6. I click on OK.
The workaround works me too: thanks!
Bibisected with linux-64-7.6 repository to first bad build commit [6e025eb97c6bbd2413d75ea0555482945154dbbb] which points to core commit: commit 01d0019c851b9e942f9a3b94d6dd554fb1adb40c author Armin Le Grand (allotropia) Mon Mar 13 19:39:34 2023 +0100 committer Sun Mar 19 17:38:38 2023 +0000 MCGR: Model data changes for ColorSteps Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148849 Still reproduced in recent trunk build: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5589659829f8a1cef8ca1c8a468732105bbe231b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Armin, can you please have a look?
(In reply to David García from comment #0) > 1. I can't set 2 increments, as the minimum is 3 (I need to find out about > this issue and possibly write a separate report). That is a restriction from file format: <quote> The draw:gradient-step-count attribute specifies the gradient step count of a color interpolation. ●Value 0 means that the step count is automatically calculated on the size and resolution of the filled area. ●Values 1 and 2 shall not be used. ●Values of 3 or greater mean that the step count is that fixed value. </quote> https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1419688_253892949
> That is a restriction from file format: Thanks for the information! It probably doesn't make sense to have a gradient where there is no intermediate step between one colour and the other one. I think I was just trying to use the gradient for the wrong reasons.
For draw:gradient-step-count: I think '3' as minimum was a bad choice, '2' would b better and also work. Probably happened due to '2' not really creating a gradient due to just Start/EndColor being used. This is 'half-true', but still would fill the ColorRange with two aequidistant gradient pieces (using just Start/EndColor) -> I would support to change that... For the error: Seems as if this happens (in Chart) due to chart2/source/controller/itemsetwrapper/GraphicPropertyItemConverter.cxx the method GraphicPropertyItemConverter::ApplySpecialItem in case XATTR_FILLGRADIENT expecting a 'Name' for the NameOrIndex-Value of the gradient. NOTE: With the workarond there is a name, so that works. The XFillStyleItem without name gets created at SvxGradientTabPage::FillItemSet in the 'else' branch, so will now have to check how and why a name was created/added here before that model change...
Checked commit 01d0019c851b9e942f9a3b94d6dd554fb1adb40c, but saw no changes that prevent/change to create a name for a NameOrIndex Item. Will have to build & check version before that change
Problem is in GraphicPropertyItemConverter::ApplySpecialItem: in case XATTR_FILLGRADIENT the call to PropertyHelper::addGradientUniqueNameToTable does *no longer* create a name -> previous versions did... Reason is that addGradientUniqueNameToTable uses lcl_addNamedPropertyUniqueNameToTable and that checks ( rValue.getValueType() != xNameContainer->getElementType())) and fails. This is due to ValueType of rValue being css.awt.Gradient2 while the ElementType of the NameContainer is css.awt.Gradient (see SvxUnoGradientTable::getElementType()). Unfortunately SvxUnoNameItemTable is not capable of serving two ElementTypes, so here we have to use eiter one (or use two NameItemTables?). Have to check possible fix(es)...
Two lists make no sense and would be complicated. Strategically LO should use the newer and more capable type Gradient2 everywhere, except when needed, e.g. im/export, compatibility fallbacks. So: Will have to change the type of list to Gradient2. Also checked where that list is used and found the same problem for SvxUnoTransGradientTable (indeed same error there). Added fallback code to lcl_addNamedPropertyUniqueNameToTable to convert an evtl. given Gradient in uno::Any to Gradient2 and print a warnig about it (SAL_WARN). Looks good with that, doing some tests...
On Gerrit, see https://gerrit.libreoffice.org/c/core/+/160463
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6c986c718630ab21e6d9b5d353ddf1534e2dda41 tdf#158421 use correct awt:Gradient2 in Chart lists It will be available in 24.8.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.
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/aa281fab00724d23c8d6f1f7fd557e3f05dcfc51 tdf#158421 use correct awt:Gradient2 in Chart lists It will be available in 24.2.0.0.beta2. 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.
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/f662cf428692e4b031b43fd6e4022cba16728fac tdf#158421 use correct awt:Gradient2 in Chart lists It will be available in 7.6.5. 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.
Fix verified in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fdc87dd56548622e13353b4cf9864232ee0110fb CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Thank you Armin and all!
Fixed in 24.2.0.3! Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded