[GRASS-dev] numeric-numpy-scipy for graphs?

[Glynn Clements]

Hamish wrote:

> > The one complication is changing window size. The GRASS command would
> > need to be rerun and the graphic rendered. With the new PS driver, we
> > might not be stuck with a rasterized version.
> 
> just to throw something else out there: What if we had a SVG driver?
>   http://en.wikipedia.org/wiki/Svg

SVG is a viable alternative to PostScript.

As it's orientated towards video graphics rather than hardcopy, it
provides some features which PostScript doesn't. OTOH, some of those
features (e.g. translucency) can't be realised in hardcopy (other than
by rasterising everything and printing the resulting image, which
effectively means lower resolution).

My main concern with SVG is whether it is sufficiently mature.

The "mismatch" with hardcopy output isn't critical; a lot of systems
offer a single interface for both video and hardcopy graphics, with
certain operations being documented as not working for hardcopy.

OTOH, even if it isn't critical, it may still be an issue. The main
risk is that some people may simply forget about hardcopy and end up
introducing gratuitous "video-only" restrictions.

> very rough idea:
> If window bounds are the same, maybe it is easier to render raster maps
> in the PNG driver and vector maps & decorations in the SVG driver before
> combining with g.pnmcomp?

I was thinking that might be worthwhile allowing display modules to
choose between two API "levels". The basic level would allow the use
of the current set of operations using the existing PNG driver code.
The advanced level would allow more operations, including the ability
to output arbitrary PostScript (or SVG if that was chosen).

Modules which use the advanced level would always generate
PostScript/SVG; if image output was selected, the graphics library
would automatically invoke the renderer to generate the image.

Modules which use the basic level would still generate PostScript/SVG
if that output format was selected, or if "quality" (rather than
"draft") output was selected, but would use the existing renderer for
"draft" image output.

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