Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Xterm and .Xresources



Derek Martin <dmartin at lancity.COM> writes:
	On Thu, 2 Sep 1999, John Chambers,,,781-647-1813 wrote:

	> 	On this machine, and on many other linuxes that
	> 	> I've used in the past few years, whenever I run  gv  it  gives  me  a
	> 	> popup complaining about about a number of missing colors:
	> 	> 
	> 	> 	Warning: Cannot allocate colormap entry for "AntiqueWhite2"
	> 	> 	Warning: Cannot allocate colormap entry for "AntiqueWhite4"
	> 	> 	Warning: Cannot allocate colormap entry for "gray90"
	> 	> 	Warning: Cannot allocate colormap entry for "#D3B5B5"
	> 
	> 	The problem, probably the most common one with X, is that your out of
	> 	color table entries.  You almost undoubtedly are running an 8-bit (256
	> 	color) display.  You can set all the resources you like, and you'll still
	> 	have the same problem.  To fix it, you need to figure out if you can run
	> 	your video card at a higher color depth (probably you can), and then use
	> 	some method to start X at the higher depth.  
	> 
	> Well, I don't believe this is quite true.  It's  probably  true  that
	> this  is  an 8-bit display.  But I don't think it's true that I can't

	I assure you that I am correct.  Your display has already allocated all
	256 entries of the color map, which is why you're getting the message
	"cannot allocate colormap entry" and your widget's colors are falling back
	to the default white.

OK; I'll stipulate that you're exactly right.  However, you're giving
the answer to a different question than the one I asked.

I'm not asking "Why can't gv get color #D3B5B5?" I  agree  that  it's
because  the  colormap  is  full.  But I can see that xterms that use
color "cyan" are successful. So "cyan" is allocated and available for
use.   If I could tell gv "Don't ask for color #D3B5B5, ask for color
"cyan", it would get the color, the color would contrast with  white,
and I'd be able to read it.  Well, maybe grey40 (the background color
of the xterms) would work better, but you get the idea.

The problem is that I don't know how to tell it to  stop  asking  for
color  #D3B5B5  and ask for one that is in use.  If I could learn the
resource names that gv is using, then the fact that I'm on a  machine
with 8-bit color wouldn't matter. I could just assign these resources
to the same set of colors that my xterms are using.

There are a lot of test machines here, many running linux on  various
sorts  of hardware.  I can't really afford (and don't have authority)
to swap the displays for better ones. But it seems that problems like
this should have simple solutions. In fact, it has one: "simply" tell
gv that this resource is to be a different color.   But  it's  simple
only if I can discover the resource name that it's asking for, and so
far, that seems to be Top Secret.

I suspect that the nice folks who brought us ghostview didn't  really
intend  that  it  not  work on an 8-bit colormap.  After all, in most
cases gv only actually needs two colors ...

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org