Issue 98924

Created attachment 59956 [details]
A Safari example of effective highlighting

Created attachment 59957 [details]
the OOo example — less legible

= See also =

Issue 97675

> Poor Cell Highlighting Contrast

Issue 71448

> Highlight colour displays differently from one chosen

i believe this is a bug, as the text is "covered" by the colour (green in Graham's example, blue on my 
system – as Graham points out, it's probably dependend on the system colour scheme with which I never 
tinkered) rather than being "highlighted". Also, In the midst of the frenzied updates I did to alleviate the 
issues in this thread (builds m37, 39, 41), my spellchecker stopped checking as I type (in any language) 
and I can't get it to work again (the spellcheckers and grammar tools show in the extension manager). 
Anyone knows how to fix this? thanks.  

pl->aw: seems they don't like your general transparent highlighting.

confirm, but works s designed.

AW: It's a feature in the ergonomy field and for most people it raises
readability. There is still the fallback to XOR when You activate HighContrast
for people who need it. The light blue is not guessed, but the current selection
color of the system (so Your Safari screenshot shows that Apple is ignoring
their own settings if the shots are taken on the same machine).

I agree that it would even be better when the 50% transparent selection would
not blend the text itself. I also know that on the mac in the style books the
selection is defined to seem to 'lay' behind the text. This is currently
technically not possible for OOo, we only can lay things above objects (without
distinguishing text and objects). This is still more pleasant than the old XOR
visualisation (and closer to the Mac definitions, too :-)). OOo is also a
multi-plattform application, so not only Mac style definitions apply.

Have You thought about that it's not only text that is selected, but also
embedded graphics? How does that look on a Mac in the Mac programs, BTW?

All in all it works as designed (and You are the first who do not like it, i got
a lot of positive feedback), so this is no defect.

Created attachment 59960 [details]
setting in appearance panel in system preferences determines the highlight colour.

Created attachment 59961 [details]
how safari highlights text+picture.

Created attachment 59962 [details]
how Indesign CS3 highlights on the same configuration.

@aw: Apple is consistent. The talk of blue was mine, but screenshot was Graham's. The appearance 
panel of the system preferences determines the highlight colour.
I presume XOR = old style, "inverted" highlighting. Being more contrasty, it is definitely easier to read 
than the current implementation in OOO. But if it can't be made to look like it is in apple apps, I 
suppose it is something we have to live with... It's not a deal-breaker. 
I sent another screenshot where you can see how it looks when text as well as image is selected (from 
safari). Out of curiosity, third screenshot, from Adobe's Indesign CS3. you can see it uses the old style, 
"inverted" highlighting. To be honest, I wasn't even aware that Indesign does it differently from let's 
say, Safari or Textedit. I did not even consciously know how it was in the old OOO (= "inverted"). But 
when OOO was changed, I immediately noticed the difference in legibility. I don't want to question that 
you got positive feedback for this change, but I certainly doubt it "raises readability". It certainly did 
not improve readibility for me! It might not be a "defect" in the sense that you designed it in this way 
(and you told us why), but it is a departure from how this feature is implemented system-wide.

AW: Thanks for the added examples and infos. I would have wondered if Apple
really was inconsistent :-)
The Safari screenshot (safari-highlight-picture.png) is very interesting. It
shows that they do the same as we do, except for main text. I write main text,
because the most interesting part is the picture description text. Is it black
without selection? Then they do the 'lay behind' hilighting really only for
'main' text. COuld You check, please?
Please let's not talk about Adobe's Indesign CS3, XOR is really no longer
feasible except for high contrast (do i understand it right that they are not
conform with the Mac rules :-)) It is simply a fact that XOR is ugly for most
and also has the worst result for the font smoothed edges. Overlaying with
transparent is better in that aspect, and most do not want to have the extreme
contrast it gives. Also (Well, not on Mac) it normally inverts everything, so
You have to guess e.g. on red text when it is selected if it is red text when
unselected. This information stays (slightly blended) with the overlayed
transparency, You can still see which color(s) the selected text has.

