Issue 97672 - New transparent selection hardly visible
Summary: New transparent selection hardly visible
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: current
Hardware: All All
: P3 Trivial with 13 votes (vote)
Target Milestone: OOo 3.2
Assignee: wolframgarten
QA Contact: issues@framework
: 96268 97773 98878 101787 (view as issue list)
Depends on:
Reported: 2008-12-30 21:12 UTC by christoph
Modified: 2010-01-06 20:04 UTC (History)
7 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

Hardly sisible selection in Calc using non standard color sheme (11.93 KB, image/png)
2009-01-03 22:22 UTC, andre_l
no flags Details
Proposal for selection handling (change transparency before/after selection, add border) (50.16 KB, text/plain)
2009-07-25 12:07 UTC, christoph
no flags Details
TCS_Transparent_Selection.htm (8.62 KB, text/html)
2009-07-31 17:16 UTC, eric.savary
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description christoph 2008-12-30 21:12:25 UTC
On a user mailing list it has been mentioned that the new transparent selection
in Calc is hardly visible. Although the visualization may be altered together
with the accessibility settings, this may be an issue for many people
(especially if this kind of selection will be integrated in all/other OOo modules).

The user proposes to provide a user configuration for the visualization of
selection (inverse, transparent).

Proposal by issue reporter: Reduce the transparency of the selection slightly or
increase the thickness of the selection border lines (for high resolution
monitors, large zoom scales).

Reference (German mailing list):

Reported system: Windows (settings taken from operating system, maybe no issue
on other platforms)
Comment 1 christoph 2008-12-30 21:14:20 UTC
Additional comment: User does not use the standard color scheme in Windows.
Comment 2 andre_l 2009-01-03 22:22:47 UTC
Created attachment 59117 [details]
Hardly sisible selection in Calc using non standard color sheme
Comment 3 sunrwynn 2009-03-27 20:57:21 UTC
*** Issue 97672 has been confirmed by votes. ***
Comment 4 andreschnabel 2009-05-20 07:05:05 UTC
we now have also complaints for writer - this time that the marked text is
hardly visible. 

I'd like to see UX have a look at this and would prefere to have an option to
disable the translucent selection in all OOo applications (and switch back to
the old "ubgly but high contrast" behaviour).
Comment 5 eric.savary 2009-05-20 15:23:56 UTC
My proposal on this:

How things are visible enough/nice/ugly is depending of the user's point of view.

-> Thus the selection color should not be hard-coded as it is now but flexible.

1. Use the selection color of the system theme.

There is always complains about "OOo doesn't respect my theme": Mac OSX, Win
XP/Vista, Gnome, KDE... and so on.

Where this is possible, we should get the system color.

2. Possibility to change the color inside OOo

Like a lot of other UI colors, the Selection color should be present under
"Tools - Options - - Appearance" so that the user has the
opportunity to change that System setting in OOo for a particular work.

3. [Nice to have] Possibility to set a Transparency level under "Tools - Options
- - Appearance"

4. [Nice to have] A mix of transparency AND the good old ugly inverse video

I think the new selection has been mainly introduced for aesthetic reasons.
That's fine!
But the old inverse video selection was offering a better contrast, had more

Why not change the selected content's color (the text) when selection color and
text reach a certain contrast ratio (luminance)? So that we can ovoid black on
black, blue on blue and so on...
Comment 6 Regina Henschel 2009-05-20 16:32:59 UTC
*** Issue 101787 has been marked as a duplicate of this issue. ***
Comment 7 Regina Henschel 2009-05-20 16:39:23 UTC
*** Issue 98878 has been marked as a duplicate of this issue. ***
Comment 8 Regina Henschel 2009-05-20 16:41:30 UTC
*** Issue 97773 has been marked as a duplicate of this issue. ***
Comment 9 Regina Henschel 2009-05-20 16:49:09 UTC
*** Issue 96268 has been marked as a duplicate of this issue. ***
Comment 10 christoph 2009-05-22 13:41:30 UTC
Just a few thoughts from what I know. In my point-of-view, the implementation
itself is sub-optimal. Thus, introducing different new settings won't fix it for
the most common use-cases.

The new selections do use the "drawing layer" which is placed above all document
objects. That means that e.g. both black and white are affected and are reduced
in contrast. For light colors, this is even worse.

