[GRASS-dev] ps.map: raster always under vector map?

[Glynn Clements]

Hamish wrote:

> > it would be better (IMHO) to work on getting better PostScript output
> > from d.* commands.
> 
> I think it would be really nice to have the PS driver better, but we are
> nowhere near (yet) having something that rivals ps.map's output quality.
> (ie I haven't given up on ps.map)
> 
> > FWIW, what are the main advantages of ps.map over using the PS driver
> > and d.* commands?
> 
> I think there are a few, mainly related to ps.map already tuned to the
> problem of hardcopy output. The PS driver would need a hardcopy-wizard
> wrapper GUI, at least to help with the presets.
> 
> But one specific issue when I tried the PS driver with d.vect.chart was
> rendering method of filled areas being drawn as a series of horizontal
> lines instead of a solid area. Filled vector areas were fine.

That's an inevitable problem with using G_plot_polygon(), which does
its own rasterisation. This cannot be made to work with non-raster
drivers such as PS and HTMLMAP.

Nothing should ever use G_plot_polygon() in conjuction with the R_* or
D_* functions; it's only legitimate use is for modules which *need* to
perform their own rasterising, e.g. v.to.rast or r.in.poly.

Of the modules which currently use it:

 display/d.mapgraph/OBJ.i686-pc-linux-gnu/do_graph.o | G_plot_polygon
 display/d.vect/OBJ.i686-pc-linux-gnu/plot1.o        | G_plot_polygon
 display/d.vect.chart/OBJ.i686-pc-linux-gnu/bar.o    | G_plot_polygon
 display/d.vect.chart/OBJ.i686-pc-linux-gnu/pie.o    | G_plot_polygon
 display/d.what.vect/OBJ.i686-pc-linux-gnu/flash.o   | G_plot_polygon
 raster/r.in.poly/OBJ.i686-pc-linux-gnu/poly2rast.o  | G_plot_polygon
 vector/v.to.rast/OBJ.i686-pc-linux-gnu/do_areas.o   | G_plot_polygon

The last two are legitimate, the others aren't (at least d.vect
provides the render= option; unless there are specific objections I
intend to change the default from g to l).

> Another issue I noticed was lack of page margins in the final PS file.

That isn't hard to change; the main issue is deciding how to feed the
various parameters to the driver, preferably without adding a dozen
new environment variables. OTOH, it isn't hard to change externally,
using e.g. psutils.

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