Bug 131785 - LIST NUMBER: Different behaviour when using Font Colour and Highlight Colour
Summary: LIST NUMBER: Different behaviour when using Font Colour and Highlight Colour
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2020-04-01 13:11 UTC by foo
Modified: 2024-05-31 16:06 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file showing problem (10.48 KB, application/vnd.oasis.opendocument.text)
2020-04-01 13:12 UTC, foo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description foo 2020-04-01 13:11:40 UTC
Description:
When wanting to colour a block of text in a list background=RED with foreground=WHITE, the list number takes on the FOREGROUND colour but not the BACKGROUND colour. 

In the normal case, this results in the text disappearing (WHITE on WHITE).


Steps to Reproduce:
1. Create new list with items
2. Select a line, set background colour to RED
3. Set foreground colour to WHITE

Actual Results:
Number (from automatic list) disapepars

Expected Results:
Number should remain either as original black-on-white or take on the (red) BACKGROUND colour selected for the paragraph.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
The number disappears (white on white)
Comment 1 foo 2020-04-01 13:12:57 UTC
Created attachment 159227 [details]
Example file showing problem
Comment 2 Dieter 2020-04-02 06:41:59 UTC
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
Comment 3 Heiko Tietze 2020-04-02 10:32:51 UTC
(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
Comment 4 foo 2020-04-02 10:44:37 UTC
> 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.
Comment 5 Kenneth Hanson 2020-04-02 16:52:39 UTC
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.
Comment 6 Heiko Tietze 2020-04-03 09:45:04 UTC
(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.
Comment 7 Kenneth Hanson 2020-04-07 21:32:15 UTC
(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.
Comment 8 Dieter 2020-04-08 09:36:37 UTC
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.
Comment 9 Heiko Tietze 2020-04-09 12:39:38 UTC
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
Comment 10 Buovjaga 2020-04-09 12:44:40 UTC
(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
Comment 11 Justin L 2021-05-01 10:05:01 UTC
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.)
Comment 12 Justin L 2021-05-05 07:16:37 UTC
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);
+   }
Comment 13 Justin L 2021-05-05 10:31:49 UTC
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.
Comment 14 Justin L 2024-05-31 16:06:36 UTC
repro 24.8. MS Word looks the same as LO for a round-tripped colours testRT.docx