[GRASS-dev] discussion: replacing ps.map

Glynn Clements glynn at gclements.plus.com
Fri Apr 6 12:26:37 EDT 2007


S-Bören Gebbert wrote:-A

> thanks a lot for your effort.
> The PS driver is working great for me
> and i have a couple of questions about it:
> 
> 1.) If i use d.erase to erase the monitor, an ERASE statement is added to map.ps.
>      Using the d.erase command after i have added raster or vector maps results in
>      rerendering the "erased" content.
>      Is there a way to reset the map.ps file to avoid rerendering of
>      "old" maps after using d.erase?

Only ...

>      I need to stop the PS driver and restart it again to avoid rerendering.

... like this.

The PS driver simply appends all output to $GRASS_PSFILE.

It could truncate the file (although that will only work for files,
not pipes or e.g. /dev/stdout) upon erase, or it could close and
re-open the file.

It's not entirely clear what the "correct" solution is.

Is there a reason why you might want to send graphics to the driver
when you are subsequently going to erase them?

With the existing behaviour, the ERASE procedure can be redefined in
the prolog ($GISBASE/etc/psdriver.ps) to do something else. E.g. it
could call "showpage", so you could generate a multi-page file, using
ERASE for page breaks.

> 2.) The d.vect module works fine, the lines are really smooth if the line width is set to 1.
>      If i choose a larger line width, polylines are broken into pieces
>      spearfish60 example:
>      d.mon PS
>      d.vect roads color=black width=4
>      d.vect roads color=white width=1
>      gv map.ps
> 
>      Is there a way to avoid this? Well, i guess this is not an easy task.

Modify d.vect to generate polylines (R_polyline_abs()) rather than
individual line segments (R_{move,cont}_abs()). Unlike the PNG driver,
the PS driver implements polylines as a single stroked path. If you
send it a polyline, you'll get joins (rather than caps) between the
segments.

This is a good example of what I mean when I say that the main problem
with implementing a PostScript driver is the way that modules use the
graphics API.

Note that being able to change the line width is a relatively recent
feature (2005/08/09). Back when lines were always single-pixel, there
wasn't any difference between a polyline and lots of individual
segments.

Also note that the PS driver cannot realistically convert move/cont
operations into polylines, as a polyline has to be "stroke"d in a
single operation.

> 3.) I don't know how to tell the PS driver to use real colors, is there documentation available?
>      eg.: g.manual -m psdriver

"real" colours? As opposed to imaginary colours? ;)

If you're getting monochrome output, use:

	export GRASS_TRUECOLOR=TRUE

to get colour PostScript.

I made monochrome the default because that results in the most
portable code (a minimal level 1 PostScript implementation doesn't
support colour).

> 4.) I would love to see a doxygen documentation of the driver library,
>      so i can understand how it works :)

Regarding the graphics subsystem, documentation tends to become
inaccurate faster than it gets written.

> 5.) Is there a way to create eps output? This would be great, especially to use the created maps
>      within other documents. (latex ...)

Try ps2epsi (normally included with Ghostscript).

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




More information about the grass-dev mailing list