[GRASS-dev] Re: [GRASS-user] Freetype fonts in gis.m

GRASS GIS GRASS GIS developer
1

Hamish wrote:

> a) make a distinction between setting the font in a persistent manner
> (for d.font[.freetype]) and setting the font internally for a single
> client (e.g. "d.vect ... font=...", or the .F operator in d.text).
>
> b) modify modules which use R_text() to accept font= and charset=
> options to eliminate the need for d.font[.freetype] (which doesn't
> work well with command layers).

Adding FONT or FTFONT to GISRC and having d.font[.freetype] modify that
via g.gisenv or equiv. is a good idea. Hacking in font= etc into
G_parser()* is a huge pain when you have multiple commands that draw
text and/or use d.redraw. I don't want to have to retype that for every
command, and I do want a consistent font between different decorations.
Just adding font= for the first d.* command is non-intuitive.

* adding font= to every module that uses R_text() is just too ugly

Regardless of having a configurable global font, any command which
draws text should allow the user to specify a particular font for that
command. Trying to use d.font[.freetype] with command layers in gis.m
isn't practical.

In any case, point a) has to be dealt with. The situation where a
module setting a font for its own text changes the font used by
subsequent modules isn't acceptable.

However, one problem with the $GISRC approach is that the setting
would be shared by all monitors, whereas currently each monitor can
have a separate font. I'm not sure whether that behaviour needs to be
preserved.

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

2

Maybe this is what you're all getting at, but it seems most logical to have
a 'default' font that could be set by d.font* (putting it into GISRC seems
logical too). And also having each d.* command that uses text have the
ability to optionally set a font for that command. If the font is not set,
it uses the default; if the font is set for a command, it overrides the
default.

There should be no need to rerun d.font* for each command.

Michael
__________________________________________
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

From: Glynn Clements <glynn@gclements.plus.com>
Date: Mon, 12 Jun 2006 06:17:20 +0100
To: Hamish <hamish_nospam@yahoo.com>
Cc: <grassuser@grass.itc.it>, <michael.barton@asu.edu>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.m

Hamish wrote:

a) make a distinction between setting the font in a persistent manner
(for d.font[.freetype]) and setting the font internally for a single
client (e.g. "d.vect ... font=...", or the .F operator in d.text).

b) modify modules which use R_text() to accept font= and charset=
options to eliminate the need for d.font[.freetype] (which doesn't
work well with command layers).

Adding FONT or FTFONT to GISRC and having d.font[.freetype] modify that
via g.gisenv or equiv. is a good idea. Hacking in font= etc into
G_parser()* is a huge pain when you have multiple commands that draw
text and/or use d.redraw. I don't want to have to retype that for every
command, and I do want a consistent font between different decorations.
Just adding font= for the first d.* command is non-intuitive.

* adding font= to every module that uses R_text() is just too ugly

Regardless of having a configurable global font, any command which
draws text should allow the user to specify a particular font for that
command. Trying to use d.font[.freetype] with command layers in gis.m
isn't practical.

In any case, point a) has to be dealt with. The situation where a
module setting a font for its own text changes the font used by
subsequent modules isn't acceptable.

However, one problem with the $GISRC approach is that the setting
would be shared by all monitors, whereas currently each monitor can
have a separate font. I'm not sure whether that behaviour needs to be
preserved.

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

3

More generally, to make the d.* commands most efficiently useable from the
command line and for scripting, it makes sense to add a font= option to all
that need it. That is, d.legend by itself should be able to set which font
it uses. It can already set everything else except the font.

Michael
__________________________________________
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

From: Glynn Clements <glynn@gclements.plus.com>
Date: Mon, 12 Jun 2006 06:17:20 +0100
To: Hamish <hamish_nospam@yahoo.com>
Cc: <grassuser@grass.itc.it>, <michael.barton@asu.edu>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.m

Regardless of having a configurable global font, any command which
draws text should allow the user to specify a particular font for that
command. Trying to use d.font[.freetype] with command layers in gis.m
isn't practical.

4

[might as well move this off the -user list]

Michael Barton wrote:

More generally, to make the d.* commands most efficiently useable from
the command line and for scripting, it makes sense to add a font=
option to all that need it. That is, d.legend by itself should be able
to set which font it uses. It can already set everything else except
the font.

The question remains how to easily retain a font setting if the display
monitors will be stateless. From the command line having to retype it
for every module is highly annoying. Right now I just need to set my TTF
font once per session.

