[GRASS-dev] discussion: replacing ps.map
dylan.beaudette at gmail.com
Fri Apr 6 12:54:33 EDT 2007
On Friday 06 April 2007 08:06, Glynn Clements wrote:
> 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...
I still like this approach, however a more seamless method like that used in R
would be ideal: output is created based on the driver function which is
called png(), x11(), pdf(), etc. Note that I am not in a position to
implement this... :(
> It would certainly be *easier* to change ps.map, as ps.map generates
> PostScript directly.
Would we then be limited to the functionality of ps.map?
> 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).
I think that striving for quality would be a good thing. I usually compose
maps at 2x the resolution and then downscale with the current PNG driver.
> 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.
If this were the only driver this might solve a couple of issues in a single
step: high quality on screen output, AND high quality print output. The
slowness of the PS driver might make working with data more cumbersome,
however the current monitors are a bit slow anyways...
> More significantly, additional cases wouldn't need necessarily need
> new R_* functions; the module could just generate PostScript code
This would be nice if we knew how long it would take to compose the image.
Here are some more time comparisons for composition of separate RGB channels
I also noticed that the PS driver only supports grayscale, perhaps this was
Overall great work Gylnn - this thread has spawned some very interesting
conversation and development!
Soils and Biogeochemistry Graduate Group
University of California at Davis
More information about the grass-dev