Re: face at point

[Fredrik Staxeng]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>On 19 Nov 2002, Fredrik Staxeng wrote:
>
>> >> If that has changed to something more reasonable, could you state the
>> >> new policy?
>> >
>> >You are being unfair to the Emacs maintainers.  This issue was never
>> 
>> I was talking about faces generally, not about specificially 
>> about tty faces.
>
>Me too.  The process I described touched many standard faces, on both 
>tty's and graphic displays.

I apologize for bringing the X faces into this discussion. I think that 
the problems start there, but it is more useful to treat them as given 
when discussing tty face handling.

>> The default font-lock faces contain serveral 
>> that has too low contrast
>
>Some of them are intentional, but I suspect most aren't.  Please help us 
>make them better by reporting the specific cases to gnu.emacs.bug.

I will do that. But by intentional low contrast, surely you mean "lower
contrast used for deemphasizing", not "that text _should_ be hard to
read".

>> the GNUS default faces use italics.
>
>This should be reported to the Gnus maintainers.  I don't think Gnus 
>faces were changed at all, Emacs just uses whatever the Gnus maintainers 
>defined.  This is also true in general for the optional packages that 
>define their own cases, the only exception being (IIRC) Ediff.

They don't want reopen that can of worms.

>> Are you saying that these would be considered bugs today, rather
>> than "those complain about this are the people who are able 
>> to change this"?
>
>If the default definitions of a face make it unreadable, that's a bug 
>that should be reported, IMHO.  If the default is readable but unpleasant 
>or annoying, please report that as well, but in that case it's possible 
>that it's a matter of personal taste.