* I want to be able to set a default font. (optionally TTF)
* I want to keep the modules as simple as possible. (e.g. d.vect+new user)

fyi, Matlab's way: [each is a child of the one above]

"root" has certain settings (CLI and system wide settings)
  (More = off, ScreenDepth = [24], Children =, etc)

then
"figure" windows have their settings
  (DoubleBuffer = on, PaperType = a4, MenuBar =, Position =, Children =, ...)

then
"axes" have their settings
  (GridLineStyle =, Title =, XTickLabel =, Projection = orthographic, Children =, ...)

then
"lines" [etc] have their settings
  (Color =, LineStyle =, LineWidth =, Data = [X Y], ...)

each level has a pointer you can get() or set() features with. e.g. root
is 0, figure1 is 1, figure2 is 2, etc.

maybe a useful paradigm to consider, as the two programs are
structurally very similar creatures.

Hamish

5

You should also be able to set a 'default' font. The font= argument should
be optional. If left out of the command, it defaults to the default font.
The default font could be set (as now) with d.font*

Michael
__________________________________________
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

From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 12 Jun 2006 20:06:09 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <glynn@gclements.plus.com>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.m

[might as well move this off the -user list]

Michael Barton wrote:

More generally, to make the d.* commands most efficiently useable from
the command line and for scripting, it makes sense to add a font=
option to all that need it. That is, d.legend by itself should be able
to set which font it uses. It can already set everything else except
the font.

The question remains how to easily retain a font setting if the display
monitors will be stateless. From the command line having to retype it
for every module is highly annoying. Right now I just need to set my TTF
font once per session.

* I want to be able to set a default font. (optionally TTF)
* I want to keep the modules as simple as possible. (e.g. d.vect+new user)

fyi, Matlab's way: [each is a child of the one above]

"root" has certain settings (CLI and system wide settings)
  (More = off, ScreenDepth = [24], Children =, etc)

then
"figure" windows have their settings
  (DoubleBuffer = on, PaperType = a4, MenuBar =, Position =, Children =, ...)

then
"axes" have their settings
  (GridLineStyle =, Title =, XTickLabel =, Projection = orthographic, Children
=, ...)

then
"lines" [etc] have their settings
  (Color =, LineStyle =, LineWidth =, Data = [X Y], ...)

each level has a pointer you can get() or set() features with. e.g. root
is 0, figure1 is 1, figure2 is 2, etc.

maybe a useful paradigm to consider, as the two programs are
structurally very similar creatures.

Hamish

6

Michael Barton wrote:

>> More generally, to make the d.* commands most efficiently useable from
>> the command line and for scripting, it makes sense to add a font=
>> option to all that need it. That is, d.legend by itself should be able
>> to set which font it uses. It can already set everything else except
>> the font.
>
> The question remains how to easily retain a font setting if the display
> monitors will be stateless. From the command line having to retype it
> for every module is highly annoying. Right now I just need to set my TTF
> font once per session.
>
> * I want to be able to set a default font. (optionally TTF)
> * I want to keep the modules as simple as possible. (e.g. d.vect+new user)

You should also be able to set a 'default' font. The font= argument should
be optional. If left out of the command, it defaults to the default font.
The default font could be set (as now) with d.font*

The main problem is that, currently, there is exactly one way to set
the font: R_font().

[Or R_font_freetype(), which behaves similarly, but selects a FreeType
font. There is only one current font, which can be either vector or
FreeType.]

The same calls are used both by d.font[.freetype] and by any program
which sets the font for its own text rendering (e.g. d.text, d.vect).
d.font relies upon the fact that the setting persists, while other
programs don't care about the fact that the setting persists.

Changing d.font[.freetype] to use a different mechanism (e.g. $GISRC)
will break the existing behaviour, whereby you can set a different
font on each monitor. I don't know how important it is to retain this.

If we are willing to discard that, what needs to be done is to:

1. Make the driver reset the current font based upon $GISRC at each
client connection.

2. Change d.font[.freetype] to modify $GISRC rather than using
R_font().

If we need to preserve the behaviour of each driver having its own
current font, then what needs to be done is to:

1. Extend the library, protocol and drivers to provide separate
functions for setting the current and default fonts. [The $GISRC
approach will suffice for the driver-less rendering case.]

2. Change the drivers to reset the current font to the default font at
each client connection.

3. Change d.font[.freetype] to use the new functions for setting the
default font.

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