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)
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
Dear foo, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present although the default behaviour is significantly improved. When setting the background colour, a contrast check appears to have been introduced to change the foreground colour to white in some circumstances. However if the user manually sets the foreground colour to something (eg grey or yellow) then this foreground colour is *also* applied to List Number where the background colour is not (as before). Version: 26.2.3.2 (AARCH64) Build ID: 70e089b17412e4cb7773e41413306b17a2328c34 CPU threads: 12; OS: macOS 26.5; UI render: Skia/Metal; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 207323 [details] Updated screenshot of bug Bug manifests at what would be item 3
Moderate amend to previous comment - the contrast detection appears to apply when the foreground color is set to Automatic only. If the foreground color is *set* to White then it still applies to the list item. Updated screenshot attached