Re: face at point

[Fredrik Staxeng <fstx+u@update.uu.se>]

Miles Bader <miles@lsi.nec.co.jp> writes:

>Tim Cross <tcross@nospam.une.edu.au> writes:
>> > Note that emacs explicitly knows about this issue and maintains separate
>> > dark-background defaults for many faces, so any default face that's not
>> > readable on a dark background is a bug, so please report if you can.
>> 
>> Well...I guess in theory that should work, but my experience has been
>> that a number of faces are difficult to read when you use a dark
>> (black) background - in particular, there are a number of faces which
>> use variants of blue (navy, darker blue etc) and red or dark red which
>> are difficult to read. I found this under both X and console.
>
>Then they are broken; please report them as bugs.  I use a dark
>background myself, and fix anything I see, but of course I don't use
>every feature in emacs.

I am old enough to have a preference for amber phosphor over green.
Today I run using black text on white background. But I still find
that many of the default faces are nearly unreadable.

From the previous flaming over subject I have gotten the impression
that the Emacs maintainers prefer to treat this as a user preference
issue. 

If that has changed to something more reasonable, could you state the
new policy? Is is something like "the default faces should be easily 
readable for 95% of the users on 99% percent of the hardware/operating
system combinations out there."?

Otherwise there seems to be little point in reporting unreadable
faces as bugs. Obviously the author could read the face on his
screen.

>> I'm not sure there is a lot which can be done here though - there are
>> quite a few different faces and many of them are not very good with a
>> dark backgroun, so I think the choice for default dark background face
>> foreground colours are limited.
>
>Um, why does that matter?  If the set of foreground colors that contrast
>well is limited, then the foreground colors should be chosen from that
>set.  Of course, in some cases, the right choice is to set both the face
>background _and_ foreground.


A face with higher weight (% covered by foreground paint) needs less
color contrast than one with lower weight. Also, it seems to me, that
on CRT:s, bright colors bleed into less bright ones. This makes a
white face on black background than the same black-on-white.

One person I know prefer 1280x1024 to 1600x1280 because the higher 
resolution makes his fonts to thin, even when he chooses a bigger
font to make the apparent size the same.

>> I did find under the console, some colours just didn't show up right,
>> but expect thats a result of the limited colours available under the
>> console.
>
>Yes, this is a common problem, and hard to solve perfectly.

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.

No, it's not perfect. Perfect color support takes 24 bits. There 
is no way around that. But I think the above would be good enough.

>However, emacs _does_ attempt to deal with it, and in some cases uses
>different default faces for terminals [the console being a terminal],
>if same face just can't be made to look good on both window-systems and
>terminals.

Looking good is a much more ambitious goal. I'll settle for readable.

By the way, I found a way to get the rgb components from a color in Emacs.
Is there a way to make a color from three RGB values? The idea is to
take the color apart, scale the components to make the color darker,
and then put a set-face-forground in my .emacs.

Since it this time of the year, let me add a wish for a lisp hook
to be run when a face is realized, where I could put a function
that simply changes things to the way I want them.

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