[GRASS5] [bug #4066] (grass) gis.m: black background

GRASS GIS GRASS GIS developer
1

this bug's URL: http://intevation.de/rt/webrt?serial_num=4066
-------------------------------------------------------------------------

Subject: gis.m: black background

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs_head_20060207

I can confirm the problem with the back blackground in gis.m which Maciek mentioned as a side note in another bug report (http://intevation.de/rt/webrt?serial_num=4049&display=History).

When I erase the map display the background becomes white, but as soon as I display a map it becomes black again.

Moritz

-------------------------------------------- Managed by Request Tracker

2

Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=4066
-------------------------------------------------------------------------

Subject: gis.m: black background

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs_head_20060207

I can confirm the problem with the back blackground in gis.m which

Maciek mentioned as a side note in another bug report
(http://intevation.de/rt/webrt?serial_num=4049&display=History).

When I erase the map display the background becomes white, but as soon as I display a map it becomes black again.

Maybe this might help in identifying the problem:

A setting in the gis manager resulting in the command does not show anything, i.e. not white boundaries on black background as it should.

d.vect map=eurnuts3 color=255:255:255 lcolor=0:0:0 fcolor=none display=shape type=point,line,boundary,area icon=basic/x size=5 layer=1 lsize=8 xref=left yref=center llayer=1

However,

d.vect map=eurnuts3 color=255:0:0 lcolor=0:0:0 fcolor=none display=shape type=point,line,boundary,area icon=basic/x size=5 layer=1 lsize=8 xref=left yref=center llayer=1

does show red boundaries on the black background...

Moritz

3

I cannot reproduce this. Perhaps I don't understand the problem.

See comments below.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Tue, 07 Feb 2006 14:03:27 +0100
To: Request Tracker <grass-bugs@intevation.de>
Cc: <grass5@grass.itc.it>
Subject: Re: [GRASS5] [bug #4066] (grass) gis.m: black background

Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=4066
-------------------------------------------------------------------------

Subject: gis.m: black background

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs_head_20060207

I can confirm the problem with the back blackground in gis.m which

Maciek mentioned as a side note in another bug report
(http://intevation.de/rt/webrt?serial_num=4049&display=History).

When I erase the map display the background becomes white, but as soon as I
display a map it becomes black again.

Maybe this might help in identifying the problem:

A setting in the gis manager resulting in the command does not show
anything, i.e. not white boundaries on black background as it should.

d.vect map=eurnuts3 color=255:255:255 lcolor=0:0:0 fcolor=none
display=shape type=point,line,boundary,area icon=basic/x size=5 layer=1
lsize=8 xref=left yref=center llayer=1

This only sets the line color to white. It has no effect on the background.
If you don't change the background (use 'd.erase black' as a command layer,
for example), you'll get white on white. The default background was changed
from black to white when we went from GRASS 5 to GRASS 6. So this is
behaving correctly.

As I said, however, you can change the background with d.erase

However,

d.vect map=eurnuts3 color=255:0:0 lcolor=0:0:0 fcolor=none display=shape
type=point,line,boundary,area icon=basic/x size=5 layer=1 lsize=8
xref=left yref=center llayer=1

does show red boundaries on the black background...

On my system, this makes red lines on a white background.

Keep in mind a couple things.

1) I'm only doing this from the GIS Manager, not from the command line. d.*
commands will give unpredictable results (or won't work at all) from the
command line in the new GIS Manager because I'm no longer using x11
displays.

2) I'm working with a Mac binary from 21 January. It's possible that the
recent changes to the display drivers are causing the background to go to
black. Anyone want to hazard a guess on this??

Michael

Moritz

4

On Tue, February 7, 2006 19:26, Michael Barton wrote:

Subject: gis.m: black background

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs_head_20060207

I can confirm the problem with the back blackground in gis.m which

Maciek mentioned as a side note in another bug report
(http://intevation.de/rt/webrt?serial_num=4049&display=History).

When I erase the map display the background becomes white, but as soon
as I
display a map it becomes black again.

Maybe this might help in identifying the problem:

A setting in the gis manager resulting in the command does not show
anything, i.e. not white boundaries on black background as it should.

d.vect map=eurnuts3 color=255:255:255 lcolor=0:0:0 fcolor=none
display=shape type=point,line,boundary,area icon=basic/x size=5 layer=1
lsize=8 xref=left yref=center llayer=1

This only sets the line color to white. It has no effect on the
background.
If you don't change the background (use 'd.erase black' as a command
layer,
for example), you'll get white on white. The default background was
changed
from black to white when we went from GRASS 5 to GRASS 6. So this is
behaving correctly.

As I said, however, you can change the background with d.erase

As I said in the original bug report: "When I erase the map display the
background becomes white, but as soon as I display a map it becomes black
again.". So my problem in the above case is not that I get white on white,
but that I have a black background (which I cannot get rid of), but that
when I try to display a vector map with color set to white, it doesn't
show as it should (white on black). The map does show, however, when I
change color to any other value (red, green, blue, etc)

Something is wrong with the map display...

However,

d.vect map=eurnuts3 color=255:0:0 lcolor=0:0:0 fcolor=none display=shape
type=point,line,boundary,area icon=basic/x size=5 layer=1 lsize=8
xref=left yref=center llayer=1

does show red boundaries on the black background...

On my system, this makes red lines on a white background.

Keep in mind a couple things.

1) I'm only doing this from the GIS Manager, not from the command line.
d.*
commands will give unpredictable results (or won't work at all) from the
command line in the new GIS Manager because I'm no longer using x11
displays.

I used the GIS Manager.

2) I'm working with a Mac binary from 21 January. It's possible that the
recent changes to the display drivers are causing the background to go to
black. Anyone want to hazard a guess on this??

I guess this must be linked somehow... Could that be possible, Glynn ?

Moritz

5

Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=4066
-------------------------------------------------------------------------

Subject: gis.m: black background

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs_head_20060207

I can confirm the problem with the back blackground in gis.m which
Maciek mentioned as a side note in another bug report
(http://intevation.de/rt/webrt?serial_num=4049&display=History).

When I erase the map display the background becomes white, but as
soon as I display a map it becomes black again.

I've just fixed a bug related to the background colour in the PNG
driver; pngdriver.h had "unsigned int background" rather than
"extern unsigned int background", so each source file had its own
"background" variable, most of which would be implicitly initialised
to zero and remain at zero.

BTW, while most of the changes were simply reorganisation, and didn't
affect any functionality (or, at least, weren't meant to), the PNG
driver's implementation of R_erase() has been changed to erase to the
original background colour (which will be transparent if
GRASS_TRANSPARENT is set to TRUE), not the current colour.

This affects the behaviour of "d.erase -f" and "d.frame -e".
Previously, there was no way to erase to transparent after
initialisation.

--
Glynn Clements <glynn@gclements.plus.com>

6

Hallo,
is this problem solved or not? Fresh cvs from today, the background
under vector file is black :-/

jachym

On Tue, Feb 07, 2006 at 09:24:06PM +0000, Glynn Clements wrote:

Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=4066
> -------------------------------------------------------------------------
>
> Subject: gis.m: black background
>
> Platform: GNU/Linux/x86
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> GRASS Version: cvs_head_20060207
>
> I can confirm the problem with the back blackground in gis.m which
> Maciek mentioned as a side note in another bug report
> (http://intevation.de/rt/webrt?serial_num=4049&display=History).
>
> When I erase the map display the background becomes white, but as
> soon as I display a map it becomes black again.

I've just fixed a bug related to the background colour in the PNG
driver; pngdriver.h had "unsigned int background" rather than
"extern unsigned int background", so each source file had its own
"background" variable, most of which would be implicitly initialised
to zero and remain at zero.

BTW, while most of the changes were simply reorganisation, and didn't
affect any functionality (or, at least, weren't meant to), the PNG
driver's implementation of R_erase() has been changed to erase to the
original background colour (which will be transparent if
GRASS_TRANSPARENT is set to TRUE), not the current colour.

This affects the behaviour of "d.erase -f" and "d.frame -e".
Previously, there was no way to erase to transparent after
initialisation.

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/
-----------------------------------------
OFFICE:
Department of Geoinformation Technologies
LDF MZLU v Brnì
Zemìdìlská 3
613 00 Brno
e-mail: xcepicky@node.mendelu.cz
URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

7

Jachym Cepicky wrote:

> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4066
> > -------------------------------------------------------------------------
> >
> > Subject: gis.m: black background
> >
> > Platform: GNU/Linux/x86
> > grass obtained from: CVS
> > grass binary for platform: Compiled from Sources
> > GRASS Version: cvs_head_20060207
> >
> > I can confirm the problem with the back blackground in gis.m which
> > Maciek mentioned as a side note in another bug report
> > (http://intevation.de/rt/webrt?serial_num=4049&display=History).
> >
> > When I erase the map display the background becomes white, but as
> > soon as I display a map it becomes black again.
>
> I've just fixed a bug related to the background colour in the PNG
> driver; pngdriver.h had "unsigned int background" rather than
> "extern unsigned int background", so each source file had its own
> "background" variable, most of which would be implicitly initialised
> to zero and remain at zero.
>
> BTW, while most of the changes were simply reorganisation, and didn't
> affect any functionality (or, at least, weren't meant to), the PNG
> driver's implementation of R_erase() has been changed to erase to the
> original background colour (which will be transparent if
> GRASS_TRANSPARENT is set to TRUE), not the current colour.
>
> This affects the behaviour of "d.erase -f" and "d.frame -e".
> Previously, there was no way to erase to transparent after
> initialisation.

is this problem solved or not? Fresh cvs from today, the background
under vector file is black :-/

I had already committed that fix when I wrote the message; I haven't
changed anything relevant since.

Under what circumstances does the problem arise? Only with the PNG
driver, or also with XDRIVER? Are you setting any of the GRASS_*
environment variables.

--
Glynn Clements <glynn@gclements.plus.com>

8

On Mon, Feb 13, 2006 at 03:59:19PM +0000, Glynn Clements wrote:

Jachym Cepicky wrote:

> > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4066
> > > -------------------------------------------------------------------------
> > >
> > > Subject: gis.m: black background
> > >
> > > Platform: GNU/Linux/x86
> > > grass obtained from: CVS
> > > grass binary for platform: Compiled from Sources
> > > GRASS Version: cvs_head_20060207
> > >
> > > I can confirm the problem with the back blackground in gis.m which
> > > Maciek mentioned as a side note in another bug report
> > > (http://intevation.de/rt/webrt?serial_num=4049&display=History).
> > >
> > > When I erase the map display the background becomes white, but as
> > > soon as I display a map it becomes black again.
> >
> > I've just fixed a bug related to the background colour in the PNG
> > driver; pngdriver.h had "unsigned int background" rather than
> > "extern unsigned int background", so each source file had its own
> > "background" variable, most of which would be implicitly initialised
> > to zero and remain at zero.
> >
> > BTW, while most of the changes were simply reorganisation, and didn't
> > affect any functionality (or, at least, weren't meant to), the PNG
> > driver's implementation of R_erase() has been changed to erase to the
> > original background colour (which will be transparent if
> > GRASS_TRANSPARENT is set to TRUE), not the current colour.
> >
> > This affects the behaviour of "d.erase -f" and "d.frame -e".
> > Previously, there was no way to erase to transparent after
> > initialisation.
>
> is this problem solved or not? Fresh cvs from today, the background
> under vector file is black :-/

I had already committed that fix when I wrote the message; I haven't
changed anything relevant since.

Under what circumstances does the problem arise? Only with the PNG
driver, or also with XDRIVER? Are you setting any of the GRASS_*
environment variables.

I got the following suggestion from Michael which helped:

On Fri, Feb 10, 2006 at 08:51:46AM -0700, Michael Barton wrote:

I think you need to set GRASS_TRANSPARENT to FALSE in mapcanvas.tcl.

I don't know if that's in CVS now.

Markus

9

I think (hope) this is fixed in the gism2 version I just released. It
doesn't affect my Mac, so I can't test it.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Mon, 13 Feb 2006 17:10:24 +0100
To: Glynn Clements <glynn@gclements.plus.com>
Cc: Jachym Cepicky <jachym.cepicky@centrum.cz>, Request Tracker
<grass-bugs@intevation.de>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] [bug #4066] (grass) gis.m: black background

On Mon, Feb 13, 2006 at 03:59:19PM +0000, Glynn Clements wrote:

Jachym Cepicky wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=4066
-------------------------------------------------------------------------

Subject: gis.m: black background

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs_head_20060207

I can confirm the problem with the back blackground in gis.m which
Maciek mentioned as a side note in another bug report
(http://intevation.de/rt/webrt?serial_num=4049&display=History).

When I erase the map display the background becomes white, but as
soon as I display a map it becomes black again.

I've just fixed a bug related to the background colour in the PNG
driver; pngdriver.h had "unsigned int background" rather than
"extern unsigned int background", so each source file had its own
"background" variable, most of which would be implicitly initialised
to zero and remain at zero.

BTW, while most of the changes were simply reorganisation, and didn't
affect any functionality (or, at least, weren't meant to), the PNG
driver's implementation of R_erase() has been changed to erase to the
original background colour (which will be transparent if
GRASS_TRANSPARENT is set to TRUE), not the current colour.

This affects the behaviour of "d.erase -f" and "d.frame -e".
Previously, there was no way to erase to transparent after
initialisation.

is this problem solved or not? Fresh cvs from today, the background
under vector file is black :-/

I had already committed that fix when I wrote the message; I haven't
changed anything relevant since.

Under what circumstances does the problem arise? Only with the PNG
driver, or also with XDRIVER? Are you setting any of the GRASS_*
environment variables.

I got the following suggestion from Michael which helped:

On Fri, Feb 10, 2006 at 08:51:46AM -0700, Michael Barton wrote:

I think you need to set GRASS_TRANSPARENT to FALSE in mapcanvas.tcl.

I don't know if that's in CVS now.

Markus