[GRASS5] rgb color support in ps.map ?

GRASS GIS GRASS GIS developer
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

what is the status of RGB color support in ps.map ?
Can one use rgb codes for all elements, some elements or none ?
If not for all, it there a specific reason for this other than
"just" having to adapt the code to mirror those elements which
support it ?

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDFGeDrIrMbm76jD8RAqayAKCB6sOEQRRO2OaXVrcfgRqDNQLVyACfSo+Z
E3BMptcZEJtCqcs5nmX/0Uk=
=Y7sC
-----END PGP SIGNATURE-----

2

what is the status of RGB color support in ps.map ?
Can one use rgb codes for all elements, some elements or none ?

rrr:ggg:bbb color naming works for some features not for others.
Generally, vector drawing instructions (by Radim) support it, others
(legacy commands) may or may not at about 50/50 odds.

If not for all, it there a specific reason for this other than
"just" having to adapt the code to mirror those elements which
support it ?

For the parts I've modified, I've (mostly) only added it where I needed
it. If there is a specific command which you are desperate to have it
work with let us know so we can focus on that first.

Hamish

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hamish wrote:

what is the status of RGB color support in ps.map ?
Can one use rgb codes for all elements, some elements or none ?

rrr:ggg:bbb color naming works for some features not for others.
Generally, vector drawing instructions (by Radim) support it, others
(legacy commands) may or may not at about 50/50 odds.

If not for all, it there a specific reason for this other than
"just" having to adapt the code to mirror those elements which
support it ?

For the parts I've modified, I've (mostly) only added it where I needed
it. If there is a specific command which you are desperate to have it
work with let us know so we can focus on that first.

I wouldn't call myself "desperate" ;-), but in the effort of
creating a ps.map version of the legend created by d.vect.thematic
it would be necessary for the rectangle object...

I also think that ideally ps.map should have a consistent behaviour
across all elements, but that's easy to say while I depend on other
to do it :wink:

You can also try to briefly explain what needs to be done, and I'll
have a first attempt at doing it myself...

Thanks,
Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDFb24rIrMbm76jD8RAoKYAJ0QFRawb1q62Q6XdSQQC6JCJa5dHgCcCv5h
jlgDJpjgWNA1yM9Xc7uECVg=
=+200
-----END PGP SIGNATURE-----

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paolo,
(cc to developers list)

Paolo Cavallini wrote:

Sorry Moritz, but why you struggle with ps.map?
Qgis' map composer is so convenient and fast...

I wouldn't call it struggling, but rather trying to improve things ;-).

I don't doubt that QGIS and its composer is (or at least will be) a
very useful tool. (Personally, I have trouble doing what I want with
it, but that's most probably do to my lack of knowledge about
it...). For many people this will in fact currently be the easiest
to use solution.

However, at several occasions it has become clear that for different
reasons not all users want to depend on an external tool such as
Qgis, but want an internal GRASS GUI and useful internal GRASS tools
for map making (see results of the users survey in Number 2 of the
newsletter, for example.)

d.vect.thematic was an important step in this direction. All I'm
trying to do is to scratch some itches which come up while using it.

I imagine that if the swig interface route is successful (see
http://grass.itc.it/pipermail/grass5/2005-August/019435.html), then
we will see many more solutions pop up...

All the best,

Moritz

All the best.
pc

At 16:24, mercoledì 31 agosto 2005, Moritz Lennert has probably written:

Hamish wrote:

what is the status of RGB color support in ps.map ?
Can one use rgb codes for all elements, some elements or none ?

rrr:ggg:bbb color naming works for some features not for others.
Generally, vector drawing instructions (by Radim) support it, others
(legacy commands) may or may not at about 50/50 odds.

If not for all, it there a specific reason for this other than
"just" having to adapt the code to mirror those elements which
support it ?

For the parts I've modified, I've (mostly) only added it where I needed
it. If there is a specific command which you are desperate to have it
work with let us know so we can focus on that first.

I wouldn't call myself "desperate" ;-), but in the effort of
creating a ps.map version of the legend created by d.vect.thematic
it would be necessary for the rectangle object...

I also think that ideally ps.map should have a consistent behaviour
across all elements, but that's easy to say while I depend on other
to do it :wink:

You can also try to briefly explain what needs to be done, and I'll
have a first attempt at doing it myself...

Thanks,
Moritz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDFdRArIrMbm76jD8RAuYOAJ9IKvwW46e2vp1/n5V3HtzYEHDgTACffIiC
vs9b0/nIEFbcVIgww0I/cBI=
=4doG
-----END PGP SIGNATURE-----

5

I wouldn't call myself "desperate" ;-), but in the effort of
creating a ps.map version of the legend created by d.vect.thematic
it would be necessary for the rectangle object...

Ok, I looked at doing that but specifically didn't add it to the
rectangle instruction when I was working with that instruction some
weeks ago for two reasons:

a) I had been thinking about it as a backdrop to draw things on, not as
a foreground object itself. Basic solid colors are usually what is
wanted in this case. I now see that people might want to use the
rectangle command for foreground objects too, and a background color of
"none" would also be useful.

