[GRASS-dev] discussion: replacing ps.map

[Glynn Clements]

Glynn Clements wrote:

> > > Thierry, I have a very vague memory that you said something about KerGIS 
> > > being able to directly produce vectorized output. Is this true ? How do 
> > > you do this ?
> > 
> > By using the legacy RASTERLIB now called DRAWLIB in KerGIS. The
> > documentation about the library is misleading. It is not raster oriented
> > if you take juste the library that is just an API and a communication
> > facility to monitors. The API is a drawing API: you draw not only raster
> > images, but lines, polylines etc.
> > 
> > In KerGIS, there is only one driver: the X11 one. And it uses the X11
> > vector drawing XLIB functions for lines etc.
> > 
> > In this sense, it is not difficult to implement a psdriver.
> 
> It isn't difficult to implement, but it won't necessarily be of much
> use given the existing API.

FWIW, I've committed a basic PostScript driver to CVS.

It's behaviour is similar to the PNG driver. The output file is
controlled by $GRASS_PSFILE, defaulting to "map.ps". If
$GRASS_TRUECOLOR == "TRUE", it will generate colour output, otherwise
grey-scale.

$GRASS_{WIDTH,HEIGHT} specify the monitor dimensions in points
(1/72"), and all coordinates are interpreted as points. This means
that all drawing primitives are snapped to a 1-point grid, although
rendering will be performed at the actual device resolution.

At present, there are doubtless many things which don't work
correctly, or are sub-optimal (especially polygon filling, which
currently uses the generic software renderer, i.e. lots of horizontal
lines).

Masked images (e.g. "d.rast -o") require level 3 PostScript; colour
images require level 2 or a level 1 implementation which supports the
colorimage operator. Unmasked grey-scale images should work on
anything.

Anything which doesn't explicitly specify a line width (i.e. probably
everything except "d.vect ... width=...") will end up using a line
width of zero, which is probably not much use on a printer.

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