Readability is a continuum, and at what point a face becomes unreadble 
depends both on hardware, and on the user. Nobody can read 50% gray on
50% gray, some people can read 60% on 40%, and most can read 75% on 25%.
Also, it's possible, but mach harder to read such things as cyan
(#00ffff) on white.

I think default faces should use colors that, on most hardware,
result in high enough contrast to be easily readable by the vast
majority of users. I don't think that darkgreen on white does.

>> >Are we talking about a tty?  If so, you have only 8 colors to choose
>> >from, on most tty types, so I don't see how could Emacs consider
>> >shades that depend on a weight.
>> 
>> That was one possible explanation why one face might work on 
>> black-on-white, but not black-on-white.
>
>You mean "white-on-black", yes?

Of course.

>> When I look at a computer screen and compare the impression from
>> the same face white-on-black versus black-on-white, I get the
>> imression that white-on-black is heavier than white-on-black 
>> one.
>
>Are you suggesting that black-on-white faces use larger weight on 
>displays that support this?  If so, how much heavier?

No, that the same face in the same pixel rendering appear heavier
when white-on-black. It would say 20%, but you would have to 
test this on several people to get a good number for general use.

>> >> Pick default colors from a defined color map, e.g. the Netscape cube.
>> >> Define a static mapping from those 216 colors to the EGA colors
>> >> that PC consoles support. Provide a color-restriction option to 
>> >> Emacs so that maintainers can easily test the effect of the color
>> >> limitation.
>> >
>> >If I understand correctly what you are suggesting, this has been done
>> >already (although some parts, like the color restricting option, only
>> >exist in the CVS, not in the released versions).
>> 
>> Presently, it's obvious that default colors are picked from rgb.txt.
>> Names like LightGoldenRod...  I am suggesting that the should be of the
>> form '#xxyyzz' instead, where xx = 00, 33, 66, 99, cc, ff.
>
>Assuming we are talking about tty's, why is this important?  On a tty, 
>Emacs translates a color name into an equivalent of #xxyyzz using a 
>built-in list (see tty-colors.el), so using names and #xxyyzz gives the 
>same result.  The names of the default colors are chosen so that the 
>result of their translation give what we consider to be a reasonably good 
>and readable appearance; doing the same with RGB won't change anything.

216 mappings are reasonable to test. It's easy to verify where the
boundaries between colors are, which color that get mapped to black,
and which get mapped to the primary. 

Of course, I was thinking about X colors when I wrote that. I have
just done some work to a program of mine to get it to work reasonably
on eight-bit pseudocolor displays, while working good on 24-bit
displays.

But on tty's, I don't think that you safely can use any colors
unless you know the background color. Perhaps ANSI color 1 (red)
is readable for everybody. Green (2) and blue (4) ar often 
actually colors that are too bright to usable on a white background.

If you assume eight fully saturated colors, and white background,
you can use red, green,  and blue as foregrounds, and yellow,
cyan and magenta as backgrounds. On a black background, you can
use all six as foreground colors. (The color names above actually
refer to the ANSI color numbers)

If you assume EGA colors, and black background, you can use many
more combinations. 

>> I had a look at the Lisp code in 21.2, and I didn't see any static
>> mapping. The mapping seemed to be dynamic, considering only the
>> color itself, and not the one is was supposed in contrast to.
>
>Sorry, I don't understand the problem, as this description is too terse 
>for me.  Could you please elaborate?

I can easily imagine cases that are reasonable contrast on X, but gets
mapped into very low contrast on tty:s.

>> >Finally, the tty-color code supports character-mode displays that are
>> >not based on EGA (nor VGA) devices (e.g., xterm), so using EGA colors
>> >slightly differently on each text terminal.  This makes the job of
>> >getting readable faces much harder.
>> 
>> Theoretically there is no standard, but in practice there is.
>> Almost all people having colors on their tty are running:
>> a) console mode on Linux/*BSD, in case they have the EGA colors, 
>> b) or they are running in a xterm, which in fact tries to be use the 
>>    same colors as EGA. Many people (including me) have changed those
>>    to the six fully saturated colors.
>
>AFAIK, Unix consoles use an SVGA nowadays, not an EGA.  SVGA has slightly 
>different color definitions, IIRC.

Yes, but they are close enough that the same foreground/background
combinations can be used in most cases. The combinations that give
problems are mostly the ones that you should avoid for other reasons.

To give an example, with letters on blue background does not work 
with all blue colors. But it's imperative that this works on 
PC video cards, since Microsoft's installation programs uses that.

>Moreover, SVGA can be programmed at startup to use different palette 
>colors.  Even more important, no two SVGAs (or EGAs, for that matter) 
>have the same default colors.  Just put two consoles of two different 
>vendors side by side and observe.
>
>So text-mode colors _are_ different.  I've seen more than a single case 
>where a color combination that looked very readable on my VGA was 
>reported as barely readable on someone else's.

Yes, if skate on thin ice, you are bound to fall into the water sometimes.
That pair is probably too low contrast for some people even on your 
screen, but in anycase, it is best avoided in a default configuration.

>Enter xterm and its ilk: not only do these have different default 
>definitions of the 16 colors (e.g., compare xterm with rxvt), but they 
>are _configurable_ on the user level!  Even if we discard the 
>unreasonable cases whereby someone defines "green" as #ffffff, there's 
>still a very large range of reasonable definitions, and some people 
>actually do this.

I changed my colors because the EGA colors are not readable on a 
white background. That was a way of making Emacs color handling work
for me.

If you are not willing to assume anything about the colors corresponding
to the ANSI color numbers, then you can't use color at all. Conversely,
if you are using color, you are assuming some things. 

I think that EGA colors is reasonable assumption. I also think that
EGA/SVGA colors are compatible enough to give reasonable number of
widely usable combinations. 

>> >> Looking good is a much more ambitious goal. I'll settle for readable.
>> >
>> >That's our goal as well.
>> 
>> But the description "look good" keeps kreeping in when the issue is
>> readability.
>
>Well, that's because we would like to have both ;-)

That's OK when used in a positive sense. But as a response to "these
colors are unreadable", it's not good to say "that's a matter of user
preference".

>Of course, readability is more important that "looking good", at least 
>IMHO.

If we have to choose between looking better on some hardware, versus
being readable on wider range of hardware, I vote for the second.

If we have to choose between looking better, versus being readable for
more users, I most definitely vote for the second. 

>> And finally, looking at the default colors in e.g.
>> font-lock, it's obvious to me that the Emacs maintainers don't really
>> understand these issues. 
>
>That remark doesn't really help.  For starters, it doesn't tell the 
>maintainers how to do better.  And I already said that the current 
>defaults were subject to prolonged discussions and several phases of 
>improvements.  It would help much more to hear specific suggestions for 
>improvement (these are better posted to emacs-devel@gnu.org).

No, I know it doesn't help. It's just the frustration trying to explain
problems to people who personally can't see it. I try to propose solutions
that work for both them and me, and it is very frustrating to have 
these efforts dismissed with "you can change it if you don't like the
default". This is what is known as not getting it.

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr