[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