Created attachment 169771 [details] UI problems with dark theme Can't see text in table styles dialog. See attached image for more info.
Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: a0c689e1ad98bf3c47d189b8cc99c9f4bcc41a12 CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-02-06_03:44:29 Calc: threaded Operating System: Manjaro Linux KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.4.95-1-MANJARO OS Type: 64-bit
Thank you for reporting the bug. I can not reproduce the bug in Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nb-NO (en_US); UI: en-US Calc: CL Version: 7.2.0.0.alpha0+ (x64) Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to mulla.tasanim from comment #2) > Thank you for reporting the bug. The problem exists on Linux (Manjaro KDE) and not Windows. Windows has no real global dark theme. For now the problem is still persistent with : Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 06c3eafce490fbfb8f8c477cb8dfe7f83e1fca9c CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-02-28_18:17:47 Calc: threaded Operating System: Manjaro Linux KDE Plasma Version: 5.21.2 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.4.101-1-MANJARO OS Type: 64-bit
Can confirm this as well in latest Master build with Dark mode on in Windows 10.
If not possible to make it white on dark background at least do it dark on white background.
The TS take attributes from a binary file (bug 49437) and we cannot just drop the font color. You have to untick it manually to get Automatic in both, the autoformat dialog as well as the document itself. Alternatively you could create another TS. So in a nutshell: the dialog works well but the TS definition includes inappropriate values. Same issue as in bug 121023 (and probably many other too). *** This bug has been marked as a duplicate of bug 121023 ***
(In reply to Heiko Tietze from comment #6) > we cannot just drop the font color. Why would we need current document font color in preview table ? that table has no relation to what user has chosen in current typed document, it's just a simple table that shows examples. Either force the preview foreground color to white to match global dark theme, or use current document white background like how font foreground is used.
What you see in the preview of the autoformat dialog is what you get in the document. If the TS has defined to use black font color it will be black on what you define as document canvas color. The color "Automatic" is supposed to be either white or black depending on the brightness, however. The TS have obviously been set with black font color (not sure if Automatic would be an option here). As long the file format for TS is binary we cannot teak the TS to not set any font color/name etc. As commented before, the dialog works as expected. And the issue is just one aspect of a unfinished implementation. => DUP
(In reply to Heiko Tietze from comment #8) > What you see in the preview of the autoformat dialog is what you get in the > document. If the TS has defined to use black font color it will be black on > what you define as document canvas color. > > The color "Automatic" is supposed to be either white or black depending on > the brightness, however. The TS have obviously been set with black font > color (not sure if Automatic would be an option here). > > As long the file format for TS is binary we cannot teak the TS to not set > any font color/name etc. > > As commented before, the dialog works as expected. And the issue is just one > aspect of a unfinished implementation. => DUP Thanks, now I understand the issue, what would be right is to apply both document foreground and background colors to table preview, but I tested (with current 7.4.0.0alpha) by changing both document foreground and background and they are not used by preview, see new attached image.
Created attachment 179048 [details] Wrong background and foreground colors in table styles preview
Please make sure to define a table style (use Add in this dialog or New from Selection in the Stylist- though not sure this TS will be known immediately in the Autoformat dialog). Direct formatting wont overwrite the Default TS nor show up in the preview.
(In reply to Heiko Tietze from comment #11) > Please make sure to define a table style (use Add in this dialog or New from > Selection in the Stylist- though not sure this TS will be known immediately > in the Autoformat dialog). Direct formatting wont overwrite the Default TS > nor show up in the preview. It seems totally weird and not logical at all to have table style preview foreground and background colors dependent on some non existant page style, instead it should work at least with any default empty page without needing any customized page style. I tested it with a new customized page style and it still doesn't work for me.
Created attachment 179060 [details] customized page style
Didn't say page style. The background color of the preview takes the value from tools > options > application colors > document background... oups, it does not. But since you run a dark theme it doesn't matter. The point is that your _table style_ uses black font color (on a dark document canvas). Will look into the problem with the background.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5b2238ce779c44378f0a86e498eda39f50df3542 Resolves tdf#140439 - AutoFormat Table preview not using DOCCOLOR It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 149285 has been marked as a duplicate of this bug. ***