The cell border colour for active or selected cells consists of solid lines. As noted in bug 142121 this can be almost or completely invisible on certain cell background colours, and even moreso for the thinner selection outline. Fix this problem once-and-for-all by changing cell border for active and selected cells to a dashed line using the normal colour for dashes and the complementary colour between the dashes. As is, the dashed line would appear to be a solid grey line when the normal colour is grey. So compute the contrast ratio of the normal colour and complementary colour, and use an alternate colour for spaces if the contrast ratio is less than 7. See https://www.101computing.net/colour-luminance-and-contrast-ratio/ For example, choose white or black for the alternate colour, whichever makes the contrast ratio larger. Examples: black solid outline -> black dashed outline with white between dashes. blue solid outline -> blue dashed outline with yellow between dashes.
Please attach a sample file, reduce the size as much as possible without private information, and paste the information in Menu/Help/About LibreOffice, there is a copy icon.
(In reply to m_a_riosv from comment #1) > Please attach a sample file, reduce the size as much as possible without > private information, and paste the information in Menu/Help/About > LibreOffice, there is a copy icon. Won't the colour of the border of the active cell depend on the user's platform, and not necessarily on the contents of a workbook? It's blue for me, the same colour as the row and column indicators. Version: 7.4.7.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.UTF-8); UI: en-US Debian package version: 4:7.4.7-1+deb12u1 Calc: threaded
(In reply to Robert Lacroix from comment #0) > Fix this problem once-and-for-all by changing cell border for active and > selected cells to a dashed line using the normal colour for dashes and the > complementary colour between the dashes. There are some merits to the proposal, but also some potential conflicts. The solid "focus" (or active) line might conflict with some borders and other lines used in Calc, but dashed lines are also in use under other conditions. In LO 24.2, there have been some changes that affect how the active cell is shown/marked. For instance, there is a new optional Column/Row Highlighting setting. Further changes in up-coming versions will also have an impact on this matter. For example, the active cell/range indicator (the same we are discussing in this enhancement request) is shown slightly outside the cell, instead of overlapping with the cell's limits / grid / border. So maybe this enhancement request includes an interesting suggestion, but perhaps the aforementioned changes reduce the need for it. Using a 2-colors "dashed" surrounding line to mark the active cell/range might be worth consideration anyway.
Dashed lines are used to indicate the source of a copy action (including marching ants that, however, can be disabled). And I doubt it will fix "the problem" "once-and-for-all". Please check again with the latest changes.
(In reply to Robert Lacroix from comment #0) > […] changing cell border for active and > selected cells to a dashed line using the normal colour for dashes and the > complementary colour between the dashes. Instead of dashed line, a two-color double line could be easy to implement and better visually. (In reply to ady from comment #3) > Further changes in up-coming versions will also have an impact on this > matter. For example, the active cell/range indicator (the same we are > discussing in this enhancement request) is shown slightly outside the cell, > instead of overlapping with the cell's limits / grid / border. Good to read of the coming enhancements.
Created attachment 194423 [details] Screenshots of Excel, OnlyOffice, Google Sheets and Calc See attached ODG file with screenshots of how Excel, OnlyOffice and Google Sheets handle this issue. In Excel/OnlyOffice a white internal outline is used, and honestly it gives good contrast to me. I was about to create a ticket to propose the same thing. In Google Sheets they still haven't dealt with this issue. My proposal is to do the same as Excel/OnlyOffice and add an internal white outline.
We discussed the topic in the design meeting. To summarize the issue: with a cell background equal or close to the highlight color, selections become invisible or hard to spot. One idea was to follow Excel's example and have an additional frame in the default cell background color. However, Excel puts the focus around the selection while we distinguish the two states. This might look ugly. We may also change the line style. But the proposed dashed appearance could interfere with the cell border style and the copy state with MarchingAnts being disabled. The cell background cannot have a hatching, which could be otherwise an option too. Another solution could be to alter the highlight color if the cell background is not the default. The color merge function could be a simple way to implement this.
Created attachment 194601 [details] ODS file for testing Proposed patch here: https://gerrit.libreoffice.org/c/core/+/168538 Here's also a ODS file for easy testing the patch. It has some combinations of backgrounds and cell borders to test the new outline.
As an option, here is shown a screenshot showing an offset outline. https://ask.libreoffice.org/t/topic/106613
Created attachment 194620 [details] Screenshot with patch applied
(In reply to Heiko Tietze from comment #10) > Created attachment 194620 [details] > Screenshot with patch applied For me, as seen in the screenshot, the selection border is OK. It is possible that the (wide blue) active cell border gets some transparency? So that when you need to read the content in the adjacent cell, it's not bloqued. Thanks.
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dc243f0122ba656d2630e93bebfb84a2bfe4042a tdf#161204 Improve visibility of outline in the selection overlay It will be available in 24.8.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.
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/81f73ee5128eaa6328a2b08b0398202d747312ca tdf#161204 Fix selection outline with overlapping ranges It will be available in 25.2.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.
Rafael Lima committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/3c0db898092c2cf6148c01f6c561acc199d484f5 tdf#161204 Fix selection outline with overlapping ranges It will be available in 24.8.0.0.beta2. 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.
(In reply to Commit Notification from comment #13) > https://git.libreoffice.org/core/commit/ > 81f73ee5128eaa6328a2b08b0398202d747312ca > > tdf#161204 Fix selection outline with overlapping ranges > > It will be available in 25.2.0. That's confusing. Should comment 13 be ignored? Is commit 81f73ee5128eaa6328a2b08b0398202d747312ca annulled/canceled/reverted?
Is this bug only/mostly about behavior in the presence of a background similar to the active cell focus rectangle? At any rate, if the problematic situation of drawing the rectangle outside of the cell, with some clearance (see bug 161740) is reverted - then this bug might require some revisiting.