Created attachment 188989 [details] Comments in margin: filter/qa/data/commentsInMargin.odt Description: On high DPI displays, sometimes comments are displayed very differently. For example, using 100% scaling differs a lot with 300% or even 150%. Steps to Reproduce: 1. Set display scale to 100%. 2. Open filter/qa/data/commentsInMargin.odt in LibreOffice 4. Set display scale to 150% 4. Close LibreOffice and open the above file again Actual Results: The display of comment is different. This is also visible in the PDF output. Expected Results: The result should be the same with different scaling and DPI, both on screen and output Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 20; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-GB Calc: CL threaded
Created attachment 188990 [details] PDF output with 100% scaling PDF output with 100% scaling while having "Comments in margin" enabled in "PDF options".
Created attachment 188992 [details] PDF output with 300% scaling PDF output with 300% scaling while having "Comments in margin" enabled in "PDF options".
I am unsure if it must be the same *on screen* - because it *might* be reasonable to use a different width for the side panel where the comments are displayed (?); however: 1. It definitely should be the same in PDF, because it has the same size for the side comments area, and other elements, like font, are the same - so it looks like no re-layouting of comments is happening for PDF output; 2. At least with 150%, the *screen* appearance of the (narrower) comments is *erratic*: the wrapped line overlaps the following author/date lines, and is thus hidden; the box does not expand vertically properly, even when you delete and then re-type that text.
(In reply to Mike Kaganski from comment #3) > I am unsure if it must be the same *on screen* - because it *might* be > reasonable to use a different width for the side panel where the comments > are displayed (?); however: The code that computes the width and height of the yellow box is actually shared in screen and output, and it is dependent on DPI, and also zoom level! SwAnnotationWin::SetPosSizePixelRect() affects both display and print. It is called in SwPostItMgr::LayoutPostIts(), in which its calculations are dependent on DPI. SwPostItMgr::GetSidebarWidth() calculates the width, which is DPI dependent. Also, height of the yellow box is DPI and Zoom dependent. SwAnnotationWin::GetMinimumSizeWithoutMeta() makes the height calculations zoom dependent. If you increase/decrease the zoom level, you will see the height of the yellow box changing, and this is also visible in the PDF output. > 1. It definitely should be the same in PDF, because it has the same size for > the side comments area, and other elements, like font, are the same - so it > looks like no re-layouting of comments is happening for PDF output; As I've said, the code that calculates the yellow box rectangle is shared between screen and print. > 2. At least with 150%, the *screen* appearance of the (narrower) comments is > *erratic*: the wrapped line overlaps the following author/date lines, and is > thus hidden; the box does not expand vertically properly, even when you > delete and then re-type that text. Yeah, the calculation of the yellow box is visibly wrong.
(In reply to Hossein from comment #4) > (In reply to Mike Kaganski from comment #3) > > I am unsure if it must be the same *on screen* - because it *might* be > > reasonable to use a different width for the side panel where the comments > > are displayed (?); however: > The code that computes the width and height of the yellow box is actually > shared in screen and output, and it is dependent on DPI, and also zoom level! > > ... > > > 1. It definitely should be the same in PDF, because it has the same size for > > the side comments area, and other elements, like font, are the same - so it > > looks like no re-layouting of comments is happening for PDF output; > As I've said, the code that calculates the yellow box rectangle is shared > between screen and print. I am unsure why you write this. AFAIU we are not discussing the current state (we seem to agree that it's not OK), but what specifically should change. If the code is shared currently, and if we agree that it is reasonable to be DPI-dependent on screen, then we simply split the code (as necessary).
(In reply to Mike Kaganski from comment #5) > I am unsure why you write this. AFAIU we are not discussing the current > state (we seem to agree that it's not OK), but what specifically should > change. If the code is shared currently, and if we agree that it is > reasonable to be DPI-dependent on screen, then we simply split the code (as > necessary). Yeah, that would be good, for sure. But in my opinion, as the code is wrong on both screen and print, the first step would be to fix the problem here, make the code not dependent on DPI and zoom level, and then go for splitting the code if necessary. Isn't it a reasonable approach to provide a fix?
(In reply to Hossein from comment #6) > But in my opinion, as the code is wrong > on both screen and print, the first step would be to fix the problem here, > make the code not dependent on DPI and zoom level, and then go for splitting > the code if necessary. But is it decided that it should *not* be DPI-dependent and zoom-dependent on screen? Isn't current behavior *on screen* reasonable - except for a problem of wrong height not fitting all the text?
(In reply to Mike Kaganski from comment #7) > (In reply to Hossein from comment #6) > > But in my opinion, as the code is wrong > > on both screen and print, the first step would be to fix the problem here, > > make the code not dependent on DPI and zoom level, and then go for splitting > > the code if necessary. > > But is it decided that it should *not* be DPI-dependent and zoom-dependent > on screen? OK, then let me explain more: 0. By "DPI and zoom independent" I mean that the the box size should not change relative to the size of the text in the document and the comments. 1. The comment text IS actually DPI and zoom independent. 2. The yellow box is not DPI and zoom independent, and it seems to be a miscalculation, and not an intentional adjustment. 1 & 2 => To fix the issue, one need to make the box also DPI and zoom independent. In the next paragraph I discuss why. > Isn't current behavior *on screen* reasonable - except for a > problem of wrong height not fitting all the text? This also needs explanation. One need to fix the yellow box width and height so that it fits all the comment text. But, there is an important point here: One may try to fix the problem by making the box only fit the comment text, without making it DPI and zoom independent. But, as the text is DPI and zoom independent, a fix would require the width/height calculation for the yellow box to be also DPI and zoom independent. Agree? One may try to do a better adjustment for both text and the box, but IMO it should be (possibly) considered to be a further enhancement. I would prefer not to go with this path, because IMO it is meaningful to keep the size of the comment text and box size constant relative to the size of the text in the document. I can compare it to the older decision of using LO UI elements for content controls, and the later decision to draw the elements inside the document, and let the users interact with those elements inside the document.
I don't reproduce a difference between PDF outputs at 100% and 200% scaling with Ubuntu 20.04, GNOME and: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 92e5898fa9ffa4dd8742f5f26e790563feef286e CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Hossein, did you say this had been fixed recently on IRC?
(In reply to Stéphane Guillou (stragu) from comment #9) > Hossein, did you say this had been fixed recently on IRC? Yes. I can not reproduce it on Linux, but then I found that the problem still persists on Windows. I have to test again. Can you test on Windows and confirm the bug?
Created attachment 194015 [details] File with screenshots 100% 200% 300% Attached draw file:n Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Screen resolution 2240x1400, text scale 175%
(In reply to m_a_riosv from comment #11) > Created attachment 194015 [details] > File with screenshots 100% 200% 300% > > Attached draw file:n > Version: 24.2.3.2 (X86_64) / LibreOffice Community > Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba > CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win > Locale: es-ES (es_ES); UI: en-US > Calc: CL threaded > Screen resolution 2240x1400, text scale 175% @m_a_riosv: You need to restart LibreOffice each time. Have you done that? Otherwise, you will get the same result. I still reproduce the problem with the latest LO 24.8 dev master: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9422879a5cf74120c1057b0f8150529e304f7c95 CPU threads: 20; OS: Windows 11 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Also reproducible with the latest LO 24.8 dev master, without Skia/Vulkan: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9422879a5cf74120c1057b0f8150529e304f7c95 CPU threads: 20; OS: Windows 11 (10.0 build 22631); UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded The output is different on 100%, 200%, and 300% scaling.