b) Changing it would mean changing the format of the plotting file
(add_to_plfile()). I didn't know if this was just an internal ps.map
thing or had links to other paint commands and so was a bit loath to
make a change which would break something else.

For what you want to do, I would think it better not to use a filled
'rectangle' but rather use the 'point' command to place an icon of type
basic/box at the x% y%. Looking at the code I see I didn't change this
one either re. RGB due to the same plotfile format change. I am more
motivated to fix this first.

I though there was a message by me in the mailing list archives from
mid-June on this but it eludes my searches.

I also think that ideally ps.map should have a consistent behaviour
across all elements, but that's easy to say while I depend on other
to do it :wink:

A worthy goal, for all of GRASS.

You can also try to briefly explain what needs to be done, and I'll
have a first attempt at doing it myself...

It isn't that hard to do, copying in Radim's vector RGB parsing into
ps/ps.map/r_plt.c from eg r_vlines.c and then the code that reads the
plotfile is all.

The question is if we can change the format of that plot file during
6.1. I don't know the answer to that. If it is ok I am happy to do the
changes as I already know the ps.map code and have been the one doing
the RGB updating in the display modules. Updating the display modules
has often been more of a hack than I'm happy with, but I think I have my
head around how far & where to push that. But RGB support is better
written into the ps.map code vs. the display driver so it isn't really a
problem in this case.

Hamish

6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hamish wrote:

I wouldn't call myself "desperate" ;-), but in the effort of
creating a ps.map version of the legend created by d.vect.thematic
it would be necessary for the rectangle object...

Ok, I looked at doing that but specifically didn't add it to the
rectangle instruction when I was working with that instruction some
weeks ago for two reasons:

a) I had been thinking about it as a backdrop to draw things on, not as
a foreground object itself. Basic solid colors are usually what is
wanted in this case. I now see that people might want to use the
rectangle command for foreground objects too, and a background color of
"none" would also be useful.

b) Changing it would mean changing the format of the plotting file
(add_to_plfile()). I didn't know if this was just an internal ps.map
thing or had links to other paint commands and so was a bit loath to
make a change which would break something else.

For what you want to do, I would think it better not to use a filled
'rectangle' but rather use the 'point' command to place an icon of type
basic/box at the x% y%. Looking at the code I see I didn't change this
one either re. RGB due to the same plotfile format change. I am more
motivated to fix this first.

That sounds perfect to me.

I though there was a message by me in the mailing list archives from
mid-June on this but it eludes my searches.

Actually you filed a bug report:
http://intevation.de/rt/webrt?serial_num=3398&display=History
(mailing list:
http://grass.itc.it/pipermail/grass5/2005-July/018895.html)

You can also try to briefly explain what needs to be done, and I'll
have a first attempt at doing it myself...

It isn't that hard to do, copying in Radim's vector RGB parsing into
ps/ps.map/r_plt.c from eg r_vlines.c and then the code that reads the
plotfile is all.

The question is if we can change the format of that plot file during
6.1. I don't know the answer to that. If it is ok I am happy to do the
changes as I already know the ps.map code and have been the one doing
the RGB updating in the display modules. Updating the display modules
has often been more of a hack than I'm happy with, but I think I have my
head around how far & where to push that. But RGB support is better
written into the ps.map code vs. the display driver so it isn't really a
problem in this case.

If you are willing to implement it for the points element then I
won't touch the code, and I don't think doing so will break anything
(people will be able to continue to use color names, or ?), so it
shouldn't be a problem to do it in 6.1, or ?

Thanks !

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDFsZPrIrMbm76jD8RAkq7AJ9wQInPseVdwIHwA9ESo3ra+BxH+QCeM8Yz
CpZ8NIauUGthfL0KwhSnpW8=
=ehzW
-----END PGP SIGNATURE-----

7

I'm sure that the updates discussed will be very helpful to many.

I'd like to list a request in a little different direction however, that I
think would help even more people.

Is there any way to create a postscript output driver for a monitor window?
Sending a monitor window (at whatever its current resolution is) to a
postscript file, and then to a printer, would be very useful. This could
work like d.png. But even doing it as graphic output (rather than the nicer
ps.map output) would be a big help to many.

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

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Thu, 1 Sep 2005 12:39:29 +1200
To: Moritz Lennert <mlennert@club.worldonline.be>
Cc: <grass5@grass.itc.it>
Subject: Re: [GRASS5] rgb color support in ps.map ?

I wouldn't call myself "desperate" ;-), but in the effort of
creating a ps.map version of the legend created by d.vect.thematic
it would be necessary for the rectangle object...

Ok, I looked at doing that but specifically didn't add it to the
rectangle instruction when I was working with that instruction some
weeks ago for two reasons:

a) I had been thinking about it as a backdrop to draw things on, not as
a foreground object itself. Basic solid colors are usually what is
wanted in this case. I now see that people might want to use the
rectangle command for foreground objects too, and a background color of
"none" would also be useful.

