Description: When the display scaling on Windows is set to anything greater than 125%, the tabbed interface appears too small, and squished to the side. Consequently, the icons are also slightly smaller than they should be, making them harder to press. The problem appears to have been occurring since at least LibreOffice 6.2.5.2, and I have not been able to verify whether the problem occurs on an earlier version. This scaling bug does not seem to affect the Standard Toolbar or its variants, and affects all LibreOffice Applications where the user interface can be set to "Tabbed" or its variants. This can be especially problematic on devices for which the default scaling is set to something greater than 125%. I'll also attach two screenshots below to illustrate the bug. Both screenshots were taken in LibreOffice Writer in full screen mode, but with different display scaling options. Steps to Reproduce: 1.Open Windows settings app 2.Click on System 3.Click on Display 4.Set scale to 200% (This is the default on my windows device) 5.Open LibreOffice Word, Calc, or Impress and set the user interface to "Tabbed" Actual Results: The tabs appear to be compressed and squished to the left, and the icons are slightly smaller than normal. Expected Results: The tabbed interface is normally more polished and uniform. Reproducible: Always User Profile Reset: Yes Additional Info: Device info: - Device: Surface Pro (2017) - OS: Windows 10 Pro - Display scaling: 200% LibreOffice info: - Version: 24.2.2.2 (X86_64) / LibreOffice Community - Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 C- PU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 193532 [details] Screenshot of bugged Tabbed interface when display scaling is set to 200%
Created attachment 193533 [details] Screenshot of Tabbed interface when display scaling is set to 100%
Can't confirm, but see also bug 144134 for the Tabbed NB UI's variable padding in response to available horizontal size that would happen with Windows UI scaling. Perhaps adjust STR and identify display size and actual pixel width of the LO UI when you've scaled. Use an on screen utility like "Pixel Ruler" to get the measurments. =-Testing-= Version: 24.2.2.1 (X86_64) / LibreOffice Community Build ID: bf759d854b5ab45b6ef0bfd22e51c6dc4fb8b882 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 193546 [details] Difference between 100% and 200% scaling, with pixel measurements That's incredibly useful and interesting. Having done further testing with the scale set to 100%, 125%, 150%, 175%, and 200%, I am certain that it must be a scaling issue rather than merely a problem with the tabbed interface resizing poorly due to the available horizontal space. My device has a resolution of 2736 x 1824 px. At 100% scaling, I obtain the exact results you obtained (https://bug-attachments.documentfoundation.org/attachment.cgi?id=174702). Namely, that there is an adequate amount of padding at full screen (in my case 2736px), which is kept the same until you reach 1140px. Anything lower than that, and the Tabbed UI's padding will be reduce to merely the text. To check whether the removed padding was the result of available horizontal space or scaling, I measured the horizontal length of the tabs themselves at different scales. What follows are my results: At 100% scale: - Full width is 2736px - Padding is constant until 1140px (anything below, and the padding is drastically reduced) At 125% scale: - Full width is 2188px - Padding is constant until 913px At 150% scale: - Full width is 1824px - Padding is already reduced, but tabs aren't fully collapsed until 819px At 175% scale: - Full width is 1563px - Padding is already reduced, but tabs aren't fully collapsed until 715px At 200% scale: - Full width is 681px - Padding is already reduced, but tabs aren't fully collapsed until 681px It's worth noting that, already, anything above 125% results in the tabs having no padding. I have attached another picture (scaling_issue.jpg) to better illustrate the problem, with pixel count labelled (measured with pixel ruler). Indeed, it is very odd that, while scaled to 100%, the padding is present until 1140px, but at 200% scale, even with 681px (which is greater than the equivalent 570px), the padding is already gone and the collapsed tabs simply appear more even more compressed. In other words, even when there is more horizontal space than would be equivalently available at 100% scaling, the Tabbed UI makes no use of this space.
Is the .UI padding collapse being controlled by PriorityHBox sizing of vclHbox [1]? But then the inconsistent ratio comes from misread of os/DE scaling or pixel size calculation? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/vcl/source/control/PriorityHBox.cxx?r=b595a93f#108 @Justin, Szymon any cycles to mull over this, and see also bug 144134?
Don't think we can say the icons are resized. That is manifestation of differing dpi as the os/DE UI is being scaled. Only issue seems to be the inconsistent ratios at which the priority horizontal sizing asserts. Both in hiding NB widgets, but also the shift to the "compressed" padding for the tab labels. Other than issue of the ratio, seems more a dupe of see also bug 144134 suggesting incremental reduction in padding the NB tab labels.