Description: The red comment indicator obscures the cell values, making it very hard to read the last digit in the cell even though the indicator is semi-transparent. This is very noticeable with lower zoom levels, e.g. 60% and makes the sheet unusable. Also tested with LibreOffice 6.2 Alpha 1 and the problem still exists. Steps to Reproduce: 1. Create a new sheet. 2. Add a number to a cell, e.g. 100 3. Add a comment to the same cell. 4. Change the zoom level to 60% Actual Results: The last digit in the cell is obsured by the red comment indicator making it very hard to read as it covers a large portion of the last digit. Expected Results: The solution is quite simple, the red comment indicator should be moved to the top right corner of the cell (no space between the border and the indicator), and made smaller. This is in fact what OpenOffice does and works well even at low zoom levels. Reproducible: Always User Profile Reset: Yes Additional Info: If my understanding of the code is correct it seems that this line (2224) in core/sc/source/ui/view/output.cxx method DrawNoteMarks() needs to be modified: rRenderContext.DrawRect( tools::Rectangle( nMarkX-5*nLayoutSign,nPosY,nMarkX+1*nLayoutSign,nPosY+6 ) ); The OpenOffice equivalent is: pDev->DrawRect( Rectangle( nMarkX,nPosY,nMarkX+2*nLayoutSign,nPosY+2 ) ); OpenOffice is using a much better red comment rectangle size and position, can a similar approach be taken for LibreOffice?
Created attachment 146536 [details] Bug reproduced
I'm not sure that it's a bug. People, what do you think about it "problem" and about solution from wizzycode@virginmedia.com ?
I have tries all the same steps on: 1. LibreOffice: - Version: 6.1.2.1 (x64) - Version: 6.2.0.0.alpha1+ (x64) On both versions on the same zoom size(75), I got the same bug as reported. However, i think this is not a bug, it is because of the accuracy of the minimum and maximum zoom with the red sign of comment. Version: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 8; OS: Windows 6.3; UI render: default; Locale: en-US (en_US); Calc: group threaded Version: 6.2.0.0.alpha1+ (x64) Build ID: 8274c4c62df5b937b3f0bec9e1eeca85f3b219d4 CPU threads: 8; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-22_01:47:50 Locale: en-US (en_US); Calc: threaded 2. Microsoft Office 2010: On Microsoft, it looks well placed. and the red sign of comment doesn't cover the last number
I have tried all the same steps on: 1. LibreOffice: - Version: 6.1.2.1 (x64) - Version: 6.2.0.0.alpha1+ (x64) On both versions on the same zoom size(75), I got the same bug as reported. However, i think this is not a bug, it is because of the accuracy of the minimum and maximum zoom with the red sign of comment. Version: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 8; OS: Windows 6.3; UI render: default; Locale: en-US (en_US); Calc: group threaded Version: 6.2.0.0.alpha1+ (x64) Build ID: 8274c4c62df5b937b3f0bec9e1eeca85f3b219d4 CPU threads: 8; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-22_01:47:50 Locale: en-US (en_US); Calc: threaded 2. Microsoft Office 2010: On Microsoft, it looks well placed. and the red sign of comment doesn't cover the last number
Created attachment 146553 [details] The result of LibreOffice 6.1
Created attachment 146554 [details] The result of LibreOffice Version: 6.2.0.0.alpha1+ (x64)
Created attachment 146555 [details] Result on Microsoft office 2010
Agreed, the size of this indicator has to take the zoom level into account (extremes 20% and 200% don't work).
I agree that the correct solution would be to make the indicator size take account of the zoom level so it gets smaller as the zoom gets lower - Microsoft Excel actually does this and works very well at all zoom levels. In addition maybe the indicator can be moved more to the top right corner of the cell border.
Dear wizzycode, 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
Dear wizzycode, 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
(In reply to wizzycode from comment #0) > This is in fact what OpenOffice does and works well even at low zoom levels. With OO and LO 4.0 indicator was small. So I set regression. Then were changes with LO 4.4, not well thought of, as seen in bug 81032 and bug 89182. http://cgit.freedesktop.org/libreoffice/core/commit/?id=902b7e9f192fab45cffc35d81cd0df0373a610ed http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d1abfff0156c17cdaabf27c01e92b5e3f0bbbf4 With 7.5+ is as reported.
Even though the red comment indicator is semi-transparent, it obscures the values of the cells, making it very difficult to read the last digit in the cell. Lower zoom levels, like 60%, make this very obvious and render the document useless. https://bubble-shooters.co/
Submitting a patch for the duplicate... *** This bug has been marked as a duplicate of bug 91414 ***
*** This bug has been marked as a duplicate of bug 91415 ***