[GRASS-dev] Re: windows binaries

Hamish hamish_nospam at yahoo.com
Tue Nov 14 19:35:44 EST 2006

Glynn Clements wrote:
> > Here's an idea: if direct rendering had an option to initialise the
> > framebuffer from an image file (or PPM/PGM pair), building up an
> > image by having multiple d.* commands render on top of each other
> > would work, in the same way that it does with persistent drivers.
> I've added this feature to libpngdriver (so it affects both the
> standalone PNG driver and direct rendering).
> If you set GRASS_PNG_READ to TRUE, it will read $GRASS_PNGFILE (either
> a PNG file or PPM/PGM pair) into the framebuffer at startup. This
> allows you to build up a rendered image by overlaying multiple d.*
> commands.
> The file(s) must exist, and match the various PNG driver environment
> variables in all respects, otherwise a fatal error occurs. So long as
> the file was generated from a previous invocation with the same
> settings, there shouldn't be any problems.
> Note that GRASS_PNG_READ mustn't be set for the first command, as the
> file(s) won't exist yet.
> This feature is useful primarily for scripts (e.g. d.vect.thematic)
> which run multiple d.* commands to generate a final result. It should
> be simpler than managing and compositing the various layers manually. 
> It also works with PNG files as well as PPM/PGM pairs (we don't have a
> PNG version of g.pnmcomp).

could you add a description of it to lib/init/variables.html ?
 (internal use section)

There are now so many arcane GRASS shell variables controlling different
parts of the system, we should try very hard to keep them all documented.


More information about the grass-dev mailing list