From my point of view, the most often reported problems could be fixed by:
* use a light colored area behind between page and all document objects (in
terms of a layer, thinking of: document background, selection marker background,
* put a semi-transparent border line on top

For the notes anchor area we will need a similar functionality. Some time ago, I
prepared some mockups how this could look like. So just for a visual comparison
(black text on white background):
Comment 11 stefan.baltzer 2009-05-26 11:00:55 UTC
Put myself on c/c.
Comment 12 eric.savary 2009-05-27 17:18:09 UTC
Reassigning for AW for implementation.
Volunteering myself as I-Team QA Member.

@AW: could please comment Christoph's last statement?
Comment 13 Mathias_Bauer 2009-06-10 10:34:08 UTC
I think the target should at least be "3.x". In case we can do it, I would like
to see that fixed even in 3.2.

The transparent selection is such a nice feature that I really don't want to see
it damaged by complaints about a few percent of situations where it doesn't work
properly or doesn't fit.
Comment 14 Armin Le Grand 2009-07-24 10:37:48 UTC
AW: Collecting comments on various annotations:

@ES: Selection color from the system is already used; most people complain about
not being system-conform enough, so i opt to not add another 'extra'-changed
color inside OOo (esp. not for 0.2% of users ever using it).

@ES: A mix of transparency AND the good old ugly inverse video selection is
technically not possible. The Inverse (XOR) defines itself by being deleted
again when applied twice; this would not work when mixing somehow with
transparence. I see no technical way to 'enhance' XOR in itself.

@ES: A fallback to the old inverse/XOR is there, it's used for HighContrast
(where it's urgently necessary)

@christophnoack: The new selections use the 'Overlay', part of DrawingLayer. As
the name suggests, it's only possible to have something 'above' the whole
visualisation, so we are technically limited here and cannot do the optimum
currently (would be to draw the selection behind text, but above graphical
objects -> leads to problems when You have graphical objects with text). The
best technically possible when being ablet to have something 'above' is a
transparent selection. So currently it will not be possibele to 'use a light
colored area behind between page and all document objects', sorry. For the
semi-transparent border line: Calc does this; this is application-dependent. SW
would have to decide if this is wanted.

What can be done now and what i suggest to do:

- Add an option to switch back to XOR independent from HighContrast, default to
use the transparent selection (i have no numbers, but my feeling is that most
people are very happy with the new selection :-)

- Add an option to control the transparency (if transparent selection is
activated). Value in percent, restricted to (10-90)% since neither no
transparence nor full transparence makes sense

- Do not add an option for another color; be system-conform and use the System's
selection color
Comment 15 yanovets 2009-07-24 11:47:59 UTC

Controlling transparency will kind of fix the problem for me. But.

Your suggestion:
- Do not add an option for another color; be system-conform and use the System's
selection color

System conformation would be great if in the theme exact color for selecting
content would be present. But usually you take some logically close color from
the system (like selected menu item background) and make text selection based on
that. And this approach fails sometimes.

You could instead use color from the system by default and give ability to
change it to different one.

But if it is too complex to implement, controlling transparency level will be
Comment 16 christoph 2009-07-25 12:06:35 UTC
@aw: Thanks for the clarification.

To be honest, I a little bit afraid to provide options for things that should
really work out of the box... So is there any chance to improve the situation
having the "overlay" only approach in mind. Currently, that means to find a
tradeoff for visibility of the selection vs. readability of the selected content.

Question: Why not introduce the border line (e.g. system themed) which could be
much darker in comparison to the selection area. If I know correctly, the
DrawingLayer is able to handle animation, so why don't we do the selection with
a certain transparency which is increased (faded) a short time after the
selection has been finished.
Proposal attached (2009-07-25_Proposal_Selection.png)
Comment 17 christoph 2009-07-25 12:07:29 UTC
Created attachment 63774 [details]
Proposal for selection handling (change transparency before/after selection, add border)
Comment 18 andreschnabel 2009-07-25 14:27:25 UTC
Idon't really understand why we need to discuss what to implement.

We have a very clear request (that splits into to parts):
1st: Some user complain that the new selection is hardly visible
2nd: Some user complain that selected content (text) is hardly visible

Both issues are caused by the new implementation which added translucency and
removed inversion for the selected contend. This caused:
a) lower contrast between selection and non-selected background
b) lower contrast between selection background and selection content

@christoph: while you suggestion will address a),it will not address b) - so
this is not a solution.

for the propsol from es:

1) use system setting
I agree

