[GRASS-dev] New installation for wxPython GUI

[Glynn Clements]

twiens wrote:

> > ...lots snipped...
> ... more snipped...
> > versions of these too? This is a lot of work. If the CLI
> > could simple recognize existing GRASS commands, it would
> > save a lot of coding.
> > 
> ... more snipped ...
> > It sounds like you are proposing more of a CLI-based
> > cartography module (conceptually along the lines of LaTex
> > perhaps?). If so, why not work with improving the existing
> > CLI cartographic module, ps.map? Make it easier to use so
> > that it can be realistically be controlled interactively
> > from the CLI. Just a thought.
> 
> Good idea, but from my point of view, it is awkward to have
> one environment in which you work with your maps for
> analysis and then have to switch to another environment to
> lay it out for printing. The classic case is ArcView where
> you place you labels in one environment and then have a
> separate layout environment. Invariably the final output
> sucks. and use is awkward. Instead one should be simply
> working with the different layers and when you are ready to
> go to print it, you just do it. This is one of the reasons I
> had asked about using postscript directly because one would
> be continually working with the final output which is the
> ideal from a cartographic point of view. However as Glynn
> pointed out, this would be very slow, and thus not viable.
> I'm not sure of the slowdown is due to postscript generation
> or display.

Display. PostScript's rendering model was designed for quality, not
speed. Also, it was designed for high resolutions; e.g. there are no
short-cuts for single-pixel lines (a single-pixel line would be almost
invisible at 300dpi and completely invisible at 2400dpi).

> At this point, in my conceptualizing about this,
> I would want to abstract the commands sent to ps.map and to
> d.* into a single supper set which would then either
> generate d.* or ps.map commands to give the desired output.
> Thus users would only have to use one set of commands, not
> two and certainly not three. 
> 
> If this concept isn't viable at this time, I'm happy to
> write a simple wrapper for d.* commands as a short term
> solution, but I think this would not represent the kind of
> leap forward in GRASS ease of use and functionality that I
> would like to achieve. It is nice to get critical feedback
> however, because if I'm just creating stack of d.* commands
> then the design would be quite different.

IMHO, the more logical solution is to improve the d.* commands and the
underlying libraries so that having an option to generate PostScript
rather than PNG/PPM images is viable.

For this to work, display modules need operate at a higher level,
rather than treating the raster library as a mechanism to render
things directly. E.g. not using G_plot_area() for filling polygons.

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