[GRASS-dev] Re: not quite there on fonts

[Paul Kelly]

On Sun, 13 May 2007, Michael Barton wrote:

> I'll play around with these. But maybe one of you can check to see if
> d.histogram will actually accept some kind of background color change or if
> it is hardcoded to white--so I don't waste a lot of time messing with this
> in situation where it won't work.

FWIW, I was able to achieve my desired black background for the histogram 
plot through changing three things:
* Setting $GRASS_BACKGROUNDCOLOR to 000000 in gui/tcltk/gis.m/mapcanvas.tcl
* Changing D_setup(1); to D_setup(0); in display/d.histogram/main.c
* Removing the hardcoded "background=255:255:255" in the call to g.pnmcomp 
in gui/tcltk/gis.m/mapcanvas.tcl

It's hard to say which is the most important change - all were required -
after the first change the background originally started off black, but 
the D_setup(1); erased it to white. When I changed *that* so it didn't 
erase it to white first, but plotted the histogram on top of the black 
background, the output was still white. I think that was because it was 
transparent and the transparent parts were being made white by gis.m's 
call to the g.pnmcomp command. So I had to change it too.

Something worth looking at (as Hamish hinted) might be the way D_erase(1); 
erased to the hard-coded value of GRASS_BG_COLOR. As far as I can see 
there is no way to change this without re-compiling - kind of thwarting 
the purpose of it which was presumably to make it easier to change the 
default background colour? Maybe explicit use of DEFAULT_BG_COLOR and 
DEFAULT_FG_COLOR should be replaced by a call to a function which will 
override the hardcoded default values by (yet more) environment variables 
(if present)? I guess $GRASS_BACKGROUNDCOLOR could easily enough be used 
to override DEFAULT_BG_COLOR. I'm not sure of the implications though.

That's probably too much to change now though - an option to set the 
GRASS_BACKGROUNDCOLOR environment variable and removal of the hardcoded 
background=255:255:255 in the call to g.pnmcomp might be enough for now, 
if it doesn't mess up anything else. I've got the behaviour I wanted 
anyway. Regarding d.histogram though, I'm guessing the change to the 
erasing behaviour makes it now contradict the man page which explicitly 
says:
[...]
NOTES
[...]
d.histogram does not erase the active frame before displaying output.


Paul