[GRASS-dev] discussion: replacing ps.map

[Glynn Clements]

Jachym Cepicky wrote:

> btw: what do you think about replacement of ps.map with new PS driver
> && d.* commands?
> 
> would it be easier to add line styles and area fillings to ps.map
> (where it partely is, at least the areas) or to d.rast/d.vect ? I
> think, it would be great to have only one set of tools for both - data
> displaying and hard copy maps preparation...

It would certainly be *easier* to change ps.map, as ps.map generates
PostScript directly.

d.* commands are limited to whatever the raster library provides. If
you want to add an additional operation to the graphics API, you
currently have to:

 1. Add a R_* function to lib/raster/com_proto.c
 2. Add its prototype to include/raster.h
 3. Add a field to "struct transport" in lib/raster/transport.h
 4. Add an intitialiser for the field to "loc_trans" in lib/raster/com_io.c
 5. Add an intitialiser for the field to "rem_trans" in lib/raster/com_io.c
 6. Add a LOC_* version to lib/raster/loc_proto.c
 7. Add a REM_* version to lib/raster/rem_proto.c
 8. Add an opcode to include/graphics.h
 9. Add a "case" to lib/driver/command.c
10. Add a COM_* version to lib/driver/<whatever>.c
11. Add its prototype to lib/driver/driver.h
12. Add a field to "struct driver" in lib/driver/driver.h
13. Add a PNG_* version to lib/pngdriver/<whatever>.c
14. Add the prototype to lib/pngdriver/pngdriver.h
15. Add an intitialiser for the field in lib/pngdriver/Driver.c
16. Add a PS_* version to lib/psdriver/<whatever>.c
17. Add the prototype to lib/psdriver/psdriver.h
18. Add an intitialiser for the field in lib/psdriver/Driver.c
19. Add a XD_* version to display/drivers/XDRIVER/<whatever>.c
20. Add the prototype to display/drivers/XDRIVER/XDRIVER.h
21. Add an intitialiser for the field in display/drivers/XDRIVER/main.c
22. Add a NULL intitialiser for the field in display/drivers/HTMLMAP/main.c

If we can eliminate monitors in favour of direct rendering, we can
eliminate steps 3 through 12. The R_* function would become the COM_*
function, with no need to dispatch based upon local/remote transport.

If we can eliminate XDRIVER in favour of a GUI which uses PPM/PNG
images, that loses 3 steps. If we can eliminate the PNG driver in
favour of "gs -sDEVICE=ppmraw", that loses another 3 (as well as
giving better quality).

Ultimately, if the PS driver was the only driver, we'd be down to just
steps 1 and 2. The R_* function would become the PS_* function; there
would be no need to dispatch based upon the current driver.

More significantly, additional cases wouldn't need necessarily need
new R_* functions; the module could just generate PostScript code
directly.

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