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 188.8.131.52, also LO 184.108.40.206 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.
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
CONFIRMED on Ubuntu 18.04 LTS and LibreOffice 220.127.116.11
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 18.104.22.168
> Version: 22.214.171.124
> 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?
d09c5defb702f63eabd460d81f2e9434866f3b24 is the first bad commit
Author: Matthew Francis <firstname.lastname@example.org>
Date: Sat Mar 14 23:38:09 2015 +0800
Author: Kohei Yoshida <email@example.com>
AuthorDate: Tue Jul 22 15:25:27 2014 -0400
Commit: Kohei Yoshida <firstname.lastname@example.org>
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.
> 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?
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":
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:
Affected users are encouraged to test the fix and report feedback.
I assume this is fixed.