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

[Glynn Clements]

Hamish wrote:

> > 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.
> 
> What about adding a [E]PostScript display driver? Akin to the PNG
> driver, vs. the x11 driver. It would primarily be intended for hardcopy
> output, but could potentially be used for (slow) GUI protoypes.

The raster graphics API is entirely unsuitable for a PostScript
driver. The main problem is that everything operates using "pixel"
coordinates, but PostScript's graphics model is based upon infinite
resolution (the actual device resolution is an implementation detail).

Certainly, something could be written which exposed a fake resolution
to the application, however:

1. All coordinates would end up being snapped to the fake resolution
grid.

2. Any raster data would be re-scaled client side, the rescaled data
sent to the driver, then rescaled again by the PostScript
implementation to the actual device resolution.

3. d.area renders filled areas itself (using G_plot_polygon) by
sending a series of horizontal lines to the driver.

The above points would all have an impact upon the choice of the fake
resolution. A higher resolution would result in better output, but
would result in #2 and #3 generating significantly more data; this
will harm performance and generate huge PostScript files (if you're
storing them, or sending them to a physical printer). A lower
resolution would result in low quality output, which would be very
noticable on >300dpi hardcopy.

In practice, a PostScript driver based upon the current API wouldn't
produce significantly better results than just using the PNG driver
and embedding the image in a PostScript file.

In short, we need a new graphics API; if it was only a matter of
implementing a driver, I would have done it years ago.

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