[GRASS-dev] using system fonts?

[Glynn Clements]

Michael Barton wrote:

> If there is a way to get the path from the multitude of font information I
> CAN get, I can't find it. Everything but.
> 
> What I'd like to get away from is for everyone to have to search for their
> fonts to use in GRASS. On the Mac, most are in /Library/fonts. However, some
> are also in the X11RC directory. On different Linux systems they are in
> other places, and for Windows I have no idea where they live.
> 
> This means that there is no way to design a generic font picker for GRASS
> that will simply list available fonts. I CAN get a generic font picker from
> a GUI package, but at least with wxPython and TclTk, it provides lots of
> information about font DESCRIPTION, but nothing (that I can find) about font
> LOCATION and file name.
> 
> Maybe it's just not possible to specify font description for GRASS display
> (or more trouble than it's worth for one reason or another). But it would be
> nice.

At a minimum, it requires that the renderer knows where the fonts are,
and can get at them.

> The other thing that makes this more complicated is that, if I understand it
> correctly, font settings do not persist past a single display event. This
> provides greater flexibility in creating displays with different fonts, but
> it makes it harder to set a default font for all GRASS unless you want to
> change it.

For direct rendering, the font is set from environment variables. That
means that they can only be changed by an ancestor of any d.* commands
(e.g. the shell, gis.m, gism.py etc), and not by a sibling (the way
that d.font works).

The font could easily be set from a GRASS variable, but that's
basically a bad idea. It doesn't make it any easier for a GUI (setting
an environment variable is no harder than running d.font), and causes
problems due to statefulness, i.e. the order in which you execute the
display commands matters, you can't run multiple display commands
concurrently, etc.

In general, global state is bad. Its use in GRASS is due to its CLI
origins, where having to specify the database, location, mapset,
region, monitor, font, etc as explicit parameters for each command
would be a nuisance. Mostly, you want those parameters to be the same
for successive commands until you say otherwise, so you use global
state to eliminate the need to keep typing them.

For a GUI, this isn't an issue; the GUI can keep track of the state. 
Moreover, if you want to change a parameter for an individual command,
you don't have to modify global state, run the command, change the
state back, and hope that the modification didn't interfere with
anything else which was running concurrently.

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