>but it is a departure from how this feature is implemented system-wide.

..well, on the Mac systems. Have You seen the download numbers of OOo per
System...? I see that the Mac's way to do text selection ist the best compromize
(i like it personally), but please see the relationships, too...

All in all, i hope we will one day be able to do the bestmost selection on all
Systems. Maybe we should change this task to 'Enchancement' and keep it as a
reminder when we are able to do it tme mac way on all systems (or wait until the
numbers have inverted :-)...

@ AW:
(an attachment will be sent later to demonstrate)
Actually, no, Apple doesn't do it the way you do, highlight "lays behind" all of the things. The problem 
is that the caption in the first screenshot is not in black, but 40% of RGB (102, 102, 102). The text 
itself is not black, but 20% of RGB (51, 51, 51), or 80% grey in CMYK terms. I noticed this recently on 
many websites that text is no longer "printed" as black, but as a shade of grey. I suspect the reason is 
the high-contrast LCD screens that most people use nowadays, where the contrast can be actually too 
much if not set properly... 
I am sending one example where black text is highlighted, not too good one but all of the other 
newspapers I read on the internet now have the "grey" text!
and re indesign: yes, in this sense, it probably does not follow apple guidelines. not that Adobe ever 
did :-) However, the inverted selection has no problem there with font antialiasing (smoothing of 
edges); and likewise, text in different colour is still visible as different colour. Everything is like a 
negative, so blue text becomes orange-ish, etc. I think it works rather well :-) (I can send you a 
screengrab if you like, but preferably to personal e-mail as this is getting off-topic).
I understand the business of numbers of users, downloads etc. When I said system-wide, I meant mac, 
of course. That was what I stated when I first opened this issue, which might be since merged, or 
whatever.

Created attachment 59969 [details]
highlight example #2

Apple Human Interface Guidelines: Selecting: Selections in Text
http://tinyurl.com/apple-hig-select-in-text
http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGUserI
nput/chapter_12_section_4.html#//apple_ref/doc/uid/TP30000361-TPXREF26

> When the window becomes inactive, the text should remain
> highlighted, but in the secondary color, which is a percentage of
> the original highlight color. Both Carbon and Cocoa provide a way
> to return the current highlight color, as well as other important
> colors in the user interface. Your application should use these
> defined colors in any custom controls you create, rather than
> hard-coding specific color values.

At least: 

1) when the OOo Writer window becomes inactive, I see no change in percentage; the highlight colour 
remains the same

— comparing with most other applications, for me a green highlight becomes a grey highlight; maybe 
the HIG require correction

2) when black text is selected in Writer, OOo appliation of highlight makes the text appear a different 
colour: grey

— that may be an optical illusion, but it's optical, it's how I see it ;)

At the foot of Apple's HIG pages we have the opportunity to report inaccuracies. For another page (not 
this one) I did so the other day. They're not perfect. 

In any case: m39 and m41 are 'odd ones out', appearance of highlights and underlying text is differs 
from most other applications on Mac OS X.

Summary line is updated accordingly. 

Best, 
Graham

> Apple Human Interface Guidelines: Selecting

I have fed back to Apple that there are inaccuracies. With reference to this issue 98924. 

@graham: AW has already explained that the issue of highlighting making the text grey cannot be 
solved at this point "I also know that on the mac in the style books the selection is defined to seem to 
'lay' behind the text. This is currently technically not possible for OOo, we only can lay things above 
objects (without distinguishing text and objects)". 
The business of the colour of not changing when you click away is not bothering me in the least. it is 
obvious that the method of highlighting AW used is non-standard (on Apple) and doesn't use the 
routines Apple wants applications to use, hence your problem and mine. But that same fact probably 
explains why the colour does not change when you click on another window... 
If it is indeed a "struggle" between mac-specific and ooo-cross-platform code that makes 
implementing Apple's preferred ways of doing impossible, I guess the mac has to give, and 
unfortunately, my hunch is that this will also apply to your problem with the keyboard shortcuts...