2) add option in OOo to define Selection color
this is (imo) not necessary. People did not complain about the missing color
definition bevore to OOo 3.0 - so *this* is not our problem

3) add option to control translucency level
imo not necessary - this is not what people complain about

4) mix of 3) and old xor behaviour
this would even add more complexity (and will still not address the complains)

I fully second the idea of having an option to force the old (ugly but high
contrast) XOR behaviour. 
this would adress most peoples comlaints (as they were fine with the pre 3.0
behaviour). The code should still be around, as XOR should be used in
high-contrast mode anyway (according to the spec). UI changes are minimal (just
one simple option).

Comment 19 Armin Le Grand 2009-07-27 09:44:48 UTC
AW->christophnoack, andreschnabel: Thanks for feedback. I think, the analysis:

>1st: Some user complain that the new selection is hardly visible
>2nd: Some user complain that selected content (text) is hardly visible

is the central point here. (1) can be enhanced by adding a border (as already
done in SC) for transparent mode. It also uses the selection color, but without
transparence. I would not use animation (despite we can in overlay); it's too
deflective for professional users.

(2) can be enhanced by fallback to XOR (which was indeed not removed; it's used
for HighContrast anyways), but also by adding the option to control the degree

So, i conclude:
-> Use system selection color
-> Option to fallback to XOR, default transparence
-> If XOR: Do as in 3.0: Use pure XOR
-> If transparence: Use controllable transparence (10%..90%, default 75% as
currently in SC) plus frame around merged selection (as currently in calc).

To get an impression, please take calc in 3.1 as example. (1) is supported by
the frame around the selection, (2) by a high initial transparence. For XOR
impression, just take a look at 3.0...
Comment 20 Armin Le Grand 2009-07-27 17:18:47 UTC
AW: Of course it makes more problems as thought. I have now implemented a common
OverlaySelection in svx, used from SC and SW. Wors well so far. Problem is that
SW's multiselection used multiple rings of SwSelPaintRects, so i get no clean
merge for a common, surrounding polygon, only one for each selection. Looking
for a solution...
Comment 21 Armin Le Grand 2009-07-28 18:14:15 UTC
AW: Committing first version; updating prepared spec...
Comment 22 Armin Le Grand 2009-07-30 16:15:31 UTC
AW: Made a testing session with ES, also showed OD. Both like the new SW
selection very much. Also got feedback from UFI concerning to disable the option
when it's not available for the system (same as 'use HW acceleration' and 'use
AA' do). Adding that to the spec and the code...
Comment 23 eric.savary 2009-07-31 17:16:19 UTC
Created attachment 63899 [details]
Comment 24 Armin Le Grand 2009-08-06 10:34:18 UTC
AW: All done, spec is being uploaded (es, fl), instsets are ready. Adapting target.
Comment 25 Armin Le Grand 2009-08-06 13:52:16 UTC
AW->WG: Please review. ES and UFI are involved, the spec is uploaded by FL
Comment 26 Armin Le Grand 2009-08-06 16:26:57 UTC
AW: Spec now available at 
Comment 27 eric.savary 2009-08-10 14:32:39 UTC
Verified in CWS aw075
Comment 28 Armin Le Grand 2009-08-12 17:55:35 UTC
AW: I took a look at the Mac-version and it still does not look as good as i
wanted it to. Diving deeper shows that the problem is caused by the Mac's
selection colors; e.g. the light blue which is standard, has a luminosity of 218
(!) of 255 possible. When blending this color with transparence, it cannot look
Since the same may happen when on other systems the user chooses a very light
selection/hilight color, i decided to add an upper bound to the luminosity of
the selection color. I experimented a bit, and 180 (70%) is a good value. When
the system selection color is above this max, it will be scaled down to this max
This looks good and i added the needed code. I also added (just in case) that
value as percent value (70%) to the configuration.

AW->WG: Sorry, but needs to b e re-tested. I updated all install-sets. The
difference is the seleciton on the mac. The brightness of the light blue will be
limited. On other systems, this can be checked by setting a very bright system
hilight color.
Comment 29 andreschnabel 2010-01-06 20:04:13 UTC
Ok in OOo 3.2RC1

closing, as the spec has been implemented.

I did not verify the last comment about systems using very light selection
colors (esp. Mac). Anyway - as this is not reflected in the spec and no testcase
is prepared, the current implementation seems to work as specified.

Anyway - if the current implementation differs from the spec, the spec should be