Created attachment 139650 [details] Screenshot showing Stylist with all but one style "white on white" Found in 5.3 (windows), but also present in 5.4 (Linux). Most likely much older (see bug 58161): When Creating a document with white letters on black background by changing the font color of the default style to white, the style names in stylist all disappear; if not immediately, they do after clicking on them (see attachment).
I could reprodce this behaviour. But for me it's logical, because it shows the preview of the style. If you disable "show preview" all style names appear. So I can't say what the expected result would be.
(In reply to Dieter Praas from comment #1 on "But for me it's logical(...)") If the style includes just a glyph color, but no background color, it's undetermined what the background should be (even if the page background is set to black in the page style, there are several factors that can change it). So while there's probably no color that guarantees visibility of a specific non-invisible glyph color, the system could be smarter, like using a checker-type background that other applications use to indicate a transparent background. I'm not against more clever solutions, however ;-)
Well, let's check with the design team for good measure. I do confirm the problem.
There is an option to show or not the fonts preview, with it disable all style are visible. So I don't think it's a bug, nothing special to manage the styles is needed.
Pretty sure that this issue has been reported. The right solution is to invert the background if the contrast is below a certain threshold. Shouldn't be too difficult to implement. The plain preview option is a workaround but not a solution for users who permanently work with bright font colors.
Created attachment 140264 [details] Test document with styles having different font and background colors Here is a test document with font color in default, black, and white combined with all 12 gray scales for the background.
Created attachment 140290 [details] Selection issue Tried to solve the issue myself, and it's easy to change the background depending on the color at templdlg.cxx with void StyleLBoxString::Paint() ... rRenderContext.SetDrawMode( DrawModeFlags::BlackFill ); Though I couldn't figure out how to access the font color of the current style, perhaps something like SfxItemSet& pItemSet = pStyleSheet->GetItemSet(); SfxPoolItem& pItem = pItemSet.GetItem( SID_ATTR_CHAR_COLOR_EXT ); But actually I tend to agree with m.a.riosv to keep it full WYSIWYG (comment 4) since using a white font on white background (or vice versa) has been done intentionally by the user. The alternative is to highlight the selection like for default styles (such as Test 1 with automatic and none colors). In case of automatic font color it's adjusted in the sidebar too but apparently with a different formula as shown in the attachment. Test 2 in the document is black while it's contrast seems to be calculated as enough for white in the sidebar. To summarize: My suggestion would be to always highlight the selection in the system color.
Similar issue for the toolbar dropdown was solved partially in bug 58161. (light gray on white but black on black).
(In reply to Heiko Tietze from comment #7) [...] > 4) since using a white font on white background (or vice versa) has been > done intentionally by the user. The alternative is to highlight the [...] If you read comment 0 again, you will find that the user created a white font on a black background, not "white on white" as you claim. Also, as pointed out in comment 2, the assumption that the color of paper is white may be wrong. On some printers that can feature a page watermark on the background, you clearly see where writer keeps the "transparent page background" (where the watermark "shined through" and where it fills the area with white (Where "paper without watermark shined through"). Also pointed out in the same comment, there was a proposal for assuming a transparent background (unless the page fill color is explicitly set), and reflecting that in the background of the style preview.
This is an old known bug, see Bug 94397.
*** Bug 94397 has been marked as a duplicate of this bug. ***
*** Bug 116229 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #7) > But actually I tend to agree with m.a.riosv to keep it full WYSIWYG (comment > 4) since using a white font on white background (or vice versa) has been > done intentionally by the user. The alternative is to highlight the > selection like for default styles (such as Test 1 with automatic and none > colors). I think the current situation is very bad UX. As a user I assume: 1) The "Show Preview" command for paragraph and character styles shows several visual attributes of the style (all attributes of Font, 'Font Effect', Highlight and Area tabs, maybe attributes from 'Indents & Spacing' tab like in MSO and Position, Transparency and Borders tabs) to see what it changes if assigned to text. This isn't true today as it only shows font style and font color attributes. More? 2) If only some attributes are changed (for example light grey font color but no background color change) then the NOT changed attributes (here: background color) should be inverted to a value that the user can see his font color with enough contrast as Heiko said in comment 5. This isn't implemented yet. 3) For the user, it should always be clear what style is currently selected at the page and what style was clicked by the user in the Styles sidebar. This is true today but should be kept in mind when implementing 2). Deactivating "Show Preview" is no solution for this issue.
(In reply to Thomas Lendo from comment #13) > ...... > 2) If only some attributes are changed (for example light grey font color > but no background color change) then the NOT changed attributes (here: > background color) should be inverted to a value that the user can see his > font color with enough contrast as Heiko said in comment 5. > 'Inverted' it's not show what the user does, seems to me a clear contradiction about what is requested.
(In reply to m.a.riosv from comment #14) > 'Inverted' it's not show what the user does, seems to me a clear > contradiction about what is requested. The point is: We need contrast in showing bright font colors with no background color in the style assigned. This is a realistic szenario if maybe the page background has a dark color. Showing white font on transparent/white background is bad UX. Also we need more contrast in case of bug 94397 (and I think it's not a dupe of this) when the highlighting of LibO results in too few contrast in sidebar or drop-downs.
We talked about the topic in the design meeting. Question is whether we want to provide a full WYSIWYG preview. And we show only a few properties and do not provide a full preview. One idea is to show the selection independently from the style (could also be done on hover like happening in the dropdown) but there are other settings that intentionally makes the style hardly readable like small font sizes, e.g. the Horizontal Line. So the decision was to accept the situation => WFM.
*** Bug 101700 has been marked as a duplicate of this bug. ***
This problem was also mentioned at https://www.dedoimedo.com/computers/libreoffice-styles.html and I hope it will be fixed sometime. For me, nothing must be changed in handling of wysiwyg preview. Only a minimum contrast value should be introduced to keep the style name readable.
*** Bug 113243 has been marked as a duplicate of this bug. ***
*** Bug 148202 has been marked as a duplicate of this bug. ***
Created attachment 184849 [details] Screenshot of paragraph style with white background and black font in Windows dark mode Now with the new dark mode functionality, the implementation of showing styles in the sidebar effects also styles that have a white or bright background (and "automatic" aka black font color). The LibreOffice dark mode changes all font colors into white so that it's shown with white font color on white background color. See the attached screenshot.
Set issue back to NEW to hopefully start new discussion. Some contrast is needed if "user decision" [font/background] color is too similar to "system decision" [font/background] color.
The problem of not using the document background color in the Stylist is handled in bug 137705. Back to resolved/WFM.