https://bugs.documentfoundation.org/show_bug.cgi?id=91415
--- Comment #8 from ady ---
(In reply to Cor Nouws from comment #7)
> (In reply to ady from comment #5)
> Is it that there may never be any overlap in the content and the indicator?
No, of course I'm not demanding that; just that the current workarounds be
still available, especially the zoom, as it is the easiest to temporarily
apply. The current change seems to prevent it.
> Or..?
> Can I see images/examples somewhere of what works and what not?
First, apologies for the long text that follows, but this matter needs clear
debate (as shown by the several bug tickets, many comments, and prior attempts
of resolutions back and forth).
I have encountered some case with the comment indicator blocking some text or
number in a cell at some point or another in my life. Usually, I am able to
overcome such situation by means of zoom. Using the zoom is something that I am
used to use frequently, for other reasons, so it is natural for me to use such
method. Other users might not even think about that, so they might think that
they have a critical UI issue. There is very little mention of using zoom in
the related bug reports (which might indicate that they don’t even try it or
think about such alternative).
Other workarounds, besides those I already mentioned, can be text alignment,
indentation and border padding (all of which I also use for cases such as
filter arrows blocking text, either within or around the boundaries of the
filtering cell).
When I saw the wording, "scale…", I went and asked Heiko Tietze in irc
#libreoffice-design, and the screenshots and video provided show that, no
matter the zoom, the resulting text is still covered by the indicator. This is
not what happens as of LO 7.4.4, in which, most frequently than not,
temporarily changing the zoom can resolve the relatively minor problem – I say
"relatively minor", because it can be easily overcome by several
currently-available methods. It is still in the hands of users.
By changing the indicator to grow when we use higher values of zoom (i.e. part
of scaling it), which is part of the change according to the screenshot that
Heiko Tietze showed me, a relatively minor problem for some users in some cases
can turn into a permanent inconvenience (especially to visually challenged
users) that has no easy workaround (because no matter the zoom, if the
indicator covers a text, it will cover it under any zoom value once the change
is committed). There will be no longer an easy workaround in the hands of users
(especially if the file is read-only, when other properties cannot be modified,
but the zoom is yet available).
Having some artifact covering some text is not an exclusive issue with the
comment indicator. There is help text showing under the mouse pointer, and/or
filter arrows, just as common examples. The user has sometimes some method to
overcome or correct the situation (e.g. for filter arrows, and for comment
indicators), but sometimes there is no workaround (e.g. mouse pointer over help
text). The resolution proposed here seems to make useless the easy workaround
currently available (as of LO 7.4.4.), and will not solve the issue really (as
shown in the screenshots that Heiko Tietze provided in irc).
For example (of what _not_ to do), making the indicator just one color (i.e.
with no border of another contrasting color) would make it smaller, but such
hypothetical change clearly clashes with using a similar background color for
the cell or for the cell’s border, so you should _not_ make the indicator
one_color_only and without its border (i.e. its border, with a different color,
must remain).
If you can make the indicator smaller but still visible (e.g. triangle, still
with a border of a different color), then that’s an improvement (in UI) that
shouldn't affect negatively other users. Perhaps if the indicator can be partly
transparent (the alpha thing that was suggested before) then both objectives
can be maintained(?): the text can be clearly seen, and the indicator can be
clearly spotted.
It is possible that just making it a triangle is enough, in which case no new
bug enhancement requests would show up (and so, going step-by-step towards a
resolution can be helpful, rather than applying several changes at one time,
risking some unnecessary negative side-effects).
Reading prior tickets (some of which I already linked to) on the same subject
and prior attempts to improve the situation, demonstrates that there is some
balance to consider, and that some changes that are centered on the comment
indicator alone can negatively affect other aspects of UI and usage. Since I
have to rely on using the zoom more often than not (and the comment indicator
is not nearly the main reason for it, by far), I am perhaps more aware than
others that using the zoom can be an easy workaround for the matter in question
in many occasions, while scaling the comment indicator seems to have
