From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Fredrik Staxeng Newsgroups: gmane.emacs.help Subject: Re: face at point Date: 19 Nov 2002 09:54:48 +0100 Sender: help-gnu-emacs-admin@gnu.org Message-ID: <1madk63pnr.fsf@Tempo.Update.UU.SE> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037696225 11031 80.91.224.249 (19 Nov 2002 08:57:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Nov 2002 08:57:05 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18E4Bq-0002rj-00 for ; Tue, 19 Nov 2002 09:57:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18E4B9-0005EB-00; Tue, 19 Nov 2002 03:56:19 -0500 Original-Newsgroups: gnu.emacs.help Original-Lines: 229 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Original-NNTP-Posting-Host: news.update.uu.se Original-X-Trace: puffinus.its.uu.se 1037695249 news.update.uu.se (19 Nov 2002 09:40:49 +0100) Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!peer1.news.newnet.co.uk!zen.net.uk!news.nl.linux.org!humbolt.nl.linux.org!surfnet.nl!newsfeed.sunet.se!news01.sunet.se!puffinus.its.uu.se Original-Xref: shelby.stanford.edu gnu.emacs.help:107198 Original-To: help-gnu-emacs@gnu.org Errors-To: help-gnu-emacs-admin@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.help:3752 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:3752 Eli Zaretskii 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