Description: When I set a gradient background with the settings line colour: black; line type: crossed; distance: 0,20cm to a LO Impress presentation, save it and re-open it, it is now blue, simple and has a distance of 0,02cm. Steps to Reproduce: 1. Create a new presentation 2. Set the background to the settings I mensioned in the description 3. Save the file 4. Re-open it Actual Results: The background changed Expected Results: The background shouldn't have changed Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.4.6.2 (x64) Build-ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115 CPU-Threads: 4; BS: Windows 6.1 Service Pack 1 Build 7601; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
I noticed the bug in version 6.2.7.1, then did an update to 6.4.6.2 and it is still reproducable.
I suppose that the description should have "Hatch" instead of "Gradient", and "Spacing" instead of "distance" ... then I repro with Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL and ODP used for saving.
(In reply to Mike Kaganski from comment #2) > I suppose that the description should have "Hatch" instead of "Gradient", > and "Spacing" instead of "distance" ... and also "Dark Blue 1" instead of "blue", and "Single" instead of "simple". :/
From my perspective not a bug but a usage error. The description does not mention that either **Modify** button or **Add** button has been clicked to either modify an existing hatch pattern or to add a new (custom) hatch pattern. If doing so, it is not repro in: Version: 7.0.2.2, Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US, Calc: threaded not repro in: Version: 6.4.7.2 Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5; Locale: en-US (en_US.UTF-8); UI-Language: en-US, Calc: threaded
(In reply to Uwe Auer from comment #4) > From my perspective not a bug but a usage error. The description does not > mention that either **Modify** button or **Add** button has been clicked to > either modify an existing hatch pattern or to add a new (custom) hatch > pattern. If doing so, it is > and not repro on Windows as well: Version: 7.0.2.2 (x64), Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE,Calc: threaded
(In reply to Uwe Auer from comment #4) > From my perspective not a bug but a usage error. The description does not > mention that either **Modify** button or **Add** button has been clicked to > either modify an existing hatch pattern or to add a new (custom) hatch > pattern. Hmm, right ... but it's still a bug. If it weren't, then why does OK applies the black cross-hatch with large spacing, and not the one that should be without the Add/Modify?
*** Bug 137740 has been marked as a duplicate of this bug. ***
> Hmm, right ... but it's still a bug. If it weren't, then why does OK applies > the black cross-hatch with large spacing, and not the one that should be > without the Add/Modify? OK - take my comment as a workaround.
The question is - which bug it is: is this a problem of not saving in the file, or of the dialog applying wrong (not saved) hatch?
Thank you, Mike, for adding the correct english words. I'm using the German version of LO and my attempts of finding the right English words did obviously fail... :-( I also would like to thank you, Uwe, for explaining how to get it working. But, as Mike already mentioned, it wasn't clear to me when working with the dialog; so I think, this could be improved.
In the course of getting familiar with LibreOffice's consequent application of a style based design, it started to get quite familiar to me, that I'm required to to add a new, let's say, hatch style (or at least modify an existing hatch pattern). So my rationale rather would be that it is a bug to show the settings and the bug is not to not save the settings made, though a completely admit that users expect the setting to be stored and reapplied on opening the document. So there is room for improvement to make that clear to the user.
Thank you for sharing your thoughts. I truly appreciate your efforts and I will be waiting for your further write ups thanks once again. https://mcafeeactivatenow.com/ https://setupofficecomsetup.com/
Created attachment 167820 [details] drawHandHatch.odg: a hand-crafted document containing a custom hatch The same problem is seen in Draw of course. In Word - it accepts it without being added as a persistent hatch. The attached document proves that it can work if the hatch is written out to the styles file - like Writer does. So I would say that this is a bug. The adding of a hatch should only be if the user wants to add this as a permanent choice to his user settings to easily get the same hatch.
Limited, predefined hatching support has been in Draw since before LO 3.5. For Writer's Page background, hatching was new in LO 4.4. It required you to select from predefined hatches, but you couldn't define your own hatches anywhere until LO 5.3. Everything worked horribly until LO 5.4. Word fixed decently in bug 103847, but the code doesn't help here. LO 5.3's edit the hatching was a GSOC project commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=686349476e03f951f4a9ff9755b9f71951b64ea5 By the time the UI worked in 5.4, the saving part was already working fine. So I'm not sure how to find code pointers for that part that is missing in Draw. Somewhere I saw a dialog box warning if you modified a hatch, but didn't save it. Unfortunately I can't find that back...
It works fine for the background of a Draw's textbox... I'm sure the big clue is empty name in content.xml's <style:drawing-page-properties draw:fill="hatch" draw:fill-hatch-name=""/> ODF export code is voodoo to me, so I'm fairly lost at even where to start.
We can copy-cat LO 6.3.4 bug 125449 to fix this. Proposed patch at http://gerrit.libreoffice.org/c/core/+/107258
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0c37e164dbbff89ecac843e1b182fdbce70cda34 tdf#137729 sd UI: unique hatch names in slide/page area dlg It will be available in 7.2.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.
Thanks to Xisco for the unit test. Backport to 7.1 is in gerrit.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/601329a5e873506ddbea9b7e0669fb63bb46ad53 tdf#137729: sd: Add UItest It will be available in 7.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/6b161f615712f6daa11f66d0dfe45eef0877c860 tdf#137729 sd UI: unique hatch names in slide/page area dlg It will be available in 7.1.0.2. 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.
Thanks to Katarina for the gradient code that I copied to fix this bug.