Thank you both :)

On the hunch that this could lead to extended discussion (and wishing to keep the ticket concise) I have 
spun off to 
http://n2.nabble.com/-td2276684.html addressed to discuss@ux

AW->stepank:

>Actually, no, Apple doesn't do it the way you do, highlight "lays behind" all
of the things.

But the picture itself...? And the text below it (probably not if i got You
right, it is the same gays as non-selected...?)

>I suspect the reason is the high-contrast LCD screens that most people use
nowadays, where the contrast can be actually too much if not set properly... 

One more reason against XOR and for transparence.

>However, the inverted selection has no problem there with font antialiasing
(smoothing of edges);

Problem is (when You use a screen zoomer) that e.g. ClearType uses not gray to
smooth characters (as You woud expect in the first thought), but tones of red.
Those do not fit to the inverted scheme well...

> and likewise, text in different colour is still visible as different colour.

For people who know inverted colors by mind this might be true, but i would say
for the majority of people a e.g. blue-blended red letter is still better to be
identified as red as a cyan one, isn't it...?

>Everything is like a negative, so blue text becomes orange-ish, etc. I think it
works rather well :-)

I doubt this is true for the majority of people using a ofice package, sorry :-/

Another reason to get off of XOR is that XOR of a gray near the middle of gray
cannot be separated form it's original color.

AW->grahamperrin:
Thank You for your constructive help so far. I hope You also wrote Apple at once
about Adobe's Indesign CS3, everything else would not be fair, would it :-)
I have some unreadable characters in the title, with what have You edited this
task...?
I think it will be better to rename back this task and open a new one
(enhancement, too ) for handling focus loss to have a better granularity and
overview when looking at the task titles. Please do so.

stepank => aw

> But the picture itself...? And the text below it (probably not if i got You
right, it is the same gays as non-selected...?)

the picture is a different matter and the selection is "above" or "over" thepicture, presumably because 
the picture forms a significant chunk that if it were not overlayed with selection colour, the user 
wouldn't know whether it is selected or not. Also, for picture, you either select it it or not, and your 
perception of the picture is that you already know its contents by that time (i.e. you have decided to 
select it, or to avoid it). Whereas for text, you need to see clearly what you're selecting – do you need 
another word, another letter? So I suppose that's why it is implemented the way it is: selection "under" 
the text, irrespective of its colour, and "over" the picture. 
I take all your points about the disadvantages of XOR, especially the fact that it does probably cause 
trouble with antialiasing. You prompted me to have a look at how it is actually done onscreen on my 
macbook pro, and i can see that small type, esp. in italics, is sometimes mostly composed of shades of 
blue, brown and yellow, and black plays almost no role in it! Most interesting. I also checked for Adobe 
Indesign CS3 does it, and they obviously have their own routines for font smoothing, beucase it uses 
only shades of grey! Maybe they did it this way to avoid wreaking havoc with their XOR, or because 
maybe they're Adobe and want to do things their way. Maybe it's different in CS4, but I don't have that. 
Anyway..if the highlighting could be one day changed to the way apple does it.. it would be terrific :-)

AW: OOps, sorry,
>it is the same gays as non-selected...?
is a typo and should have been of course 'grays'. Damned. My keyboard is too
bumpy, maybe :-)

@aw: 
>>AW: OOps, sorry,
it is the same gays as non-selected...?
is a typo and should have been of course 'grays'. Damned. My keyboard is too
bumpy, maybe :-)

I got that 'gays' should be 'grays' :-)
In case I haven't made made myself clear – the grays are not affected by the highlighting. It seems only 
the picture is affected by it (overlay), but the highlighting always "lies under" text being selected, 
irrespective of its colour. (Makes one wonder what it would be like if you tried to select text of the same 
colour as the highlight colour... it'd possibly disappear in the highlight?). 

Please see also issue 97672, where it is discussed to make the colors someway
configurable. Does Apple need a special way or is this issue duplicate to issue
97672?

Reset assigne to the default "issues@openoffice.apache.org".