April 2017

S M T W T F S
      1
2345678
910111213 1415
16171819 2021 22
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
marcmagus: Me playing cribbage in regency attire (Default)
Wednesday, April 30th, 2008 12:16 am

I know there are some people out there with graphic design experience, and some people out there who spend a lot of time looking at text in a terminal window, and even some who are both. I'm looking for a little advice.

See, there's this problem with the default settings for most terminal emulators: the colors suck. I use a black background because I find it more comfortable to look at. There seem to be studies going in both directions on the dark/light background question, so I'd just as soon skip it. Most of the colors are pretty easy to read, but both blue and bright blue on black are a strain.

So I think I want to change the palette for the ANSI colors on the terminal. I've done some research (hoping to find a website which had a bunch of palettes and screen shots of them, honestly, but with no luck) and learned a bit about it, but haven't found anything really satisfactory. I think I'm going to have to roll my own.

From my research, I've come up with a few guidelines for what it should look like which seem reasonable to me. I'd value input on what I'm thinking, as well as color suggestions.

  • The ANSI colors are black, red, green, yellow, blue, magenta, cyan, and grey, plus a corresponding bright version of each (bright black is dark grey, bright grey is white).
  • Ideally, the colors should remain as true to the spec as possible, and should certainly be recognizable as those colors.
  • The colors must have sufficient contrast from black to be easily readable when text is <color>/black.
  • The colors should be readily distinguished from one another, as they're often used to convey information.
  • As often as feasible, the colors should have sufficient contrast with one another to provide readable text. At the very least, bright secondaries should be visible against their dark primary complements.
  • I am given to understand that similar perceived brightness reduces fatigue, so ideally the set of dark colors (black excluded) should be about the same perceived brightness, and the set of bright colors (dark grey excluded) should be about the same perceived brightness. I am currently looking at the W3C accessibility standard of perceived brightness, but am open to alternatives. I'm really not sure I trust the numbers I'm getting out of this. (Blue is really dark, but is it that really dark?
  • Perhaps as a result of blue being so very dark, many colors are impressively readable against it as a background, which is kind of useful. It would be nifty to be able to preserve that, though I'd accept if that's not possible.

It recently occurred to me to fiddle with my monitor brightness/contrast/whatever settings. On my work monitor, dialing contrast to max seems to make the blues more visible, but I don't know what those settings really do. Is this a good approach, or is it going to be counterproductive?

Something really needs to be done. 0x0000ff:0x000000 is only readable if I work really hard at it, and blue doesn't go any brighter without becoming less blue.

marcmagus: Me playing cribbage in regency attire (Default)
Thursday, March 20th, 2008 12:39 pm

Over the last year or so, I've spent quite a number of hours fighting with the terminfo system to get certain tools I use on assorted systems I log in to to be able to send information to the status line (usually the title bar in xterm and most other terminal emulators). This has been a struggle primarily because certain RedHat derivatives ship with a terminfo database containing a broken information file for screen (lacking definitions for tsl and fsl). I finally learned that you can augment the terminfo database with local settings in your homedir (this they got right). At this point I feel I've learned quite a bit about terminfo and its predecessor, TERMCAP, and I have a simple question:

Why the hell did we go from TERMCAP to terminfo?

terminfo stores a static database of all the capabilities of every terminal which might ever be encountered. If you use a new terminal (that is, one with an unknown name), the database must be augmented with its capabilities. Why the inflexibility? Now that I'm trying out a relatively obscure terminal emulator (rxvt-unicode), and typically run it under screen, I pretty much have to create ~/.terminfo/r/rxvt-unicode and ~/.terminfo/s/screen.rxvt-unicode on every system I connect to. And if I connect to a system which doesn't give me a homedir for some reason, I'm pretty much screwed (or have to remember to lie about what TERM I'm using before I connect).

Compare with TERMCAP. The terminal informs the login shell of its capabilities through an environment variable. This means that if it's configured with different capabilities than the stock (say I've enabled/disabled colors differently from the expectation), it can inform the system. And if it's a brand-new terminal, the system doesn't have to have heard of it. I wouldn't have to go to drop files on every system I connect to letting them know about my terminal.

Yeah, there are severe problems with the TERMCAP approach (environment variables are often limited in length), but when they reinvented the wheel to overcome the limitations, what the hell were they thinking in taking away the most useful feature, the ability for the terminal to inform anything which cares about its capabilities, rather than the system having to know about every possible terminal?

Seriously, does anybody have any insight on this?

Tags: