Created attachment 152759 [details] Impress document with character highlight issue Changing Highlight color to "No fill" is not saved in Impress document. Steps to reproduce: - Open attached Document - point left lower orange "box" with mouse and mark all - select Format->Character->Highlighting - select or confirm "None" - text "TITEL" gets visible - save file - open file - text "TITEL" is unchanged (orange Text on orange Highlight) - should be: "TITEL" is orange text - no colored Highlight background behaviour is in current 6.2.5 fresh and also in 6.1.6 still release.
Could confirm the buggy behaviour. You could set the highlighting to "None" but it won't be saved. Only change to another colour like "white" will be saved. Bug appears also in LO 5.1.5.2, also LO 6.2.0.0 beta2. Tested all with OpenSUSE 15 64bit rpm Linux.
The saved file has correctly fo:background-color="transparent". The print preview has it correct. PDF Export is correct too. So it is not a save or open problem, but a rendering problem. With a Basic macro you see CharColor = 15764006 (=F08A26) and CharBackColor = -1013210 (= -F08A26 on 24Bit) and CharBackTransparent = TRUE. Workaround, if character style is unique in the text box: Use a style for the text box and set Highlight to None there.
My own tests confirm the conclusions made by Regina, which I just happened to discover here. The information contained in the saved module seems OK (also in comparison with a similar cass in Writer), the interpretation of the informations contained in the object and the style seems to be wrong when the file is presented in the user interface of LibO; I tested printing with PDF24, in addition to Regina's statements, which also showed the correct interpretation. So it seems to boil down to the representaion in the UI of LibO. The title "character Highlight color 'No fill' not saved" for the bug report is not very precise, which might lessen the impact on people able to tackle such problems, and is also not accurate regarding Regina's observations; I narrowed down the scope with a change of the summary.
Bad in 4.4.7.2 Fine in Versie: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
CONFIRMED on Ubuntu 18.04 LTS and LibreOffice 6.0.7.3 Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.10 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3; Locale: en-IN (en_IN); Calc: group
(In reply to Harshita Nag from comment #5) > CONFIRMED on Ubuntu 18.04 LTS and LibreOffice 6.0.7.3 > > Version: 6.0.7.3 > Build ID: 1:6.0.7-0ubuntu0.18.04.10 > CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3; > Locale: en-IN (en_IN); Calc: group It only fails for No fill, I tried with other colours, the changes were saved.
Bisected with bibisect-44max. This seems to have begun at the below commit. Adding Cc: to Kohei Yoshida; Could you possibly take a look at this one? Thanks d09c5defb702f63eabd460d81f2e9434866f3b24 is the first bad commit commit d09c5defb702f63eabd460d81f2e9434866f3b24 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Mar 14 23:38:09 2015 +0800 source-hash-0f47de0cff673d298af63926e15e3dff40ee80db commit 0f47de0cff673d298af63926e15e3dff40ee80db Author: Kohei Yoshida <kohei.yoshida@collabora.com> AuthorDate: Tue Jul 22 15:25:27 2014 -0400 Commit: Kohei Yoshida <kohei.yoshida@collabora.com> CommitDate: Tue Jul 22 15:26:14 2014 -0400 Fix the font handling esp wrt font colors.
It can hardly be a regression. But yeah, if before it wasn't setting a background colour, and now it is (and it happens to look better without a background) then it seems like a regression. Clear formatting (and looking at styles.xml for "Standard graphic") shows that it inherits an orange character highlight style (and black text). But I don't know where to find this via the UI.
(In reply to Justin L from comment #8) > But I don't know where to find this via the UI. Drawing Styles - Default Drawing Style - Highlight (I was looking at Area). Nothing special about that. You can't cancel a highlight via a NONE (at least on file-open) no matter what style it is set on.
(In reply to Regina Henschel from comment #2) > The saved file has correctly fo:background-color="transparent". The print > preview has it correct. PDF Export is correct too. So it is not a save or > open problem, but a rendering problem. [..] > Workaround, if character style is unique in the text box: Use a style for > the text box and set Highlight to None there. JustinL: > Drawing Styles - Default Drawing Style - Highlight (I was looking at Area). So you successfully got the workaround mentioned by Regina ;o)) To see the effect do: Mark all Text (TITEL), then go to Format -> Character -> Highlighting tab You'll see: pressed "Color" button with color orange. now press "None" button and you'll see orange colored "TITEL" on transparent background Now save the file and reopen it: the orange in orange text on background is back also on the Highlighting tab. As Regina said: It's a rendering problem, not a saving problem.
Created attachment 178533 [details] 126382_transparent.odg: In Draw as well as impress Using a Draw document might be easier to diagnose because there are less items setting background colour. At first I thought it was a file-load issue. However, all the dialogs are showing NONE for the highlighting - so obviously the setting must have loaded OK. As seen in the document, a NONE in a style does override a color in a parent style. So it only seems to be direct formatting that fails to affect the display. The big question then is why does resetting the property via the UI affect the display, but setting the property during import doesn't? (I tried various methods of "refreshing" the layout, but none of that worked. Very bizarre.)
After file-load, try changing the style's background color. It doesn't affect the highlight color. So somehow the direct formatting has acquired a copy of the style's highlight? Or is this autostyle related?
repro 24.2+
Let's try with https://gerrit.libreoffice.org/c/core/+/154082 .
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/619ac8bbb31a62087ac1e3745cc28b461bfb49c0 tdf#126382 Correct check for transparency It will be available in 24.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.
I assume this is fixed.
I confirm attachment https://bugs.documentfoundation.org/attachment.cgi?id=152759 loads as expected in: Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 4; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE 24.2.5-2 Calc: threaded but shows the issue of this report in: Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: 60(Build:2) CPU threads: 4; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE 7.6.7-1 Calc: threaded so from my part this is fixed. Thank You all for that! :-) Closing. Reopen if still alive elsewhere