From: Fredrik Staxeng <fstx+u@update.uu.se>
Subject: Re: face at point
Date: 19 Nov 2002 07:02:26 +0100 [thread overview]
Message-ID: <1mptt2drm5.fsf@Tempo.Update.UU.SE> (raw)
In-Reply-To: mailman.1037646827.31512.help-gnu-emacs@gnu.org
"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
next prev parent reply other threads:[~2002-11-19 6:02 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-15 2:13 face at point John Hunter
2002-11-15 2:50 ` Jesper Harder
2002-11-15 3:30 ` John Hunter
2002-11-15 3:40 ` Jesper Harder
2002-11-15 10:24 ` Oliver Scholz
2002-11-15 13:37 ` Jesper Harder
2002-11-15 14:51 ` Jesper Harder
2002-11-15 16:58 ` Oliver Scholz
2002-11-16 18:49 ` Kai Großjohann
2002-11-15 4:24 ` Miles Bader
[not found] ` <mailman.1037335988.3983.help-gnu-emacs@gnu.org>
2002-11-15 14:21 ` Michael J Downes
2002-11-15 14:31 ` John Hunter
2002-11-17 22:40 ` Tim Cross
2002-11-17 23:00 ` Miles Bader
2002-11-18 5:54 ` Tim Cross
2002-11-18 8:52 ` Miles Bader
[not found] ` <mailman.1037610573.27378.help-gnu-emacs@gnu.org>
2002-11-18 13:48 ` Fredrik Staxeng
2002-11-18 17:23 ` Oliver Scholz
2002-11-18 18:16 ` Fredrik Staxeng
2002-11-18 17:56 ` Eli Zaretskii
[not found] ` <mailman.1037646827.31512.help-gnu-emacs@gnu.org>
2002-11-19 6:02 ` Fredrik Staxeng [this message]
2002-11-19 6:47 ` Eli Zaretskii
2002-11-19 9:20 ` Miles Bader
2002-11-19 20:24 ` Kai Großjohann
2002-11-18 22:06 ` Tim Cross
2002-11-18 22:36 ` Jesper Harder
2002-11-19 2:00 ` Miles Bader
2002-11-19 1:55 ` Miles Bader
2002-11-19 5:31 ` Eli Zaretskii
[not found] ` <mailman.1037671096.385.help-gnu-emacs@gnu.org>
2002-11-19 5:58 ` Tim Cross
2002-11-19 6:24 ` Eli Zaretskii
2002-11-19 6:24 ` Fredrik Staxeng
2002-11-19 6:56 ` Eli Zaretskii
2002-11-19 8:56 ` Miles Bader
[not found] ` <mailman.1037696237.22239.help-gnu-emacs@gnu.org>
2002-11-19 9:46 ` Fredrik Staxeng
[not found] <mailman.1037688495.14173.help-gnu-emacs@gnu.org>
2002-11-19 8:54 ` Fredrik Staxeng
2002-11-19 18:14 ` Eli Zaretskii
[not found] ` <mailman.1037733383.18353.help-gnu-emacs@gnu.org>
2002-11-20 13:37 ` Fredrik Staxeng
2002-11-20 16:13 ` Eli Zaretskii
[not found] ` <mailman.1037812462.4160.help-gnu-emacs@gnu.org>
2002-11-20 17:56 ` Fredrik Staxeng
[not found] <mailman.1037687132.614.help-gnu-emacs@gnu.org>
2002-11-19 22:16 ` Tim Cross
2002-11-20 5:47 ` Eli Zaretskii
2002-11-20 11:06 ` Oliver Scholz
2002-11-20 14:01 ` Stefan Monnier <foo@acm.com>
2002-11-20 16:00 ` Michael Slass
[not found] <mailman.1037771296.12946.help-gnu-emacs@gnu.org>
2002-11-20 7:34 ` Miles Bader
2002-11-20 7:39 ` Kai Großjohann
[not found] ` <mailman.1037777785.20916.help-gnu-emacs@gnu.org>
2002-11-20 11:10 ` Oliver Scholz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1mptt2drm5.fsf@Tempo.Update.UU.SE \
--to=fstx+u@update.uu.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.