[GRASS-dev] discussion: replacing ps.map

[tlaronde at polynum.com]

Hello,

On Fri, Mar 30, 2007 at 06:38:37AM -0600, Roger Miller wrote:
> 
> How do you see this contributing to a solution to the complaints that
> have been posted?  Is there a plan?
> 
> 
> On Fri, 2007-03-30 at 06:17 +0100, Glynn Clements wrote:
> 
> > FWIW, I've committed a basic PostScript driver to CVS.
> > 

Obviously, I do not answer for Glynn Clements. I will simply write down
some alternatives that I have in mind, related to the problems you
reported, and to the possible solutions, being granted that the final
format of the solution is the format of the hardcopy, that is
PostScript.

PostScript is a "simple" interpretive programming language for document
description. As such, it is a text, even an ASCII description, that is
it can be humanly written or at least edited once you have a template.

Strictly speaking, because at least ps.map(1) produces a template, at
the moment with GRASS/KerGIS you can produce absolutely what you want.
The problem is that this requires some knowledge, and that, at least,
this means trial and errors to write the file, then to interpret
(render/display) to see the result, correct the file etc.

My remark about the fact that the DRAWLIB (mistakenly called RASTERLIB)
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.

Now for interactive use, one can imagine, whether a psdriver that writes
directly a PS file---but in this sense, there is not an interactive
gain---or a psdriver that writes a ps.map(1) script from a d.* history
file for example, or a psdriver simply called from v.digit(1) to
"publish"---keep in a script---via DRAWLIB commands to the psdriver 
a placement you are happy with in an GUI.

In fact, the legacy paint and RASTERLIB were overlaying, and the paint,
now---because PostScript is a standard and there are tools to translate
it to printers' proprietary formats---is of no more use.

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.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C