[GRASS-dev] Re: not quite there on fonts

Paul Kelly paul-grass at stjohnspoint.co.uk
Fri May 11 15:18:13 EDT 2007


On Fri, 11 May 2007, Michael Barton wrote:

> On 5/11/07 11:41 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:
>
>> On Fri, 11 May 2007, Michael Barton wrote:
>>
>>> GRASS_RENDER_IMMEDIATE is set prior to rendering and unset immediately
>>> after. The reason is that it doesn't affect any command-line use of GRASS.
>>
>> So you're saying if you start a Tcl application (e.g. gis.m) from a Unix
>> shell, and then set an environment variable within the Tcl application,
>> that the shell kind of inherits it backwards and commands run from there
>> will be affected by the changed environment? I didn't think of that - I
>> suppose it would be better if Tcl allowed you to specify environment
>> variables that applied only to it and commands spawned from it.
>>
>> But I suppose anyway you can work around it in this case by setting
>> GRASS_RENDER_IMMEDIATE before running d.font -l and unsetting it
>> afterwards.
>
> Just tried this and it doesn't work. When I set GRASS_RENDER_IMMEDIATE and
> run d.font -l, it tries to generate a PNG file from the font list. This
> generates an error of course.

Did you update gis.m from CVS first? d.font -l needs to have its stderr 
redirected (as should probably most commands run in the background like 
this - thinking of all the problems with g.region calls). I updated it in
CVS to do this today - seem my earlier e-mail to Glynn explaining why.

Basically the list of fonts is dependent on the driver being used. So 
d.font needs to open the driver first before listing the fonts. In the 
case of direct rendering and the PNG driver, as Glynn said that results in 
some messages being printed to stderr. It doesn't mean d.font is trying to 
create an image though - just the process it has to go through before it 
can list the fonts.

Hope that is a clearer explanation.

Paul




More information about the grass-dev mailing list