Suppose I'm working on a document which I intend to export. In this document, I use different fonts to convey some sort of meaning, or as a form of styling, and my fonts have different levels of lightness: I have red and blue and green, but also dark gray, and deep brown, and dark blue; all still quite usable and discernable on a white background - which is what I get if I print or export to PDF. Now, suppose I run LibreOffice in Dark Mode, and with the document background also dark. This would make my dark colors almost invisible against the background. And while with "regular" documents, I could just set the text color to automatic and be done with it, in my example - I cannot. Nor can I change the color scheme to somerthing else, since that would mess up the coloring during export, where the background is white again. You could say: "It's your problem, you chose to make it that way etc." - but it's not so simple: * Maybe this happened to me when I upgraded. * Maybe it was fine with the documents I work on, then somebody else sent me the document with the dark colors? * Maybe it's the default when I install LO. In these situations, we are in a bit of a problem. We again could just rely on the user, but I am wondering if we should not make some suggestion on switching at least the document background. Or perhaps, let the choice of document background be part of the settings saved with the document. ---------------- Note: This bug was motivated by the following rant: https://www.reddit.com/r/libreoffice/comments/1l2vepo/which_200_iq_developer_came_up_with_this_genius_ux/ which can be resolved by not insisting on black text color.
(In reply to Eyal Rozenberg from comment #0) > Note: This bug was motivated by the following rant: > > https://www.reddit.com/r/libreoffice/comments/1l2vepo/ > which_200_iq_developer_came_up_with_this_genius_ux/ > > which can be resolved by not insisting on black text color. Some of the greatest hits from that thread: "This is a LO mindset problem. Don't assume that the average user has always the most rational or default settings. Boomer-Betsy, the secretary, clicked on every setting available to make sure the Excel file is the way she wants it." "This is sort of shit that generates massive amount of calls to the IT admin that sorts out such problems for boomers having no idea how to fix it. Do not force opt-in updates like that. This is a Libre problem. I'm talking in behalf of my friend that has enough of it. I demanded myself Office licence because I can't stand bullshit anymore. I tried to be OS friendly but Libre is not my friend. Do not force feed users update in such way." "Nah, it's better to just comply to what the OS is set to, as by now basically everywhere you can set dark or light mode system-wide. That being said, not only shouldn't they have rolled out the drak theme is this horribly broken state, but how tf is there not a really simple way to use dark mode with white working space?" "I also have to agree: We run multiple Fedora machines and after an update earlier this year, every LibreOffice install showed this behaviour, and worst of all: also for new documents. I am a huge LibeOffice fan, but I was baffled that this wasn’t tested for (our that we collective ran into some weird config) as this lead to a lot of user frustration."
But isn't this the roll of our 'Print preview' feature, to isolate any UI appearance settings from actual export/print WYSIWYG layout? As a final sanity check of the document content. If it is wrong in the preview, *that* is the indicator to user that they've got formatting issues and need to revisit. Otherwise they should adjust their UI appearance (apply os/DE provided Automatic, Dark, Light; or apply a revised Appearance theme). As folks transition releases, they'll find what they like and works for them and then stick with it. We just need to coach them on their options through Help, the GS and module specific guides, supplemented with feedback on Ask and project blogs.
I think that if we were able to check colours how they look originally in the light theme (which could be done by the Print Previw feature in theory), I'd be totally satisfied with how we can work with our theme set to dark. I think it's a good solution that either you work with the original appearence of your document in a light them and your colours look normal, or you work in dark theme for the health of your eyes, and you have to check colours in light theme repeatedly. Most important is that the primary font yolour (automatic) should be adapted to the theme. (An other solution would be that the app inverts colours having low contrast, but you still have to check how they look originally on white background, so that does not reduce your job.) ## My problem is that currently, exporting and printing does not handle colours well in dark theme: * both in the preview shown in the print dialogue and in the Ctrl+Shift+O Print Preview Math Formulea are invisible since they have automatic white font colour (I have to set the colour of the formulea to black by command in order to override that) See: https://bugs.documentfoundation.org/show_bug.cgi?id=167773 * exporting PDF files from Draw has a dark background which they inherited from the dark theme's document background colour
Andras: you have assigned this report to yourself. Does this mean you intend to submit a patch in Gerrit for it?
(In reply to Buovjaga from comment #4) > Andras: you have assigned this report to yourself. Does this mean you intend > to submit a patch in Gerrit for it? Oh, not at all, sorry. I was playing with the idea to find the problem myself, but I couldn't even figure out the code infrastructure not mentioning the fact I'm totally unfamiliar with makefiles and real C(++) programming. I just wanted to follow the discussion and reach from the "My Bugs" page, so thought this would be a good way of achieving it, but of course it means more than that. Thank you for warning me.
(In reply to V Stuart Foote from comment #2) > But isn't this the roll of our 'Print preview' feature, to isolate any UI > appearance settings from actual export/print WYSIWYG layout? As a final > sanity check of the document content. I think you misunderstand what I meant with this report. The point is the situation in which a document will either look ok when exported but be difficult to edit, or be easy to edit but possibly look bad when exported. It's true that in the second case, 'print preview' will show me that the result of an export would look bad. But that doesn't address the problem, it only makes it a bit easier to notice earlier (in one of the cases).
(In reply to Andras Simon from comment #3) > I think that if we were able to check colours how they look originally in > the light theme (which could be done by the Print Previw feature in theory), > I'd be totally satisfied with how we can work with our theme set to dark. But not everyone feels like you do... the problem exists, and affects some/many users - even if some users can live with it, or don't mind it. Also, would you really be satisfied with receiving documents like the one buovjaga linked to? Opening a spreadsheet just to see black-on-black text?
Users may force a black font color without knowing the consequences for dark backgrounds - or with the intention to hide parts of the text. I recommend to not override manual setting.
(In reply to Heiko Tietze from comment #8) > I recommend to not override manual setting. I did not suggest overriding manual settings. The question is, what _can_ we do to mitigate this problem - which does occur in practice now that we have users who run light mode and user who run in dark mode. > Users may force a black font color without knowing the consequences for dark > backgrounds - or with the intention to hide parts of the text. Well, the second scenario is a user error, of course. So, how do we help users avoid mistakenly using black color, or white color, to hide text? My initial question also regards other dark/very-light colors, but even regarding black and white, you've just described a scenario which users may need some help in avoiding.
(In reply to Eyal Rozenberg from comment #9) > I did not suggest overriding manual settings... > how do we help users avoid mistakenly using <...> color "Thou shalt not do..." sounds like patronizing. And "mitigating" like overriding. => RTFM aka NAB/WF (and don't abuse Writer for other than text editing, "Parents are responsible for their children")
(In reply to Heiko Tietze from comment #10) > => RTFM 1. How will the user who _receives_ the file with dark colors benefit from reading the manual? 2. What _does_ the manual say about this matter, that would help the author of such a document? > aka NAB/WF (and don't abuse Writer for other than text editing, This bug is about documents (in Calc, or Writer, etc) in which some of the text is set to have dark color while edited in light mode, and then opened in dark mode; or set to have very light colors while edited dark mode, and then opened in light mode. Where is the abuse?
We discussed the topic in the design meeting. There are many scenarios where low contrast could be done intentionally like questions and answers where the latter should not be visible on the printout. The print preview works well for this purpose although it is not shown on print/export directly. The good news is that low contrast is part of the accessibility check and raises a warning. We could raise attention to this feature by showing an infobar on the print/export dialog or a message box for direct operations.
(In reply to Heiko Tietze from comment #12) And it was said in the meeting that this suggestion, even if it might help, would not fix this bug - not even for the case of exporting or printing, let alone for the case of saving (or the less-frequent case of copying and pasting). So, we definitely did not agree to limit the bug to this warning. Additionally - while it's not a bad idea to warn: * The warning has to clarify that not just visually-impaired users would be impacted, but also users who use the opposite 'mode' (i.e. dark if the colors only agree with light mode and vice versa). * The warning does not in itself help the user resolve the problem. Anyway, in the design meeting, additional ideas were put on the table, e.g.: * Allowing, and perhaps encouraging, users to set colors relative to the text color, or default text color, and background color (e.g. "20% of the way between the text and the background") - so that the interpretation would depend on the lightness mode. * Flipping colors according to the different mode - not a fully-fleshed-out idea and I also said that I don't have something I could really put forward as a solid solution.