Created attachment 153397 [details] first picture: some depressed and some undepressed buttons in LibreOfficeWriter. This bug report pertains to Version: 6.4.0.0.alpha0+ Build-ID: 9ee5ad5a0b84bfa652da34694ba4f75668f06087 CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-07-30_13:21:44 Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded running on Xubuntu 16.04 and as well on 18.04. I tried windows manager’s theme „Hoher Kontrast“ (probably it is called High Contrast in an English version). However, using it in connection with LibreOffice, the buttons which have a permanent on/off state become almost unreadable when they are activated. When depressed, LibreOffice's buttons are flooded with dark color. Since the key caps inscription is in dark grey, they become almost unreadable then. Try it out e.g. with bold, italic, underlined, … as shown in my first picture. First I thought this is a problem of xfwm4, the window manager of xfce4 and I reported a bug at https://bugzilla.xfce.org/show_bug.cgi?id=15826. However I was told, xfwm4 has nothing to do with how the applications draw their own widgets. I should report the bug at the make of the application instead. If one would just invert the color of the pressed key, the on and off states for bold/italic/underlined/subscripted/superscripted…. would clearly be recognized in one or the other state and this would work in any a windows manager settings as shown in my second picture. Instead of inverting, one might do a little better by inverting the button using a negatively bent brightness curve as shown in my third picture.
Created attachment 153398 [details] second picture: original undepressed keys, inverted and proposed special inverted display
Created attachment 153399 [details] third picture: The color transformation curve used in Gimp for a special inversion for the depressed states The bent curve is the inversion applied in the third row (this has been done in GIMP). This one shows the added items more clearly. In the pressed state, a button should best be shown in such a special inversion mode. This can be done by applying a proper look up table for the pixle colors.
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Unfortunately the appearance is not really pleasant under the high contrast theme in Version: 7.0.0.0.alpha0+ Build ID: 48295aead3e15c62d31157f963bd5728f7278db5 CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-02-29_21:13:36 Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded It could easily be done better (and the method to invert the appearance of a depressed button is probably the easiest thing to implement since the inverting operation applied an even number of times returns to where it left off). But it could be made even nicer with a similar approach as in the attached document, but that is not inverse to itself. One would have to keep a copy of the bitmap of the pressed button to re-establish if a pressed button gets reverted to unpressed. BTW: I don’t like it that pictures pasted are now by default anchored to the character. I know, it has been an endless discussion between 2014 and 2019 under Bug 79234, Bug 87720. Bug 99646 e.g. requested to make the default anchor “to character”, however I don’t like it that way, I just like placing pictures anchored to paragraph by default. I had to manually anchor each picture in this document to the paragraph to really get what I want. I’d still advocate to make the default anchoring to be configurable (at least for new documents). A good place would be in Frame Styles:Graphics under the tab Wrap. It leaves enough space place buttons letting one to select between anchor to page/paragraph/character and since this would be in the style sheet aka template, every LO user could set it to his/her personal preferences. However, there seem to be some pagination and image placement bugs which are/were(?) buried deep in LO and even in OOO.
Created attachment 158291 [details] Attachment mentioned in comment #4
(In reply to Adalbert Hanßen from comment #4) > BTW: I don’t like it that pictures pasted are now by default anchored to the > character. I know, it has been an endless discussion between 2014 and 2019 > under Bug 79234, Bug 87720. Bug 99646 e.g. requested to make the default > anchor “to character”, however I don’t like it that way, I just like placing > pictures anchored to paragraph by default. Adalbert, please don't mix diferent topics in one bug report. Thank you.
(In reply to Adalbert Hanßen from comment #0) > I tried windows manager’s theme „Hoher Kontrast“ (probably it is called High > Contrast in an English version). However, using it in connection with > LibreOffice, the buttons which have a permanent on/off state become almost > unreadable when they are activated. Does it happen with every icon theme? There are some bug reports about high contrast. Have you checked for duplicates or relationships?
Meanwhile I tried it in the two versions currently installed on my system: First: The appearance of the tool buttons of LO Writer has changed between version 6.0.7.3 and LibreOfficeDev 7.0.0.0.alpha0+ (2020-03-13_16:53:06): In general the pressed/depressed state in the development version is better distinguishable than in LO Writer version 6.0.7.3. The appearance of LO’s butons seems to be almost independent from the theme chosen for xfce4 with two exceptions for the development version: Adwaita-dark changes everything and the inscriptions on the tool buttons are poorly legible. The difference between the depressed and the non depressed state is distinguishable, but it could be done better. In the High contrast theme, the pressed and the unpressed states of LO’s tool buttons are easily distinguishable, but the button inscriptions are poorly legible. Which possible duplicate do you mean? Before my original post, I searched for similar postings bud did not encounter any.
Adalbert, since LO 7.0 is the fresh version now, could you please retest with the actual version from https://www.libreoffice.org/download/libreoffice-fresh/ ? For possible duplicate check bug 107921. => NEEDINFO
Created attachment 165999 [details] file with screenshots under high contrast, also with a technically more detailed version of an improvement. (In reply to Dieter from comment #9) > Adalbert, since LO 7.0 is the fresh version now, could you please retest > with the actual version from > https://www.libreoffice.org/download/libreoffice-fresh/ ? For possible > duplicate check bug 107921. > > => NEEDINFO Dieter, I have this newer version installed and I checked it with this one instead of 7.0 for which you asked me: Version: 7.1.0.0.alpha0+ Build ID: f8474367449a1b6b54918d2753e3a36798761839 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-GB TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-09-19_02:46:03 Calc: threaded Since the bug is still present in this version, it most probably will also be present in 7.0. See the screenshots in my attached file which also shows how the bug could easily be mended. According to what I was told when I first reported the bug to the Xubuntu maintainers, the buttons are drawn with features from the application, not with features from the screen settings. Therefore I already had shown a general approach which works for any appearance settings by a (simple) inversion and I also set out an enhanced version with another grey value transformation. In the attached document I also provide you with a color value transformation function which would do the job for the enhanced version which I proposed earlier. One note however: If one toggles a tool key several times, one should apply my inversion function only for the transition unpressed -> pressed. If one would apply it over and over again (i.e. also for presses -> unpressed, one would change the appearance of the pressed or the unpressed states. So for unpressed, reconstruct the toolbar button appearance as in its initial state. The bug 107921 report most probably addresses the same flaw, but it does it for the Windows environment. My proposed solution would solve that too.
[Automated Action] NeedInfo-To-Unconfirmed
It looks exactly the same in this version (the one of yesterday): Version: 7.1.0.0.alpha0+ Build ID: 4c5ffaf2ae8cd08a6d24bf674d203659e59f049f CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-GB TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-10-02_09:19:38 Calc: threaded
repro in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c5ca46e75e28ba4245d8544ca53c71fea87d1bbd CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-US (ru_RU); UI: en-US Calc: CL
Created attachment 173861 [details] in highcontrast theme some symbols are barely visible
Could you please try version 7.5 and tell us if issues remain, as dark themes and high contrast support have greatly improved: https://wiki.documentfoundation.org/ReleaseNotes/7.5#GUI With GNOME's high contrast mode, I can't see issues. Thank you!(In reply to Dmitriy Siushkin from comment #13) > repro in > > Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: c5ca46e75e28ba4245d8544ca53c71fea87d1bbd > CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: > win > Locale: en-US (ru_RU); UI: en-US > Calc: CL Dmitriy, this report is about Linux. If you still see issues on Windows in version 7.5, please open a new bug report. Thank you!
Dear Adalbert Hanßen, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Created attachment 188022 [details] comparison old and new state, one minor item still to be improved (In reply to QA Administrators from comment #16) > Dear Adalbert Hanßen, > > This bug has been in NEEDINFO status with no change for at least > 6 months. Please provide the requested information as soon as > possible and mark the bug as UNCONFIRMED. Due to regular bug > tracker maintenance, if the bug is still in NEEDINFO status with > no change in 30 days the QA team will close the bug as INSUFFICIENTDATA > due to lack of needed information. > ... Congratulations. Most of my complaint have successfully been covered. In the attached file you see my last visited state and the state with an almost current development version side by side plus a minor item still to be improved. I just noticed a small improvement to be applied to the Table Toolbar.
(In reply to Adalbert Hanßen from comment #17) > Created attachment 188022 [details] > comparison old and new state, one minor item still to be improved > > (In reply to QA Administrators from comment #16) > > Dear Adalbert Hanßen, > > > > This bug has been in NEEDINFO status with no change for at least > > 6 months. Please provide the requested information as soon as > > possible and mark the bug as UNCONFIRMED. Due to regular bug > > tracker maintenance, if the bug is still in NEEDINFO status with > > no change in 30 days the QA team will close the bug as INSUFFICIENTDATA > > due to lack of needed information. > > ... > > Congratulations. Most of my complaint have successfully been covered. > > In the attached file you see my last visited state and the state with an > almost current development version side by side plus a minor item still to > be improved. > > I just noticed a small improvement to be applied to the Table Toolbar. Quoting from the file: "But the table toolbar could be improved: the red and green highlights for insertion or deletion respectively have become gray. Ok, there are red/green color blind people, but for them there is already a plus or minus sign in the symbols. If red/green color-blind people do not recognize a red coloring in the symbols with the plus sign, then the plus sign still remains, as would be the case with an additional green coloring of the insertion functions." What I see is that the old screenshots are using Colibre theme and the new ones are using Sifr. Do you still get the problems, if you switch to Colibre from Tools - Options - LibreOffice - View?
Created attachment 188977 [details] bug report with screenshots taken with the current development version and LO theme Sifr I have checked the issue as requested with my currently installed development version. No progress has been achieved with respect to the headline "Still one detail to improve". In the attached bug report, I have made one aspect of Table-tools a bit more precise.
(In reply to Adalbert Hanßen from comment #20) > Created attachment 188977 [details] > bug report with screenshots taken with the current development version and > LO theme Sifr > > I have checked the issue as requested with my currently installed > development version. No progress has been achieved with respect to the > headline "Still one detail to improve". > > In the attached bug report, I have made one aspect of Table-tools a bit more > precise. You are again testing with Sifr even though I requested to test with Colibre.
Created attachment 188981 [details] the same test done again, trying with colibre, which might not have been set (In reply to Buovjaga from comment #21) > (In reply to Adalbert Hanßen from comment #20) >... > > You are again testing with Sifr even though I requested to test with Colibre. Buovjaga, sorry for my misunderstanding. I have repeated the test with LibreOfficeDev, but possibly I was unable to use Colibre, see attached bug report. Feel free to log this as a separate bug report, if my suspicion is right, that selecting Colibre instead of Sifr dir not work in my version.
(In reply to Adalbert Hanßen from comment #22) > Created attachment 188981 [details] > the same test done again, trying with colibre, which might not have been set > > (In reply to Buovjaga from comment #21) > > (In reply to Adalbert Hanßen from comment #20) > >... > > > > You are again testing with Sifr even though I requested to test with Colibre. > > > Buovjaga, sorry for my misunderstanding. > > I have repeated the test with LibreOfficeDev, but possibly I was unable to > use Colibre, see attached bug report. Feel free to log this as a separate > bug report, if my suspicion is right, that selecting Colibre instead of Sifr > dir not work in my version. I think your Linux distribution is forcing you to use Sifr due to choosing high contrast in the Xfce settings.
Created attachment 188986 [details] Colibre can not be selected with Hoher Kontrast, tests repeated Yes, you are right. Colibre is incompatible with Hoher Kontrast. However it can be selected with the Linux system theme Adwaita. This test (see attachment) with Adwaita (rather than Hoher Kontrast) does not show, that my proposed improvement under the headline "Still one detail to improve" has been realized. The findings about the LibreOffice internal Icon Styles Sifr (and others) versus Colibre does not relate to this topic. However it rises further topics: At least the manual https://documentation.libreoffice.org/assets/Uploads/Documentation/en/GS7.3/GS73-GettingStarted.pdf should mention (e.g. on page 43) that some of the LibreOffice internal Icon Styles (e.g. Colibre) are incompatible with appearance settings of the operating system and will not be honored if selected, if this is the case. It would be better, not to offer those incompatible LibreOffice internal Icon Styles- At least they should be shown greyed out if they are incompatible with the chosen operating system theme. If this proposal is followed, such a line should be added to the manual: "The selectable icon themes depend on the theme settings of the operating system. Incompatible themes are grayed out in the drop-down list under Icon Style Icon Style."
(In reply to Adalbert Hanßen from comment #17) > Created attachment 188022 [details] > comparison old and new state, one minor item still to be improved When using Hight Contrast, the Sifr icon theme should be automatically picked because that is the one designed for High Contrast. In High Contrast, icons are designed to be understandable in greyscale, and ideally with only two colours that contrast significantly. So what you see as an issue with the table toolbar is actually expected. If anything, the Sifr theme should be improved to avoid using an intermediate grey, and only have single-shade icons that contrast starkly with the background. As the original issue in this report is resolved, and we're getting to a large number of comments, I am closing as "works for me". Please open now, focused reports if you still see issues when testing with version 24.2, starting with a new profile. Thank you!