Further testing and looks like d.text DOES respect GRASS_FONT settings
This leaves only d.label
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
Michael Barton wrote:
Further testing and looks like d.text DOES respect GRASS_FONT settings
This leaves only d.label
d.labels is only a conduit. It works using the font given in labels file
and is not subject to local override. Choose the font you want at the
v.label step.
I guess we could change it to look the other way on that if the labels
file is using the default, "font: standard".
currently do_labels.c has:
#define STANDARD_FONT "romans"
...
if (sscanf (text, "%*s %s", font) != 1
|| !strcmp (font, "standard"))
strcpy (font, STANDARD_FONT);
we could change that hardcoded "romans", but it needs to be done
explicitly as other previous labels may have changed the font to
something specific already. (different labels in the same file can
use different fonts) How to do *string = {G|R}_get_current_font();
rather than just trusting the current state?
FWIW, ps.map defaults to Helvetica for the standard font.
Hamish
How does this work with d.barscale or d.text.
If a font isn't specified and GRASS_FONT is NOT set, it defaults to Romans.
If a font isn't specified and GRASS_FONT IS set, it defaults to GRASS_FONT.
If a font IS set, this overrides the other two.
Also, I forgot to reiterate that d.rast.nums only does Romans and does not
respond to GRASS_FONT.
Finally, helvetica is a very nice font for this stuff. How can ps.map
default to helvetica, however? Is it likely to be present on all systems?
What happens if it's missing?
Michael
On 4/29/07 7:41 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
Further testing and looks like d.text DOES respect GRASS_FONT settings
This leaves only d.label
d.labels is only a conduit. It works using the font given in labels file
and is not subject to local override. Choose the font you want at the
v.label step.I guess we could change it to look the other way on that if the labels
file is using the default, "font: standard".currently do_labels.c has:
#define STANDARD_FONT "romans"
...
if (sscanf (text, "%*s %s", font) != 1
|| !strcmp (font, "standard"))
strcpy (font, STANDARD_FONT);we could change that hardcoded "romans", but it needs to be done
explicitly as other previous labels may have changed the font to
something specific already. (different labels in the same file can
use different fonts) How to do *string = {G|R}_get_current_font();
rather than just trusting the current state?FWIW, ps.map defaults to Helvetica for the standard font.
Hamish
__________________________________________
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
Michael Barton wrote:
Finally, helvetica is a very nice font for this stuff.
I notice that I have some grass6/lib/db/latex/Helvetica.ttf files.
I assume this is copied there by "make pdfdocs" at some point. Which
means that apparently the LaTeX tools have a trick to find the raw TTF
font files....
Hamish
Hamish wrote:
> Further testing and looks like d.text DOES respect GRASS_FONT settings
>
> This leaves only d.labeld.labels is only a conduit. It works using the font given in labels file
and is not subject to local override. Choose the font you want at the
v.label step.I guess we could change it to look the other way on that if the labels
file is using the default, "font: standard".currently do_labels.c has:
#define STANDARD_FONT "romans"
...
if (sscanf (text, "%*s %s", font) != 1
|| !strcmp (font, "standard"))
strcpy (font, STANDARD_FONT);we could change that hardcoded "romans", but it needs to be done
explicitly as other previous labels may have changed the font to
something specific already. (different labels in the same file can
use different fonts) How to do *string = {G|R}_get_current_font();
rather than just trusting the current state?
There is no R_get_current_font(). Nor for any of the other persistent
state (line width, text size, text rotation, current point, current
colour, maybe others).
But that's not what d.labels does at present; "standard" selects
"romans" rather than the current font at module startup (i.e. that
selected by d.font). In that regard, the corresponding fix would be
e.g.:
const char *std_font;
std_font = getenv("GRASS_FT_FONT");
if (!std_font)
std_font = getenv("GRASS_FONT");
if (!std_font)
std_font = "romans";
We should probably kill one of GRASS_FONT/GRASS_FT_FONT now that there
are no longer separate stroke/freetype fonts.
--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
Finally, helvetica is a very nice font for this stuff. How can ps.map
default to helvetica, however? Is it likely to be present on all systems?
What happens if it's missing?
The following fonts are likely to be present in nearly all PostScript
implementations:
Times-Roman
Times-Italic
Times-Bold
Times-BoldItalic
Helvetica
Helvetica-Oblique
Helvetica-Bold
Helvetica-BoldOblique
Courier
Courier-Oblique
Courier-Bold
Courier-BoldOblique
Symbol
PostScript files generated for distribution typically limit themselves
to these fonts to avoid having to embed fonts.
--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
Also, I forgot to reiterate that d.rast.nums only does Romans and does
not respond to GRASS_FONT.
$ grep R_font display/d.rast.num/*
display/d.rast.num/number.c: R_font("romans");
remove that line, then it will.
(but then will it still be guaranteed to fit within a cell?)
Hamish
Michael:
> > Further testing and looks like d.text DOES respect GRASS_FONT
> > settings
> >
> > This leaves only d.label
Hamish:
> currently do_labels.c has:
>
> #define STANDARD_FONT "romans"
> ...
> if (sscanf (text, "%*s %s", font) != 1
> || !strcmp (font, "standard"))
> strcpy (font, STANDARD_FONT);
>
> we could change that
Glynn:
"standard" selects "romans" rather than the current font at module
startup (i.e. that selected by d.font). In that regard, the
corresponding fix would be e.g.:const char *std_font;
std_font = getenv("GRASS_FT_FONT");
if (!std_font)
std_font = getenv("GRASS_FONT");
if (!std_font)
std_font = "romans";
done in cvs. (for GRASS_FONT only)
d.labels still won't respect d.font, but if the font changes there is no
way to know what it started as for the next font-less label, so I'm not
sure it would be a good idea to try / have it change the default font
part-way through.
We should probably kill one of GRASS_FONT/GRASS_FT_FONT now that there
are no longer separate stroke/freetype fonts.
GRASS_FT_FONT seems like the obvious choice for removal as it is now a
subset of GRASS_FONT, but not the other way around.
Hamish
Hamish wrote:
> We should probably kill one of GRASS_FONT/GRASS_FT_FONT now that there
> are no longer separate stroke/freetype fonts.GRASS_FT_FONT seems like the obvious choice for removal as it is now a
subset of GRASS_FONT, but not the other way around.
In terms of implementation, they both do exactly the same thing:
lib/raster/loc_io.c:
const char *ftfont = getenv("GRASS_FT_FONT");
...
const char *font = getenv("GRASS_FONT");
...
if (ftfont)
R_font(ftfont);
else if (font)
R_font(font);
else
R_font("romans");
display/d.mon/pgms/select.c:
const char *ftfont = getenv("GRASS_FT_FONT");
...
const char *font = getenv("GRASS_FONT");
...
R_font((ftfont ? ftfont : (font ? font : "romans")));
R_font() gets passed the value of whichever variable is defined; using
GRASS_FT_FONT=romans would work. OTOH, the _FT_ is misleading, so that
one should probably go.
--
Glynn Clements <glynn@gclements.plus.com>