[GRASS-dev] discussion: replacing ps.map

[tlaronde at polynum.com]

On Sat, Mar 31, 2007 at 12:05:42AM +0100, Glynn Clements wrote:
> 
> 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.

Yes and no. PostScript is a vector language, as is METAFONT and so on.
The fact that, generally, the final step is to convert these vectorial
descriptions in raster is an implementation detail.

The man pages for the DRAWLIB (RASTERLIB) mentions:

A!ll graphics standards in industry are aimed  at CAD-CAM vector
applications.  GRASS, being raster based in its primary data
format, requires the ability to work  directly  with a  device's
pixles.  This library provides that capability while interfacing
itself to commercially available vector graphics.


So the "raster" was more taken from the source (the original GRASS,
before the development of the vector) than for the target.

>>> In theory, PostScript could be use as the DRAWLIB language. But I don't
> 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.

Well, I think I do not quite agree about the way the implementation 
has to be made.

AFAIK, rendering (displaying) in GRASS GPL is made by displaying a
previously composed PNG image (Am I right?).

In KerGIS, for displaying, I do not have the intention to pass by an
intermediate step: the xdriver is a direct implementation of the DRAWLIB
opcode. There can be a psdriver, that is a PostScript implementation of
the DRAWLIB opcode.

But, since for hardcopy and the mixing of arbitrary text (with all the
kerning, and even, why not? mathematical text and so on), for this
particular task, dedicated programs will be used to render chunks (label
blocks, images of text) to allow the full power of say a TeX like
formatting system, but for display, whether, in fast mode, only the
outline of the images (bounding box) will be used, or the precomputed
images (chunks) will be displayed with the normal display functions (not
everything will be precomputed by passing by PostScript).

ISTR that, three years ago, when I rewrote the xdriver for KerGIS and
was first able to use v.digit(1) in KerGIS (coming from GRASS GPL 5.0),
I was surprised to see that the display was fast (without having made
any optimization). If you do first render via PNG, that is if there is
indeed an intermediate step in GRASS GPL, this is not a surprise.

Interactivity must be very responsive.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C