b) Changing it would mean changing the format of the plotting file
(add_to_plfile()). I didn't know if this was just an internal ps.map
thing or had links to other paint commands and so was a bit loath to
make a change which would break something else.

For what you want to do, I would think it better not to use a filled
'rectangle' but rather use the 'point' command to place an icon of type
basic/box at the x% y%. Looking at the code I see I didn't change this
one either re. RGB due to the same plotfile format change. I am more
motivated to fix this first.

I though there was a message by me in the mailing list archives from
mid-June on this but it eludes my searches.

I also think that ideally ps.map should have a consistent behaviour
across all elements, but that's easy to say while I depend on other
to do it :wink:

A worthy goal, for all of GRASS.

You can also try to briefly explain what needs to be done, and I'll
have a first attempt at doing it myself...

It isn't that hard to do, copying in Radim's vector RGB parsing into
ps/ps.map/r_plt.c from eg r_vlines.c and then the code that reads the
plotfile is all.

The question is if we can change the format of that plot file during
6.1. I don't know the answer to that. If it is ok I am happy to do the
changes as I already know the ps.map code and have been the one doing
the RGB updating in the display modules. Updating the display modules
has often been more of a hack than I'm happy with, but I think I have my
head around how far & where to push that. But RGB support is better
written into the ps.map code vs. the display driver so it isn't really a
problem in this case.

Hamish

8

Michael Barton wrote:

I'm sure that the updates discussed will be very helpful to many.

I'd like to list a request in a little different direction however, that I
think would help even more people.

Is there any way to create a postscript output driver for a monitor window?

It wouldn't provide any benefit over using the PNG driver and
converting the result to PostScript. Otherise I would have written it
already.

The problem is that the raster graphics API is too oriented toward
screen display (e.g. operating in integer pixel coordinates, requiring
rasters to be scaled client-side etc).

Also, some clients rely upon low-level details of rendering operations
(e.g. assuming that drawing lines will set certain pixels, e.g. using
G_plot_polygon() with R_line_abs() to fill a polygon by drawing
horizontal lines).

A display architecture which did a half-way decent job of generating
PostScript would need to operate in abstract coordinates, with no
pixel-level guarantees about drawing operations and a scaled raster
primitive.

Sending a monitor window (at whatever its current resolution is) to a
postscript file, and then to a printer, would be very useful. This could
work like d.png. But even doing it as graphic output (rather than the nicer
ps.map output) would be a big help to many.

PNG driver + pnmtops.

You'll get jagged lines, but that's a problem of the display
architecture which can't be fixed in an individual driver.

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

9

PNG driver + pnmtops.

You'll get jagged lines, but that's a problem of the display
architecture which can't be fixed in an individual driver.

Use pnmalias to fix that (sort of).

pngtopnm infile.png | pnmalias | pnmtops > outfile.ps

Hamish

10

Hamish wrote:

> PNG driver + pnmtops.
>
> You'll get jagged lines, but that's a problem of the display
> architecture which can't be fixed in an individual driver.

Use pnmalias to fix that (sort of).

pngtopnm infile.png | pnmalias | pnmtops > outfile.ps

I'm not sure how good an idea that is if you're planning on printing
the file. pnmalias will interpolate the colours; the interpolated
colours will then end up getting dithered for printing.

BTW, the PNG driver can write PPM files directly.

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

11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Barton wrote:

I'm sure that the updates discussed will be very helpful to many.

I'd like to list a request in a little different direction however, that I
think would help even more people.

Is there any way to create a postscript output driver for a monitor window?
Sending a monitor window (at whatever its current resolution is) to a
postscript file, and then to a printer, would be very useful. This could
work like d.png. But even doing it as graphic output (rather than the nicer
ps.map output) would be a big help to many.

In order to get (vector) postscript output, I use d.vect.thematic,
save the results as a group and then use the printing dialog in the
GIS Manager to print it to postscript.

It would also be possible to directly create a ps.map instructions
file from d.vect.thematic, but this seems to be overkill since the
printing dialog exists.

However, some d.vect commands are not implemented in ps.map (e.g.
d.vect.chart), so this solution is obviously limited.

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHBMjrIrMbm76jD8RArT3AJ9rHVmGvfOEn1A4ERwo1VBWuFLdJQCeKcac
MErlO1Hc3wgFlRsKppTPVvo=
=wOrq
-----END PGP SIGNATURE-----