Bug 115507 - Style names become invisible if the default style used white color
Summary: Style names become invisible if the default style used white color
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 94397 101700 113243 116229 (view as bug list)
Depends on:
Blocks: Sidebar-Styles
  Show dependency treegraph
 
Reported: 2018-02-07 07:41 UTC by Ulrich Windl
Modified: 2018-11-07 09:17 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing Stylist with all but one style "white on white" (18.58 KB, image/png)
2018-02-07 07:41 UTC, Ulrich Windl
Details
Test document with styles having different font and background colors (17.24 KB, application/vnd.oasis.opendocument.text)
2018-03-01 16:51 UTC, Heiko Tietze
Details
Selection issue (9.59 KB, image/png)
2018-03-02 13:01 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2018-02-07 07:41:40 UTC
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).
Comment 1 Dieter 2018-02-07 12:36:50 UTC
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.
Comment 2 Ulrich Windl 2018-02-07 13:16:10 UTC
(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 ;-)
Comment 3 Buovjaga 2018-02-26 19:58:34 UTC
Well, let's check with the design team for good measure.
I do confirm the problem.
Comment 4 m.a.riosv 2018-02-26 21:34:02 UTC
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.
Comment 5 Heiko Tietze 2018-02-27 08:44:11 UTC
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.
Comment 6 Heiko Tietze 2018-03-01 16:51:09 UTC
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.
Comment 7 Heiko Tietze 2018-03-02 13:01:01 UTC
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.
Comment 8 Heiko Tietze 2018-03-02 13:37:44 UTC
Similar issue for the toolbar dropdown was solved partially in bug 58161. (light gray on white but black on black).
Comment 9 Ulrich Windl 2018-03-05 07:44:05 UTC
(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.
Comment 10 Thomas Lendo 2018-03-05 19:47:56 UTC
This is an old known bug, see Bug 94397.
Comment 11 Buovjaga 2018-03-06 06:59:12 UTC
*** Bug 94397 has been marked as a duplicate of this bug. ***
Comment 12 Dieter 2018-03-06 10:41:39 UTC
*** Bug 116229 has been marked as a duplicate of this bug. ***
Comment 13 Thomas Lendo 2018-03-11 22:14:20 UTC
(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.
Comment 14 m.a.riosv 2018-03-11 23:44:31 UTC
(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.
Comment 15 Thomas Lendo 2018-03-12 05:38:17 UTC
(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.
Comment 16 Heiko Tietze 2018-04-11 19:23:24 UTC
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.
Comment 17 Buovjaga 2018-04-11 22:41:35 UTC
*** Bug 101700 has been marked as a duplicate of this bug. ***
Comment 18 Thomas Lendo 2018-07-07 21:04:54 UTC
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.
Comment 19 Thomas Lendo 2018-11-07 09:17:30 UTC
*** Bug 113243 has been marked as a duplicate of this bug. ***