help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: face at point


From: Eli Zaretskii
Subject: Re: face at point
Date: Tue, 19 Nov 2002 21:14:13 +0300

> Newsgroups: gnu.emacs.help
> From: Fredrik Staxeng <fstx+u@update.uu.se>
> Date: 19 Nov 2002 09:54:48 +0100
> 
> 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 agree, of course.

> I don't think that darkgreen on white does.

Well, there's no darkgreen on a tty.  Are you talking about X?

> >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. 

This has actually been done.  The purpose was to make sure that the
heuristic in tty-colors.el that decides when it is okay to map a
non-gray color to some shade of gray does its job reasonably well.

> But on tty's, I don't think that you safely can use any colors
> unless you know the background color.

Right; the default face definitions assume either black or white
background.  If a user changes her background to something else, she
will have to redefine many tty faces.

> If you assume eight fully saturated colors

[IIRC, the tty colors are not fully saturated, only their bright
varieties are.]

> 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.

We are assuming that something called "red" is at least reddish in its
appearance.  The default colors were tested on many different systems
and to the best of my knowledge, when people complained some color to
be unreadable, the color was changed.

My point was that, color definitions on tty's being intrinsically
inexact, we should expect the results to be unpleasant or even barely
readable on some systems.  The goal is to minimize the number of such
systems, but it's a hard goal.

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

Likewise.

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

Same here.

> 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.

I don't think there's such an attitude among the current maintainers,
except in those cases where it's hard to achieve agreement.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]