[GRASS-dev] WxPython front-end to ps.map

[Glynn Clements]

Dylan Beaudette wrote:

> > > > As soon as new map display class will be defined in wxPython, I would
> > > > like to build georectifing, ps.map and digitizing tool on top of it.
> > >
> > > Is there any possibility of changing the display system so that vector
> > > data is displayed as such in the display or at least the content of the
> > > display could be directly exported to ps or pdf as vector ?
> >
> > No. At least, not in the short/medium term.
> >
> > You're talking about a completely new display architecture. The
> > current architecture is entirely unsuitable for writing a
> > PostScript/PDF/SVG/etc "driver".
> >
> > Note that any display architecture which *was* suitable for generating
> > PostScript/etc output would be rule out the use of G_plot_polygon()
> > etc for rendering, so d.vect would need to be fixed.
> 
> Having specialized output drivers seems like it might help retain CLI 
> functionality _and_ potential to create high quality output. Using R as an 
> example:
> 
> # plot something to the screen, low res but functional
> x11()
> plot(x, y, ...)
> 
> # plot something to a PDF file: nice crisp lines, etc.
> pdf(file='new.pdf', width=6, height=10)
> plot(x, y, ...
> # close the file
> dev.off()
> 
> This approach allows the same commands to draw on the screen or out to any 
> number of files:
> png() , postscript(), pdf(), fig(), ... you get the idea
> 
> Generalizing the d.* commands sufficiently would be the challenge... it would 
> be a great improvement to just output an Xmon to PDF - with real vector 
> representation of lines, etc.

My original preference for a new graphics API was to have d.* commands
simply generate PostScript conforming to certain conventions. The
resulting PostScript could then be drawn on screen (x11 driver),
rendered to an image (PNG/PPM/BMP/etc drivers) or sent to a printer
(either a native PostScript printer or via the ljet/PCL/etc drivers).

Unfortunately, rendering vector maps using PostScript is between 1 and
2 orders of magnitude slower than using XDrawLine(), which is bad for
interactive use. So we still need some kind of intermediate layer
which provides a speed-before-quality option for drawing lines.

[PostScript draws lines by filling closed paths; there isn't much
point in allowing for single-pixel lines when you're primarily
targeting devices with resolutions of 300 DPI and upwards.]

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