Bug 155886 - Hash marks that indicate "cell too narrow" should fill up the cell width
Summary: Hash marks that indicate "cell too narrow" should fill up the cell width
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-UX Calc-Cells
  Show dependency treegraph
 
Reported: 2023-06-16 23:16 UTC by Hossein
Modified: 2023-07-06 13:03 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
XLSX file containing text and number with different cell widths (9.97 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2023-06-16 23:16 UTC, Hossein
Details
Excel vs. LibreOffice (436.95 KB, image/png)
2023-06-19 07:58 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hossein 2023-06-16 23:16:57 UTC
Created attachment 187951 [details]
XLSX file containing text and number with different cell widths

Description:
In both LibreOffice and MS Excel, hash marks are used as a replacement, when the area for showing a number is not large enough to contain the number as it should be shown. But LibreOffice always shows 3 hash marks (###) for this purpose. This has a major drawback: no matter how much the needed width is, the placeholder remains the same.

Even by implementing tdf#129847, it is not meaningful to place arrows on left, right, or both sides because the use case is different compared to a text, which part of it is visible, and the arrow shows where the extra part of the text is hidden.

When there is no visible text, the arrows will be meaningless. On the other hand, increasing the number of hash marks until it fills the cell width is a more meaningful approach to show the cell area, and its lack of enough space.

Steps to Reproduce:
1. Open the attachment in LibreOffice

Actual Results:
LibreOffice always shows 3 hash marks (###). If the area is smaller, 

Expected Results:
Hash marks should expand fill the cell width. For a comparison, you can open the same file in MS Excel.

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f1ee5c77fbdc2aa2b6448d056db2929423aa9bc4
CPU threads: 20; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: CL threaded
Comment 1 ady 2023-06-17 16:34:28 UTC
> Hash marks should expand fill the cell width.

FWIW, I agree... but with a minimum of three # marks, even when the width of the cell is not enough for all three marks.

If the width of the cell is not enough for all three # marks, then the behavior should not be modified in comparison to the current one (unless and until tdf#129847 is implemented, if implemented).

If the width of the cell is enough for more than 3 # marks, then additional # marks should be displayed in the cell, until the width of the cell is full of # marks, but not over it.

I am setting this as NEW ENHANCEMENT request, even when there is still needsUXEval.
Comment 2 Heiko Tietze 2023-06-19 07:58:31 UTC
Created attachment 187978 [details]
Excel vs. LibreOffice

I don't see the benefit. It rather clutters the UI.
Comment 3 ady 2023-06-19 09:16:55 UTC
(In reply to Heiko Tietze from comment #2)

> It rather clutters the UI.

No, it does not. The current behavior (only and always 3 # marks) for inexperienced users is frequently not clear enough, and even less clear is when they see enough available space. When the width is full of # marks, it makes a better hint regarding the width. Perhaps not always enough – where tdf#129847 might help, maybe – but better than the current behavior.
Comment 4 Hossein 2023-06-19 09:35:40 UTC
(In reply to Heiko Tietze from comment #2)
> Created attachment 187978 [details]
> Excel vs. LibreOffice
> 
> I don't see the benefit. It rather clutters the UI.
To describe its benefit, I should elaborate more on tdf#129847:

Bug 129847 - ### indication of "cell too narrow" should additionally show "more content" red arrow
https://bugs.documentfoundation.org/show_bug.cgi?id=129847

It discusses the need for arrows on the left and/or right of the cells which has numeral contents that can not be fit into the cell.

Previously, it was somehow odd for me when arrows were put on the left, right or both sides of the hash marks with a patch to fix tdf#129847. Why it shows arrows, even when the cell has more space to use?

I tried to find the reason why it seems strange to have something like this:

[<     ###]

And I think the problem comes from the way LibreOffice shows the hash marks: it always uses 3 hash marks, no matter what the width is. In comparison, I think using hash marks to fill the cell is a better approach.

As a user, filling the cell with hash marks gives me the feeling that there is a big content here, that does not fit.

In the end, I should add that the attached file is here to show the situation for many different situations. This does not usually happen in the real world where only a few fields may be shown this way. If you reduce the size of the cell, it will reduce to 2 or even 1 hash marks (even in LibreOffice), and I wanted to show this, in addition to other possible situations.
Comment 5 ady 2023-06-19 10:06:54 UTC
(In reply to Hossein from comment #4)
> If you reduce the
> size of the cell, it will reduce to 2 or even 1 hash marks

No, it is always 3 # marks (partially hidden in some cases, but they are there; for instance, you can see "half" # marks), and it should never be less than 3 # marks.

As I said, I agree that when the width allows for more # marks, additional # marks should be displayed as suggested in this request.
Comment 6 Eyal Rozenberg 2023-06-27 18:22:43 UTC
Agree with Hossein, filling with ##'s is better then having the arbitrary three #'s.

Now, one can perhaps conceive of some other way to indicate there is not enough space for digits, but adding #'s is definitely an improvement.

(Some other ideas: printing actual characters but switching to ### at the end; printing characters with an overlay triangle like for text; printing actual characters but with an ellipsis, i.e. ... , at the end)
Comment 7 Heiko Tietze 2023-07-06 12:48:14 UTC
We discussed the proposal in the design meeting. While some believe the hash marks clutter the UI for no good reason the other believe showing as many hashes as the column width allow like MS Excel does, adds some information about the number length. This sounds wrong and the use case is not really clear. Actually it's easier to spot three hashes than the same length as number have next to it. 

So we are obviously split into yay and nay. May the doer or the requester decide whether to resolve WF or to implement.