[GRASS-dev] [bug #5489] (grass) d.font error in GRASS6.2/6.3

GRASS GIS GRASS GIS developer
1

this bug's URL: http://intevation.de/rt/webrt?serial_num=5489
-------------------------------------------------------------------------

Subject: d.font error in GRASS6.2/6.3

Platform: GNU/Linux/x86
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 6.2/6.3 cvs snapshot

Aldo Clerici
In GRASS6.2, the GIS Manager GUI 'Config >Text > Select default text' command, gives the following error:
No socket to connect to for monitor <x0>
No graphics device selected
The commands d.font font=romans works well in command line mode (after a minitor is open).

Also in GRASS6.3 the commands doesn't work but a different error message is issued.
In command line mode the error is:
WARNING /usr/local/grass-6.3.cvs/etc/freetypecap: No FreeType definition file.

Greetings

-------------------------------------------- Managed by Request Tracker

2

Question to those who may know...

Is d.font simply unusable without an x11 display monitor? If so, I'll just
take it off the GUI menu. Or is the warning that you need to run d.mon
another example of an old (and a little misleading) message that is now
getting properly parsed and displayed in the output window?

I tried setting some fonts and I couldn't find any text affected. I checked
d.grid, d.histogram, and d.text.

I think I remember that the font setting doesn't persist or something like
that.

Michael

On 2/9/07 2:40 AM, "Request Tracker" <grass-bugs@intevation.de> wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=5489
-------------------------------------------------------------------------

Subject: d.font error in GRASS6.2/6.3

Platform: GNU/Linux/x86
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 6.2/6.3 cvs snapshot

Aldo Clerici
In GRASS6.2, the GIS Manager GUI 'Config >Text > Select default text' command,
gives the following error:
No socket to connect to for monitor <x0>
No graphics device selected
The commands d.font font=romans works well in command line mode (after a
minitor is open).

Also in GRASS6.3 the commands doesn't work but a different error message is
issued.
In command line mode the error is:
WARNING /usr/local/grass-6.3.cvs/etc/freetypecap: No FreeType definition file.

Greetings

-------------------------------------------- Managed by Request Tracker

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

3

Michael Barton wrote:

Question to those who may know...

Is d.font simply unusable without an x11 display monitor?

It's unusable without a *monitor*. It works with any driver (XDRIVER,
PNG driver), but it isn't meaningful when using direct rendering.

If so, I'll just
take it off the GUI menu. Or is the warning that you need to run d.mon
another example of an old (and a little misleading) message that is now
getting properly parsed and displayed in the output window?

I tried setting some fonts and I couldn't find any text affected. I checked
d.grid, d.histogram, and d.text.

I think I remember that the font setting doesn't persist or something like
that.

Yep. When using direct rendering, the driver state is essentially
re-initialised for each command, as if you had run e.g.:

  d.mon start=PNG
  d.foo yadda yadda
  d.mon stop=PNG

Programs whose sole purpose is to modify driver state (e.g. d.font,
d.frame) are meaningless when direct rendering is used. In a technical
sense, they still "work", but they're pointless.

This is why direct rendering has GRASS_FONT, GRASS_FT_FONT and
GRASS_FT_ENCODING; there isn't any other way to set this state.

Ideally, the GUI needs to allow you to set these variables globally,
and to override them for individual "layers".

Even when gis.m used a standalone PNGdriver monitor, setting the font
was problematic, as individual commands can change the font for their
own purposes, and any changes would then persist for subsequent
commands. Consequently, the font that was used for a particular layer
could change depending upon the order in which layers were rendered.

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

4

OK. It is coming back to me, but this is a very nice summary.

So I should simply drop d.font and d.font.freetype from the GUI menu. They
are meaningless in that context.

We could replace them with a script that sets GRASS_FONT and GRASS_FT_FONT.
I think the layers that use text and can set text (e.g., the text layers)
are coded to check the current status of the global variables and set them
back when done.

Michael

On 2/9/07 10:55 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

This is why direct rendering has GRASS_FONT, GRASS_FT_FONT and
GRASS_FT_ENCODING; there isn't any other way to set this state.

Ideally, the GUI needs to allow you to set these variables globally,
and to override them for individual "layers".

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

5

Michael Barton wrote:

So I should simply drop d.font and d.font.freetype from the GUI menu. They
are meaningless in that context.

Yes.

We could replace them with a script that sets GRASS_FONT and GRASS_FT_FONT.

If by "script", you mean "Tcl code", then yes. An external script (run
with exec) won't work.

I think the layers that use text and can set text (e.g., the text layers)
are coded to check the current status of the global variables and set them
back when done.

With direct rendering, there's no need. Any state changes which a d.*
command makes will only last for the duration of that command.

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

6

Glynn Clements wrote:

This is why direct rendering has GRASS_FONT, GRASS_FT_FONT and
GRASS_FT_ENCODING; there isn't any other way to set this state.

Could you document these 3 in lib/init/variables.html ?

thanks,
Hamish

7

Hamish wrote:

> This is why direct rendering has GRASS_FONT, GRASS_FT_FONT and
> GRASS_FT_ENCODING; there isn't any other way to set this state.

Could you document these 3 in lib/init/variables.html ?

OK; I've added the following:

<h3>List of selected GRASS environment variables for direct rendering</h3>
<blockquote>
[ In addition to those which are understood by the
<a href="pngdriver.html">PNG Driver</a>, the following variables
affect direct rendering. ]
</blockquote>
<P></P>

<p>GRASS_FONT
<br>&nbsp; specifies the font as either the name of a stroke font in
$GISBASE/etc/fonts, the full path to a stroke font (which must begin
with $GISBASE/etc/fonts/), the name of a FreeType font from
$GISBASE/etc/freetypecap, or the full path to a FreeType font file.

<p>GRASS_FT_FONT
<br>&nbsp; specifies a FreeType font as a full path to the font file.
If both GRASS_FONT and GRASS_FT_FONT are specified, GRASS_FT_FONT
takes precedence.

<p>GRASS_FT_ENCODING
<br>&nbsp; the encoding to be assumed for text which is drawn using a
freetype font; may be any encoding know to "iconv".

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