Created attachment 143655 [details] Expected display at step 6. In order to reproduce the bug: [1] Create a new text document and open sidebar with Styles (F11). [2] At the top of the list select Paragraph Styles. [3] Open a Modify dialogue of a paragraph style: Right click on a style and select Modify… [4] Select tab 'Font Effects' and choose font colour White. [5] Select tab Highlighting and select black. Then OK. [6] Now sometimes the focus (highlighted with blue, white font) jumps to a different style, sometimes it is still on the changed style. In the latter click on another style. The changed font is now displayed white on white, that means it is invisible. Expected: Display font white on black background (only for the letters, see also attachment). [7] Open modify dialogue of same style again: Right click on same (= invisible) style and select Modify… [8] Tab Highlighting: Set back highlight colour to Standard. [9] Tab Area: Click button 'Color' and choose Black. Then OK. In this case the display of the style in the list is OK: There is a black bar as background and the font colour is white. See also attachment. The same problem occurs if you change the same preferences of a character style. Bug exists probably since the introduction of previews of styles on the sidebar in version 5.0. It may be possible that the same bug has been discussed in bug 115507. But for me it was not clear which preferences in which styles have been changed there. Hence I wrote this new report.
Created attachment 143656 [details] Display at step 9.
(In reply to Harald Koester from comment #0) > It may be possible that the same bug has been discussed in bug 115507. But > for me it was not clear which preferences in which styles have been changed > there. Hence I wrote this new report. For me it sounds indeed like a duplicate of bug 115507.
Maybe a new chance to get this UX fault fixed. Others like at https://www.dedoimedo.com/computers/libreoffice-styles.html also see a problem in the current behavior.
I would close the ticket as dup of 115507.
I think that the key point is the difference between highlight and background. It works as expected if, font color being set to white, the background is set to black and highlight to none, but not if the background is set to none and the highlight color to black. Bug 115507 is only about background color. Best regards. JBF
Just two arguments: - On the one hand we promote the use of styles as good practice and on the other hand users run into troubles if they use them correctly. I think this does not match and should be avoided if possible. - In the Modify dialogue in some tabs (e.g. tab 'Font') the preview is displayed correctly. Why it should not be possible in the style list?
It is a old regression. I created file with new style, that has white color for font and gray color for highlighting. Then I checked it in 4.2.8 -> Font of style name in list has black color and in 5.2.7.2 -> Font of style name in list has white color and don't shows (because background of list is white too) and this bug repro in master from today
(In reply to kompilainenn from comment #7) > It is a old regression. It was a conscious decision to value WYSIWYG over readability. If the user has white on white or black on black it should be the same on the sidebar.
Checked with versions 4.4.7 and 5.0.0. As I guessed in my initial report, the bug was introduced with version 5.0.0. In versions before there is no WYSIWYG display of the style lists. Hence the problem does not occur in this versions.
Sorry to hijack this issue with a broader preview problem, but this can't be considered without having bug 115507 and the "whole situation" in mind. (In reply to Heiko Tietze from comment #8) > It was a conscious decision to value WYSIWYG over readability. If the user > has white on white or black on black it should be the same on the sidebar. As Buovjaga also said in one of the dupes of bug 115507, it seems like an implementation error. If a preview is implemented, all cases of possible color combinations (font, highlight, background) must be considered and the software MUST handle that automatically in a way that the user can use this software without doing something special (like disabling the style preview in the sidebar). Problem A) in the sidebar is, that a selected style is highlighted by a 'background' color behind the style name. This interferes with a background color chosen by the user. Problem B) in the sidebar is (and that's what this issue originally is about), that highlight color won't be shown in the style preview in the sidebar but only background color. Suggestions: Ad A): Other indication of selection in the styles sidebar than with a background color. Ad B) (that's what this issue originally is about): Add also highlight color to the preview in the styles sidebar. Ad A) + B): Add a mechanism that ensures that the contrast between foreground and background/highlight color always is sufficient. For comparison, MSO Word 2013: * If the font color is white, in the style preview the font will be shown in black because otherwise the user won't see the style name. This is what I mean with "the software must automatically handle that". Regardless what the user does, the style name must be readable. * Hovering effect and selection isn't done by a background color but by a border around the style name. With that nothing must be changed in how the style is previewed because normally the user will choose foreground/background colors so that it's readable--in the page canvas and in the style preview.
And what do you in case of blue for both font and background color? Of course we can twist the user settings but that ends up in some kind of no WYSIWYG preview that is available with the checkbox.
(In reply to Heiko Tietze from comment #11) > And what do you in case of blue for both font and background color? Of > course we can twist the user settings but that ends up in some kind of no > WYSIWYG preview that is available with the checkbox. As I said in the comment before: "... "the software must automatically handle that". Regardless what the user does, the style name must be readable. ...". For me, readability beats 1:1 preview realization. These cases are seldom, so this is manageable and preview means real preview in almost all cases.