Description: The thumbnails of the last used documents have from version 7.4.x.x a large branding icon in the preview (see screenshot of the Document preview, version 7.4.7.2 – large icons). In version 7.3.7.2 the branding icons were the branding icons were still small (see screenshot of the Document preview, version 7.3.7.2 – small icons). The size of the thumbnails is the same in both cases, only the size of the branding icons within the thumbnails is very different. The settings of the operating system are unchanged or there is nothing to set of the branding icons. The appearance also occurs with the version 7.5.x.x and on other computers or VMs. Actual Results: See Description. Expected Results: See Description. Reproducible: Always User Profile Reset: Yes Additional Info: See Description.
Created attachment 187153 [details] large branding icon in the preview
Created attachment 187154 [details] small branding icon in the preview
please post the Help --> About details also, the display size and the os/DE scaling factor you are using. On Windows that is Settings -> Display "Scale and layout" list box, or the adjacent "Advanced scaling settings" dialog "Custom scaling".
looking at the screen clips, the "branding icons" stamped on the preview thumbnails are now getting the same scale size as the icons for the left SC toolbar. Guess that could have slipped 7.3 -> 7.4
So can confirm an issue On Win10 with a 4K monitor and Custom scale set to 300%, the branding icons stamped onto the thumbnail previews on the SC are oversize and get scaled as the SC left side bar button icons. Looks pretty odd... Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded @Ransom, we still need details indicated please.
Hello V Stuart Foote, thanks for your commitment. Help --> About details: Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded display size 3.840 x 2.160 os/DE scaling factor 320
Update: On my wife’s PC, the branding icons are just as oversized, even though her screen size is only 1.920 × 1.080 and the scaling factor is 160 dpi. Therefore, I do not think it’s necessarily a HiDPI problem.
Created attachment 187306 [details] Screenshot wit 7.0.0.a1 Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 6f1534940ac12ff8e46f4782e18cfb6cf585da39 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Screen 2240x1400 scale 175%
Confirming, the icons scale with the display setting. But isn't this wanted?
(In reply to Heiko Tietze from comment #9) > Confirming, the icons scale with the display setting. But isn't this wanted? Agree that this is expected. My opinion is that the actual issue for Ransom is that the _thumbnails_ are not scaled up like everything else. Both are scaled together as expected for me in: Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 22950a9b008e1bb22fa9e54b5d45715e25fee764 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Heiko Tietze from comment #9) > But isn’t this wanted? That is quite possible. But maybe the programmers didn’t realize that in most cases the branding icons take up so much space that there’s not much left of the actual preview thumbnails. I have always appreciated the latter, but with this new feature, the branding icons are pushed to the foreground, which destroys the preview. And I find that very unfortunate.
(In reply to Ransom from comment #11) > [...] the branding icons take up so much space that there’s not much > left of the actual preview thumbnails. As I said in comment 10, I think the issue is that you document previews are not scaled up when they should, just like all other UI element do. If they did, the relative size of the icon would remain the same. Stuart, would you agree? Are the thumbnails not scaling up when the OS scaling is increased?
(In reply to Stéphane Guillou (stragu) from comment #12) > (In reply to Ransom from comment #11) > > [...] the branding icons take up so much space that there’s not much > > left of the actual preview thumbnails. > > As I said in comment 10, I think the issue is that you document previews are > not scaled up when they should, just like all other UI element do. If they > did, the relative size of the icon would remain the same. > > Stuart, would you agree? Are the thumbnails not scaling up when the OS > scaling is increased? Actually, they do scale. But not at the same rate. The MIME type icons stamped onto the backing window thumbnails are sized the same as the icons on the SC sidebar. But the thumbnails on the backing window scale less. So by 175% or OPs 300% they are rather out of sync.
Created attachment 187365 [details] LO 7.5.3 on a 4K system win10 os/DE at 325% scale compare the attached clips of SC from a Win10 w/4K display system--one at 325%, and the other at 175% os/DE scaling amount the thumbnails are scaled differs from amount the mime type icons are scaled.
Created attachment 187366 [details] LO 7.5.3 on a 4K system win10 os/DE at 175% scale
(In reply to V Stuart Foote from comment #13) > (In reply to Stéphane Guillou (stragu) from comment #12) > > Are the thumbnails not scaling up when the OS scaling is increased? Stuart's screenshots show that the thumbnails don't scale. But I'm not sure if the preview looks good and is usable at double size as not many more than two fit onto the canvas.
Agree that the scaling factor is not ideal, relative to the scaling factor of the thumbnails (or lack thereof). Tested with gen and kf5 VCLs. Challenge is, the thunbnails will look bad when scaled up, as Heiko said, whereas we at least have the option of upscaling icons from SVG. In 7.4, we went from barely visible icons to big overlapping ones with: commit 1dbed50a6ed73570ca2d8a1e37237205e2394c34 author Mike Kaganski <mike.kaganski@collabora.com> Tue Mar 15 15:45:15 2022 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> Tue Mar 15 21:19:17 2022 +0100 tdf#134065, tdf#147998: fix thumbnail generation code Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131610 Mike, what do you think?
(In reply to Stéphane Guillou (stragu) from comment #17) > Mike, what do you think? I think that: 1. On all the screenshots, the overlapping icons scale exactly the same amount as the icons on the left pane. 2. I made the icons show the *same* stable size, not scale *randomly*; but IIRC, it was Heiko who chosen those icons, so my work only fixed the implementation of the original design. It should be now trivial to decide and use smaller icons if wanted; or focus on proper thumbnail scaling, if deemed proper.
The thumbnail doesn't change its size with scaling so the overlay image must not too.
UI scaling is *designed* to scale the size of all UI elements. Buttons, strings, thumbnails. If some UI element doesn't scale according to the system UI scaling, it's a bug that needs fixing, not to make other UI elements not scale.
(In reply to Mike Kaganski from comment #20) > UI scaling is *designed* to scale the size of all UI elements. The overlay icon is an indicator for the thumbnail. And the size of this image was not challenged. So scaling to the original size makes sense here.
(In reply to Heiko Tietze from comment #21) A thumbnail is (1) a "button" to open a document, and (2) a preview. The preview is expected to show scaled, because without that, a HiDPI monitor would have e.g. 3x smaller thumbnail, with already small document elements getting completely unrecognizable. I do not understand the controversy here. No, not scaling the thumbnails according to system UI scaling is a bug.
Created attachment 187666 [details] Screen patched vs unpatched Start center 200% zoom, 227ppi, unpatched above the patched version While I can imagine better solutions, it is an improvement in itself.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f8036f2f5238adf227d0ffa646e503f0446bb37b Resolves tdf#155200 - Don't scale overlay images in start center It will be available in 7.6.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.
Created attachment 187739 [details] LO 7.6.0.0.alpha1+ on a 4K system win10 os/DE at 320% scale
I tried it with the daily version from this morning (03:18), and the branding icons are small this time (see screenshot of the Document preview, version 7.6.0.0.alpha1+). Unfortunately, the document names are half cut off in the first row. Maybe something needs to be improved or even the thumbnails need to be scaled according to system UI scaling after all (comment #22).
(In reply to Ransom from comment #26) > I tried it with the daily version from this morning (03:18), and the > branding icons are small this time (see screenshot of the Document preview, > version 7.6.0.0.alpha1+). Unfortunately, the document names are half cut off > in the first row. Maybe something needs to be improved or even the > thumbnails need to be scaled according to system UI scaling after all > (comment #22). The document name labeling looks to be scaled the same as the text in the Sidebar. So the packing on the backing pane needs more space, or the text labeling for thumbnails should receive a smaller font size assignment for more text to fit in the space. Related UI question, in scaled UI what size is text from the mouse-over tooltip popup--that shows the file path for the entry? Is it the same over-scaled size and matching the sidebar, or is it more reasonable size? Its size controlled differently.
(In reply to V Stuart Foote from comment #27) > Is it the same over-scaled size and matching the sidebar, or is it more > reasonable size? Is the problem here that people *think* it's oversized? Look at the screenshots. Check the window header. It has an icon and a text. Also there is a menu under it. These elements are actually correct, heading controlled by OS, and menu scaled correctly. Now look below. The "sidebar" has *almost* the same size of text (a *bit* larger, D has 27 pixels in menu, 31 pixel in sidebar). These sizes reflect the *small* text on screen on HiDPI screens. Now compare to the size of thumbnails. It is 256 pixels - less than 10 times the height of D. And then look at the *standard* scale. The menu's capital text height is 9 pixels, which looks *the same* physical size of my non-HiDPI screen; and the thumbnail is the same 256 pixels. It is 28 times higher than the capital letter. The problem here is the screenshots only showing small part of the app window, and not showing the full screen with other windows, for creating the correct scale perception.
Created attachment 187740 [details] A non-HiDPI 100%-scaled LO start center Just to create correct perception of intended UI element size relations.
Agree with Mike here, that all elements should scale in the same way, which is the whole point of scaling and touches on accessibility. Would be good to get higher-definition thumbnails to cater for that - which also would give more weight to keeping them separate from registrymodifications.xcu (bug 99716).
Even with version 7.6.0.2, the document names are half cut off on all lines except the last one. What about comment 30 from Stéphane Guillou (stragu)? She also agrees with Mike that all elements should scale in the same way. Anyway, the problem is not solved yet, and Mike’s hint sounds promising to try the same one at least once.
I can’t understand why there is only persistent silence from the responsible side. In any case, the error reported here is not (yet) “RESOLVED FIXED.” I have therefore taken the liberty of setting the status back to “REOPENED.”
The problem of the too large branding icon in the thumbnails of the last used documents seems to have been solved since version 7.6.0 (see Comment 24), but the problem of the – depending on scaling – more or less cut off document names in the document preview still exists. Yesterday I installed the latest version (24.2.0.2_x64) on Win10 with a 4K monitor. Up to a user-defined scaling factor (os/DE) of 260, the file names are completely readable or not truncated. From 270 the truncation of the descenders of a letter starts. If the scaling factor is increased further, the truncation of the letters increases more and more, and at 400 almost nothing of the document names can be seen in the document preview. I have taken several screen shots, in steps of 10 from 250 to 300% and then in steps of 50 up to 400%. The problem with the truncated document names in the document preview should also be solved.
Created attachment 192112 [details] 250
Created attachment 192113 [details] 260
Created attachment 192114 [details] 270
Created attachment 192115 [details] 280
Created attachment 192116 [details] 290
Created attachment 192117 [details] 300
Created attachment 192118 [details] 350
Created attachment 192119 [details] 400
@Ransom, please review your MS Windows UI settings for "Ease of Access Display Settings" specifically the "Make text bigger" slider. You've set a value to high for the os/DE scale you are working at. Reduce to about 120% and retest. I do see the "cut off document names" you report, but only when the os/DE text scaling is set too high. Not a bug.
@Ransom, please review your MS Windows UI settings for "Ease of Access Display Settings" specifically the "Make text bigger" slider. You've set a value too high for the os/DE scaling you are working at > 260%. Reduce the independent text scaling to about 120% and retest. Which is to say that I do see the "cut off document names" you report, but only when the os/DE text scaling is set too high. That is not a LibreOffice bug, other applications on Windows os/DE similarly affected by MS Windows asymmetrical scaling of UI elements.
@VStuart Foote, I think there is a misunderstanding. My settings for my MS Windows UI settings for “Ease of Access Display Settings” specifically the “Make text bigger” slider are untouched, so the default value (100%). The user-defined scaling factors I am talking about concern the Display settings and there the “Advanced scaling settings”. I have been using LO Writer continuously since some version 4 in 2015. I have been using Windows 10 since September 2015. Up to version 7.4.x.x I never had any problems with the display of the thumbnails of the last used documents and their document names in the document preview. Something must have changed since version 7.4.x.x, and I do think it’s a LibreOffice bug, even though I don’t set the status back to “REOPENED”.
Created attachment 192135 [details] OnlyOffice preview and icon scaling, 100% vs 200% The scaling factor is the same for previews, icons and text in OnlyOffice (here, showing the template previews). Which means it's consistent at different zoom factors and the same amount of text is shown underneath the preview. I still think all scaling factors should be the same for all elements in the Start Centre. Furthermore: - If the number of document listed on one row isn't enough, we can use a baseline preview size that's smaller. - If not enough of the document title is shown, we can use two lines of text. - And if the definition isn't sufficient at high scaling factors, we can fix bug 99716 and store higher-definition thumbnails in the profile.
Created attachment 192139 [details] side-by-side LO 7.6.4 w OnlyOffice 7.5.1.23 -- SC Template mode 300% UI w 100% text So attaching two screen clips, the first is with Win10 on a 4K display set with "Display settings" -> "Advanced scaling settings" -> "Custom scaling" set at 300% with "Ease of Access" -> "Display" -> "Make text bigger" set at 100%. The second is with Win10 on a 4K display at 300% with the "Make text bigger" set at 150% On the left is LO 7.6.4 SC in Template mode, on the right is OpenOffice 7.5.1.23 in template mode. Notice in the second that the issue seems to be the "packing" of the thumbnails onto the backing window of the SC as the UI scales. Regardless of scaling of the thumbnail (which probably should scale), the space allocated to each is insufficient to hold the height of the text as the UI text elements scale. OnlyOffice allocates sufficient space for packing its template thumbnails. Seems we need to rework the packing, and maybe the thumbnail scaling.
Created attachment 192140 [details] side-by-side LO 7.6.4 w OnlyOffice 7.5.1.23 -- SC Template mode 300% UI w 150% text with os/DE text scaling, padding for thumbnails on the SC backing is not sufficient.
Comparing the two clips attachment 192139 [details] and attachment 192140 [details] (the programs were side by side in each UI scaling test, clips were full 4K desktop, only the os/DE text scaling differed). LO responds to the os/DE text scaling which is correct, OnlyOffice does not and ignores the os/DE font scaling and tracking only the general UI scaling. Technically incorrect to ignore the os/DE text scaling provided by Windows, but the OnlyOffice implementation *is* less annoying.
Created attachment 192142 [details] side-by-side LO and OnlyOffice template mode on same Win10 system with 4K display at UI scale 150%, text at 100%
Created attachment 192143 [details] side-by-side LO and OnlyOffice template mode on same Win10 system with 4K display at UI scale 150%, text at 100%
Loosing track with >20 comments on a resolved ticket. Mind to file a new bug report?
(In reply to Heiko Tietze from comment #51) > Loosing track with >20 comments on a resolved ticket. Mind to file a new bug > report? Please don't. Heiko: basically, the majority of the comments here are relevant, you you simply need to take the effort of reading and analyzing what's told here. A new report wouldn't make it better, and the "fixed" status of this bug doesn't make it correctly fixed (see my comments prior to your commit in comment 24).
Trying with bug 160819