[GRASS-dev] discussion: replacing ps.map

[Glynn Clements]

tlaronde at polynum.com wrote:

> My remark about the fact that the DRAWLIB (mistakenly called RASTERLIB)

Not really. It was designed for raster graphics devices, and in many
regards is only suitable for them.

The name reflects the fact that it targets raster devices, not that it
draws raster images.

In that sense, PostScript is also a raster graphics system; you can't
fully implement it on e.g. a plotter.

> is NOT raster oriented, but can happily draw vector geometries and that,
> in this sense, a psdriver is not difficult to implement (restricted to
> the DRAWLIB commands) was made to emphasize that there is already enough
> framework to improve things in GRASS/KerGIS.

It isn't difficult to implement, but implementation is usually the
easy part. It's the design which takes the effort, and GRASS' existing
graphics API was designed for raster devices.

As a consequence, there will be many "rough edges" when using the PS
driver. E.g. code which tries to perform its own rasterisation using
G_plot_polygon(). Another example is code which tries to draw a border
around a rectangular region; the lines will be off by half a unit.

> In theory, PostScript could be use as the DRAWLIB language. But I don't
> think it would gain much:
> 
> 	a) because even if in PostScript reference, the language is called
> 	"simple", rendering of all the PostScript possibilities is
> 	definitively not a trivial task---and if one takes into account
> 	efficiency and time, even more so. So there would be only a very
> 	limited subset of PS commands implemented, gaining nothing except
> 	users starting to wonder why "this part can not be added";
> 
> 	b) the DRAWLIB is an abstraction interface, that does not need to be
> 	very sophisticated for the GIS needs; it can, afterwards, even be
> 	optimized by directly implementing the DRAWLIB functions in whatever
> 	toolkit one likes. The DRAWLIB can be extended to be an abstraction
> 	to even widget toolkits.

There are two issues here: whether the graphics API supports
PostScript output, and whether it supports anything else.

Supporting PostScript output is definitely worthwhile, IMHO. Any d.*
module should be able to generate PostScript with better quality than
by rendering to an image then converting the image to PostScript.

OTOH, if we were to make PostScript *the* graphics API, d.* modules
would have far more flexibility in their output than with anything
else that we are likely to be able to come up with. The existing API
would just be a compatibility library for existing code.

The main feature that people might want which can't be provided using
PostScript is translucency. The only way that can be implemented is by
rendering layers to separate images then blending the images, as gis.m
does using g.pnmcomp.

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