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

(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.