Description: Notebookbar in Contetual group view is not usable on HiDPI Display - see screenshot 1. My System: Windows 10, LO 5.3.0.0.Alpha1 - 2. Nov. 20116 I attached OpenCL and OpenGL info files. Actual Results: see screenshot Expected Results: ... Reproducible: Always User Profile Reset: Yes. Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Created attachment 128426 [details] Notebook-Bar in Contextual Group View
Created attachment 128427 [details] opencl_profile.xml
Created attachment 128428 [details] opencl_devices.log
Created attachment 128429 [details] opengl_devices.log
Thanks for the bug report Thomas. Does this hidpi issue also happen with notebookbar in tabbed view?
Do you have a scaling factor for fonts?
@ Yousuf: No, notebookbar in tabbed view ist ok, no problems, everything is visible. @ Heiko: No, no scale for fonts. Option is "automatic" Thanks:)
works on osx
Created attachment 130471 [details] Notebookbar - Contextual groups Notebookbar - Contextual groups is not the only case where LibreOffice needs a proper UI scalability. Furthermore, here on Fedora, it is not a high density screen, so it seems like a more generic problem.
*** Bug 105627 has been marked as a duplicate of this bug. ***
The problem boils down to the buttons and labels having fixed widths and/or heights defined to them, so in HiDPI the sizes of the buttons and labels go beyond the defined widths and heights.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
LibreOffice 6.3.2 (x64) - Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac Windows 10 Home x64 build 1809 I can confirm the bug still exists. Today I downloaded and installed the latest released version of LibreOffice (see above for specs on product and OS). I was going to open a new bug but a search here discovered this existing one. After enabling experimental features, I went to View -> User Interface -> Contextual Groups. Some text within the groups is truncated at the bottom. I have DPI set to 150% because text is too small at 100% on my hi-res 2560x1440 LED monitor. I wanted a higher resolution monitor to use MORE pixels per character to make them sharper, not the same number of pixels at a higher resolution which results in overly reducing the size of text. The problem is that many programs are not DPI aware, and unfortunately neither is LibreOffice - well, for its Contextual Groups user interface component (and only for that user interface). I do like having grouped tabs, like in the Microsoft Office components (Word, Excel) and was hoping to have LibreOffice emulate a similar appearance. MS Office makes their ribbon adapt to what is being done on a document. I was hoping Contextual Groups would be similar. Perhaps it is similar but I still need the text next to an icon to let me know what that icon will do (I don't want to wait for a popup to tell me). The Tabbed and Groupedbar interfaces do not suffer bottom-side truncation of text at 150% DPI as does the Contextual Groups interface. I did try to use the Compatibility settings for the executables: right-click on an .exe, select Properties from context menu, open the Compatibility tab, click on the "Change high DPI settings" button, and enable the "Override high DPI scaling behavior" and used "Scaling performed by: Application". This often works to get a non-DPI aware program to render correctly and sharply. I changed DPI compatibility on both the soffice.exe and swriter.exe files but the DPI compatibility setting did not eliminate the bottom-side truncation of text within the Contextual Groups bar. I tried "Scaling performed by: System", too. While this eliminated the bottom-side truncation of text within the Contextual Groups bar, fonts everywhere became far more fuzzy (out of focus). I tried "Scaling performed by: System (enhanced)". Bottom-side truncation of text was eliminated and fonts were a bit more readable but nowhere as sharp when not using any DPI compatibility setting. The "Program DPI" compatibility setting had no effect. It is only the Contextual Groups toolbar that encounters bottom-side truncation of its text. Other user interfaces (toolbars) do not suffer this problem. The dimensions for the text objects (and their containers) needs to resize based on the DPI setting. The user can rely on hover-over popups to see what an icon's function will do should the text become overly obliterated due to truncation; however, that means using a secondary means of determining the function.
The bug still exists in version 7.0.0.3 on windows 10, even without interface scalling.
Dear Thomas Krumbein, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
LibreOffice Writer 7.3.5.2 (latest stable version available) Windows 10 Home x64 21H2 DPI = 150% Truncation (at bottom of text labels) still occurs. At the left side of the notebookbar, no text is truncated. That is because the elements (buttons + labels) are far enough apart to prevent overlaps. Not until the mid-portion to right-portion of the Text section where bottom truncation occurs, because the objects are closer together, or there is insufficient space at the higher DPI for the bottom of the element. There is also trunction at the bottom of text labels in the Insert section.
*** Bug 151953 has been marked as a duplicate of this bug. ***