[GRASS-user] Freetype fonts in gis.m

GRASS GRASS user
21

Glynn,

This is the gist of it. See below.
__________________________________________
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: Sun, 11 Jun 2006 07:38:40 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.m

Michael Barton wrote:

2. gis.m provides no guarantees as to the order in which layers are
rendered. If a command changes the font, whether other commands use
the default font or the changed font depends upon the order in which
the commands are executed.

The layers are always rendered and composited in bottom to top order in
gis.m.

Between each layer rendering, it is necessary to run a d.font command or no
text will render. Currently this defaults to d.font romans. It could be set
to a variable which, in turn, could be set by d.font.text or
d.font.freetype.

You're still restarting the driver for every layer?

Whilst inefficient, that does at least simplify the font issue.

For now, it's simpler to keep the font handling entirely within gis.m,
i.e. provide a user option to control the font used at startup
(ideally, also provide an option to use freetype fonts).

We don't restart d.mon gism for each layer, but d.font romans and d.frame -e
is run each time due to driver issues.

I correct myself (had to check into how Cedric had changed it).

D.font romans is run once per rendering session, not once per layer
D.erase -e is run once per layer.

So how much work is done in each session?

If you render multiple layers with a single driver process, and one of
the commands sets the font, that setting will affect subsequent
commands.

If you only render "changed" layers, then commands which draw text
will produce different results depending upon whether a command which
sets the font is run previously in the same session.

E.g. suppose you have two command layers:

1. d.vect ... font=...
2. d.legend ...

If you execute both commands in the above order with the same driver
process, d.legend will use the font set by d.vect.

... Snip...

If you redisplay and nothing has changed, d.vect and d.legend will not run.
The existing PPM images from previous rendering will be used instead. It
doesn't matter that d.font romans runs, because it doesn't affect images
already stored on disk.

If the legend changes and the vector does not, then the d.font romans
command WILL affect the legend.

So the font command ought to go with the d.* command where it is meant to
apply.

Michael

22

Michael Barton wrote:

> If you only render "changed" layers, then commands which draw text
> will produce different results depending upon whether a command which
> sets the font is run previously in the same session.
>
> E.g. suppose you have two command layers:
>
> 1. d.vect ... font=...
> 2. d.legend ...
>
> If you execute both commands in the above order with the same driver
> process, d.legend will use the font set by d.vect.

... Snip...

If you redisplay and nothing has changed, d.vect and d.legend will not run.
The existing PPM images from previous rendering will be used instead. It
doesn't matter that d.font romans runs, because it doesn't affect images
already stored on disk.

If the legend changes and the vector does not, then the d.font romans
command WILL affect the legend.

So the font command ought to go with the d.* command where it is meant to
apply.

Yep; hence my earlier comment:

There should be an option to set the default font. You would need to
reset the font after calling anything which might change it (which
includes all command layers, as there's no reliable way to determine
whether a particular command will change the font).

Rather than resetting the font after commands which might change it,
setting the font before commands which might draw text may be more
appropriate.

Except that driver-less rendering will make this point moot. There,
the issue is being able to set the default font (it's currently
hard-coded to romans).

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

23

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 11 Jun 2006 22:51:14 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.m

Michael Barton wrote:

Rather than resetting the font after commands which might change it,
setting the font before commands which might draw text may be more
appropriate.

Except that driver-less rendering will make this point moot. There,
the issue is being able to set the default font (it's currently
hard-coded to romans).

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

Wouldn't it work to simply run d.font (or d.font.freetype) just before
running a d.command in this situaion too?

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

24

Michael Barton wrote:

> Rather than resetting the font after commands which might change it,
> setting the font before commands which might draw text may be more
> appropriate.
>
> Except that driver-less rendering will make this point moot. There,
> the issue is being able to set the default font (it's currently
> hard-coded to romans).

Wouldn't it work to simply run d.font (or d.font.freetype) just before
running a d.command in this situaion too?

With no driver, there is no persistent state. Each command is
self-contained; any changes which it makes to the state are lost when
the command terminates.

For something like gis.m, this should be an advantage, as you don't
have to worry about "accidental" state changes from previous commands
(i.e. commands changing the font, line width, text rotation etc).

If there are things which really should persist between commands, that
will need to be explicitly added, but then you need to be sure to
explicitly set any state which will affect a command and not assume
that it will be in its default state.

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

25

Michael Barton wrote:
> Currently, the only way to have them produce high-quality output is
> to render them in the GUI (e.g., as TclTk postscript objects). Could
> the relevant d.* commands (e.g., d.legend, d.text, d.label) be
> changed to optionally output postscript some something that would
> scale and display well? Or does this need to be done in the GUI?

I think this is could be interpreted incorrectly - this only pertains to
good looking fonts in the new GUI window.

d.font.freetype + d.legend etc look great on the display monitor -as
rendered-. Grid lines, legends, arrows, barscale decorations all have
the same problem wrt rescaling. Hint: Run a narrow blur filter on the
graphic before resizing and it looks better.

For hardcopy output ps.map fonts look very nice too.

The GUI is very nice, but you do not have to use it to get nice results.

Glynn Clements wrote:

Ideally, we need to:

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

Hamish

26

They DO look MUCH better if you use d.font.freetype. And
v.label/d.paint.labels has become quite sophisticated. However, because they
are rasterized in the display, such text and decorations don't look as good
if you enlarge them. I'm quite happy with it for PowerPoint and
publications.

However, I understood the (original) question to be about how to get high
quality cartographic output. For this, you really need postscript text,
decorations, and vectors--and GRASS doesn't do that yet except ps.map, and
for only labels and text in the gis.m.

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 16:06:44 +1200
To: Glynn Clements <glynn@gclements.plus.com>
Cc: <michael.barton@asu.edu>, <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.m

Michael Barton wrote:

Currently, the only way to have them produce high-quality output is
to render them in the GUI (e.g., as TclTk postscript objects). Could
the relevant d.* commands (e.g., d.legend, d.text, d.label) be
changed to optionally output postscript some something that would
scale and display well? Or does this need to be done in the GUI?

I think this is could be interpreted incorrectly - this only pertains to
good looking fonts in the new GUI window.

d.font.freetype + d.legend etc look great on the display monitor -as
rendered-. Grid lines, legends, arrows, barscale decorations all have
the same problem wrt rescaling. Hint: Run a narrow blur filter on the
graphic before resizing and it looks better.

For hardcopy output ps.map fonts look very nice too.

The GUI is very nice, but you do not have to use it to get nice results.

Glynn Clements wrote:

Ideally, we need to:

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

Hamish