Ignoring the aim of Pete's graphical outputs, perhaps my advice will be trivial, but quite often people want to keep vectorial formats very "far" in the output process eventhough they don't have special post-editing needs. I was of those till I understood raster formats advantages for pre-press, among which: * kind of stability between platforms/softwares (no surprise when interpreting the format, as it often happens e.g. with poor quality postscript interpreters); * very acceptable accuracy (beyond 300 dpi for a color output is useless regarding common printers technology); * lightness (if you ever tried to generate a complex A3 pdf doc with multiple translucent layers above a raster background, you might know what I mean...)
It is quite easy with Grass to write a script that: * outputs a ps file for each layer you need to overlay (may they be numerous, you have control on image size and map extent), * then performs the composition with a command line image editor (image magick can interprete postscript if you have ghostscript installed on your system) that does deal with blending options. I can provide examples for those interested... Vincent Le jeudi 25 mars 2010 à 15:12 +0000, Glynn Clements a écrit : > pete davidson wrote: > > > And then we discover that the 'svg' produced by cairo using the above script > > is actually just a png in an svg wrapper.. At least for my particular > > install of Grass. That's frustrating. Ahh well, back to the drawing board. > > Cairo falls back to rasterisation as soon as it encounters anything > which it might not be able to implement using vector operations. > > For me, a simple "d.vect fields" produces "real" (vector) SVG output. > You might want to experiment with the command options (and the > environment variables used by the cairo driver) to see if a specific > feature is triggering rasterisation. > _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user