Created attachment 159227 [details]
Example file showing problem

I assume, your talking about "Highlight Colour" (you call it background colour) and "Text Colour" (you call it foreground colour).

I agree, that actual behaviour is inconsistent.

Version: 7.0.0.0.alpha0+ (x64)
Build ID: 1c9ced04189c9d23ffea05d5570960b54b05ef28
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: CL

cc: Design Team for defining desired result

(In reply to foo from comment #0)
> 3. Set foreground colour to WHITE

Why are you surprised that white on white is not visible?

(In reply to foo from comment #0)
> Expected Results:
> Number should remain either as original black-on-white or take on the (red)
> BACKGROUND colour selected for the paragraph.

What if you want to highlight only the list content, what I expect is the default?

Solution to your problem is a special character style maybe derived from "Numbering Symbols" where you define a highlighting color. And use this character style at the list style respectively Bullets & Numbering > Customize > Character Style.

It's cumbersome, yes, but a very special use case and I don't think we need to change anything. => WFM

> Why are you surprised that white on white is not visible?

I wasn't. I was surprised it had only done half of what it should (or had done anything at all).

> What if you want to highlight only the list content, what I expect is the default?

This is what I wanted!

I hadn't selected the number, I had selected the text in the body of the item - - which is what I'd wanted to colour differently. But, having coloured the whole line, the Text/Font colour was imposed on the List Number while the Highlight Colour was not and I couldn't find an obvious way to either get it to do both or neither.

This bug is an excellent example of a more general problem with lists. Sometimes formatting of the list contents bleeds over into the number/bullet, other times it doesn't, and the user has no control over this. See, for example, bug 99330.

(In reply to Kenneth Hanson from comment #5)
> ...the user has no control over this

Please read comment 3 on how to change the list number/bullet color.

(In reply to Heiko Tietze from comment #6)
> (In reply to Kenneth Hanson from comment #5)
> > ...the user has no control over this
> 
> Please read comment 3 on how to change the list number/bullet color.

This is not a solution. It is an abuse of the style system.

It requires a proliferation of list styles for every combination of meaningful list type crossed with every character style whose formatting bleeds over. It requires all such styles to be manually kept in sync should their properties need to be changed. It requires a different style to be used for different items of the same list, and for these to be changed when the content changes. In short, it completely defeats the use of styles.

The problems go far beyond the example in this bug. For serious documents, extensive character formatting is basically unusable at present.

It also defeats the use of manual formatting, since redundant character and list styles must be created for every instance.

Finally, it is unreasonable to expect novice users to be have to do this, whether they use styles or manually formatting.

I'd like to focus the discussion back to the original bug report. Heiko, I'm still missing an explanation, why Font Color and Highlight Color behaves different and why should that be the expected result.

No explanation to the why, guess because of the list style connected to a character style. Let's just change the highlighting color as it is done for the font color. 

needsDevEval if this can be realized

(In reply to Heiko Tietze from comment #9)
> No explanation to the why, guess because of the list style connected to a
> character style. Let's just change the highlighting color as it is done for
> the font color. 
> 
> needsDevEval if this can be realized

needsDevAdvice.

needsDevEval is for potential easy hacks

There may be compatibility with MS Word implications with this (although I don't think it is true in the situation described here.) In any case, anyone fixing this bug should test that saving to DOC and DOCX formats works as expected.  (There are situations where Word ignores w:shd in relation to numbering.)

Already happens in bibisect-43all with LO 3.5. Probably inherit from OOo.

This sounds so much like bug 114799, but none of that code has any impact here. 
However, avoiding UNDERLINE is here.

Ahh, here it is. It is the same SetDiffFnt issue as DOCX faced.
txtfld.cxx's SwTextFormatter::NewNumberPortion

    // Apply the explicit attributes from the character style
    // associated with the numbering to the new bullet font.
    if( pFormat )
+   {
+   // SetDiffFnt resets the background color (why?),
+   // so capture it and re-apply if it had a non-overridden value,.
+       const std::optional<Color> oFontBackColor = pNumFnt->GetBackColor();
        pNumFnt->SetDiffFnt( pFormat, pIDSA );
+       if (oFontBackColor && !pFormat->HasItem(RES_CHRATR_BACKGROUND))
+           pNumFnt->SetBackColor(oFontBackColor);
+   }

The background is lost when there is a character format assigned to the numbering. So, if you use a numbering style, but set its character style to NONE, then highlighting applies. [eg. attachment 165456 [details] from bug 136718]

So then, either comment 12's patch should apply (making something incompatible with MS Formats), or else BackColor should always be cleared (which would also cause this bug to happen in the no-character-style case as well). Yuck.

repro 24.8. MS Word looks the same as LO for a round-tripped colours testRT.docx