[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: face at point
From: |
Fredrik Staxeng |
Subject: |
Re: face at point |
Date: |
19 Nov 2002 07:02:26 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 |
"Eli Zaretskii" <eliz@is.elta.co.il> writes:
>> Newsgroups: gnu.emacs.help
>> From: Fredrik Staxeng <fstx+u@update.uu.se>
>> Date: 18 Nov 2002 14:48:26 +0100
>>
>> 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?
>
>You are being unfair to the Emacs maintainers. This issue was never
I was talking about faces generally, not about specificially
about tty faces. The default font-lock faces contain serveral
that has too low contrast, the GNUS default faces use italics.
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"?
>> A face with higher weight (% covered by foreground paint) needs less
>> color contrast than one with lower weight.
>
>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.
>If we are talking about X, it sounds like you are suggesting a
>mechanism to dynamically change the default faces as function of the
>display and font parameters. That might be a good idea; please
>suggest it to emacs-devel@gnu.org.
I am explaining to you and Miles how _humans_ work, in this case
human perception of letter forms rendered on a computer screen.
>> 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.
>
>Sorry, I cannot parse these two sentences; please elaborate.
I missed an adjective there. But for Gutenberg, letters
got heavier in printing because ink bled into the white areas.
When technology changed in the seventies, the printing industry
had to make the faces heavier to compensate for the less
bleeding of the new technology.
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.
>> 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.
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.
This means surprises are bound to happen.
>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.
If you try xterm -fg '#ffff00' -bg '#ffffff', and test all 6 colors,
you will see that only three combinations have enough contrast.
If you try it with black background, again there are 3 good
combinations.
The EGA colors contrast well. I don't think this is an accident.
>> 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. These things are are often described as user
preferences. 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.
--
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr
- Re: face at point, (continued)
- Message not available
Re: face at point, Tim Cross, 2002/11/17
- Re: face at point, Miles Bader, 2002/11/17
- Re: face at point, Tim Cross, 2002/11/18
- Re: face at point, Miles Bader, 2002/11/18
- Message not available
- Re: face at point, Fredrik Staxeng, 2002/11/18
- Re: face at point, Oliver Scholz, 2002/11/18
- Re: face at point, Fredrik Staxeng, 2002/11/18
- Re: face at point, Eli Zaretskii, 2002/11/18
- Message not available
- Re: face at point,
Fredrik Staxeng <=
- Re: face at point, Eli Zaretskii, 2002/11/19
- Re: face at point, Miles Bader, 2002/11/19
- Re: face at point, Kai Großjohann, 2002/11/19
Message not availableRe: face at point, Tim Cross, 2002/11/18
Re: face at point, Jesper Harder, 2002/11/18
Re: face at point, Miles Bader, 2002/11/18
Re: face at point, Miles Bader, 2002/11/18
Re: face at point, Eli Zaretskii, 2002/11/19
Message not availableRe: face at point, Tim Cross, 2002/11/19
Re: face at point, Eli Zaretskii, 2002/11/19