When switching back and forth between dark and light mode, an annoying problem is that the thumbnails are not compatible with the application color settings. If the application color is light, then the thumbnails will be light, even if you switch the application color. A solution for this problem would be storing both dark and light versions of the thumbnails, and use them when appropriate.
Note that: 1. There is a thumbnail inside the ODF package. If this is implemented, it likely needs a second copy there, too? 2. The space requirement for usermodifications.xcu would double (the base64 haches of the thumbnails there take most of the space), and given how fragile our user profile is (we often recommend resetting it because of corruption), this would likely increase different problems; 3. The time requirement would increase - the rendering would need to happen twice, once for light theme, once for dark. 4. Not sure how would that work with customized theme - if user changes specific colors of their dark mode, would it still be readable? In theory, this is just a dupe of tdf#148282; however, it was worded as "I know the solution, do XYZ", so is not open to discussion of ways to fix this. Note that, despite I disagree that storing two thumbnails is OK, it could give better visual results compared to what I suggested in tdf#148282 - using transparency. At this time, as I don't really see a viable solution, my idea is: WF.
Thank you both. I'm going ahead and closing as "duplicate" as it is discussed there as one possible way forward. Better have a single discussion there, and keep this report linked as another case of a contributor seeing the current solution as not ideal. (And to reply to what is suggested here: I think we should stick to a thumbnail that matches the print preview. A "dark mode version" of a document is to me an unattainable target because of automatic vs static colours. However we define such a version of the document, there will be cases where parts will be unreadable.) *** This bug has been marked as a duplicate of bug 148282 ***