Bug 156781 - Display of comments is DPI dependent, both on screen and output
Summary: Display of comments is DPI dependent, both on screen and output
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: HiDPI Writer-Comments
  Show dependency treegraph
 
Reported: 2023-08-16 06:37 UTC by Hossein
Modified: 2024-05-07 16:52 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Comments in margin: filter/qa/data/commentsInMargin.odt (9.71 KB, application/vnd.oasis.opendocument.text)
2023-08-16 06:37 UTC, Hossein
Details
PDF output with 100% scaling (18.47 KB, application/pdf)
2023-08-16 06:45 UTC, Hossein
Details
PDF output with 300% scaling (18.48 KB, application/pdf)
2023-08-16 06:46 UTC, Hossein
Details
File with screenshots 100% 200% 300% (72.58 KB, application/vnd.oasis.opendocument.graphics)
2024-05-07 11:17 UTC, m_a_riosv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hossein 2023-08-16 06:37:34 UTC
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
Comment 1 Hossein 2023-08-16 06:45:24 UTC
Created attachment 188990 [details]
PDF output with 100% scaling

PDF output with 100% scaling while having "Comments in margin" enabled in "PDF options".
Comment 2 Hossein 2023-08-16 06:46:00 UTC
Created attachment 188992 [details]
PDF output with 300% scaling

PDF output with 300% scaling while having "Comments in margin" enabled in "PDF options".
Comment 3 Mike Kaganski 2023-08-16 07:19:30 UTC
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.
Comment 4 Hossein 2023-08-19 09:16:48 UTC
(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.
Comment 5 Mike Kaganski 2023-08-19 09:37:27 UTC
(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).
Comment 6 Hossein 2023-08-19 09:53:16 UTC
(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?
Comment 7 Mike Kaganski 2023-08-19 18:45:16 UTC
(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?
Comment 8 Hossein 2023-08-19 21:19:57 UTC
(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.
Comment 9 Stéphane Guillou (stragu) 2023-11-16 20:54:14 UTC
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?
Comment 10 Hossein 2023-11-16 21:35:05 UTC
(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?
Comment 11 m_a_riosv 2024-05-07 11:17:56 UTC
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%
Comment 12 Hossein 2024-05-07 16:47:44 UTC
(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
Comment 13 Hossein 2024-05-07 16:52:11 UTC
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.