I'm a bit behind on gism developments recently...can anyone tell me if
d.font.freetype is supported in gis.m? I tried using it to label some vector
points with today's cvs version, and it's still complaining about no monitor
being open. Is there a workaround instead?
~ Eric.
I got it to work last week, but only if I printed a 1-word text. If I
wanted to print text with spaces in it, I needed to use quotes around
the sentence and this caused problems with the GUI.
In the end, I wound up using d.text from a cmd tool.
David
On 6/7/06, Patton, Eric <epatton@nrcan.gc.ca> wrote:
I'm a bit behind on gism developments recently...can anyone tell me if
d.font.freetype is supported in gis.m? I tried using it to label some vector
points with today's cvs version, and it's still complaining about no monitor
being open. Is there a workaround instead?~ Eric.
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
--
David Finlayson
David Finlayson wrote:
> I'm a bit behind on gism developments recently...can anyone tell me if
> d.font.freetype is supported in gis.m? I tried using it to label some vector
> points with today's cvs version, and it's still complaining about no monitor
> being open. Is there a workaround instead?I got it to work last week, but only if I printed a 1-word text. If I
wanted to print text with spaces in it, I needed to use quotes around
the sentence and this caused problems with the GUI.
Neither quotes nor braces work, althoug a backslash does, e.g.:
d.text.freetype ... text=hello\ world
This should be reported as a bug with command layers.
--
Glynn Clements <glynn@gclements.plus.com>
D.font.freetype is not supported in gis.m. It became increasingly
problematic on Mac (and Windows?) platforms.
Gis.m replaces this with postscript text for vector labels and for manually
positioned text. This only is saved to graphic output if you save as eps
(i.e., not jpeg or tiff). But the eps image has nicer looking text than
d.font.freetext.
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: "Patton, Eric" <epatton@nrcan.gc.ca>
Date: Wed, 7 Jun 2006 11:10:48 -0300
To: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
Subject: [GRASS-user] Freetype fonts in gis.mI'm a bit behind on gism developments recently...can anyone tell me if
d.font.freetype is supported in gis.m? I tried using it to label some vector
points with today's cvs version, and it's still complaining about no monitor
being open. Is there a workaround instead?~ Eric.
Michael Barton wrote:
D.font.freetype is not supported in gis.m. It became increasingly
problematic on Mac (and Windows?) platforms.
It should still be possible to use it in a command layer.
The real issue is that the way that the command string is being
handled causes problems for arguments which contain spaces. I haven't
looked into why this is the case; with the "obvious" implementation,
it should be possible to use braces to prevent an argument being
split.
--
Glynn Clements <glynn@gclements.plus.com>
Actually, on the Mac, it didn't work at all--even for one word text. Also,
you can use it on a command line, but getting it to display in a TclTk
canvas is another matter.
Michael
__________________________________________
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
From: Glynn Clements <glynn@gclements.plus.com>
Date: Thu, 8 Jun 2006 20:56:42 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: "Patton, Eric" <epatton@nrcan.gc.ca>, "'grassuser@grass.itc.it'"
<grassuser@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.mMichael Barton wrote:
D.font.freetype is not supported in gis.m. It became increasingly
problematic on Mac (and Windows?) platforms.It should still be possible to use it in a command layer.
The real issue is that the way that the command string is being
handled causes problems for arguments which contain spaces. I haven't
looked into why this is the case; with the "obvious" implementation,
it should be possible to use braces to prevent an argument being
split.--
Glynn Clements <glynn@gclements.plus.com>
> D.font.freetype is not supported in gis.m. It became increasingly
> problematic on Mac (and Windows?) platforms.It should still be possible to use it in a command layer.
The real issue is that the way that the command string is being
handled causes problems for arguments which contain spaces. I haven't
looked into why this is the case; with the "obvious" implementation,
it should be possible to use braces to prevent an argument being
split.
are d.font.freetype and d.text.freetype getting confused here?
d.font.freetype usually won't have spaces unless the TTF directory has
spaces in it.
Do all the modules that can take SQL queries (with spaces) fail?
Hamish
Michael Barton wrote:
>> D.font.freetype is not supported in gis.m. It became increasingly
>> problematic on Mac (and Windows?) platforms.
>
> It should still be possible to use it in a command layer.
>
> The real issue is that the way that the command string is being
> handled causes problems for arguments which contain spaces. I haven't
> looked into why this is the case; with the "obvious" implementation,
> it should be possible to use braces to prevent an argument being
> split.Actually, on the Mac, it didn't work at all--even for one word text. Also,
you can use it on a command line, but getting it to display in a TclTk
canvas is another matter.
Sorry; I got confused. I was talking about d.text.freetype.
Commands which merely change the driver's state but which don't render
anything don't make sense in gis.m. This includes both d.font and
d.font.freetype.
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).
--
Glynn Clements <glynn@gclements.plus.com>
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).
I'd only put it at the startup/d.erase stage. If the user wants to call
something that changes the font, then let them have that control.
Hamish
That can be done now--albeit manually--by changing the listing in
options.tcl. It is a relatively straightforward project to create an
interactive window that would let users change some of the settings in
options.tcl.
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: Fri, 9 Jun 2006 21:27:03 +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.mThere 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).I'd only put it at the startup/d.erase stage. If the user wants to call
something that changes the font, then let them have that control.Hamish
Hamish wrote:
> 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).I'd only put it at the startup/d.erase stage. If the user wants to call
something that changes the font, then let them have that control.
Two problems:
1. All font changes are persistent, so if one of the layers runs
d.text on a file which changes the font with .F, any subsequent
commands will use the last selected font.
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 whole notion of a "current" font is problematic for a GUI.
Realistically, any command which draws text should have an explicit
font= option. Ditto for the encoding.
--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
>> 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).
>
> I'd only put it at the startup/d.erase stage. If the user wants to call
> something that changes the font, then let them have that control.That can be done now--albeit manually--by changing the listing in
options.tcl. It is a relatively straightforward project to create an
interactive window that would let users change some of the settings in
options.tcl.
I'm referring to the font used for text in modules such as d.text,
d.legend etc.
--
Glynn Clements <glynn@gclements.plus.com>
Hamish wrote:
> > D.font.freetype is not supported in gis.m. It became increasingly
> > problematic on Mac (and Windows?) platforms.
>
> It should still be possible to use it in a command layer.
>
> The real issue is that the way that the command string is being
> handled causes problems for arguments which contain spaces. I haven't
> looked into why this is the case; with the "obvious" implementation,
> it should be possible to use braces to prevent an argument being
> split.are d.font.freetype and d.text.freetype getting confused here?
Yes. However, the problem with d.text.freetype is real.
d.font.freetype usually won't have spaces unless the TTF directory has
spaces in it.Do all the modules that can take SQL queries (with spaces) fail?
The issue is with the way that the command string is handled for
command layers.
--
Glynn Clements <glynn@gclements.plus.com>
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.
Michael
__________________________________________
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
From: Glynn Clements <glynn@gclements.plus.com>
Date: Fri, 9 Jun 2006 21:06:18 +0100
To: Hamish <hamish_nospam@yahoo.com>
Cc: <grassuser@grass.itc.it>, <michael.barton@asu.edu>
Subject: Re: [GRASS-user] Freetype fonts in gis.m2. 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.
I also was confusing d.text.freetype with d.font.freetype.
AFAIC, all such text should be rendered separately from the geospatial data
itself. That is, fonts and decorations should be rendered as a separate
layers (as they do now). 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?
Michael
__________________________________________
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
From: Glynn Clements <glynn@gclements.plus.com>
Date: Fri, 9 Jun 2006 21:07:20 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.mMichael Barton wrote:
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).I'd only put it at the startup/d.erase stage. If the user wants to call
something that changes the font, then let them have that control.That can be done now--albeit manually--by changing the listing in
options.tcl. It is a relatively straightforward project to create an
interactive window that would let users change some of the settings in
options.tcl.I'm referring to the font used for text in modules such as d.text,
d.legend etc.--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
I also was confusing d.text.freetype with d.font.freetype.
AFAIC, all such text should be rendered separately from the geospatial data
itself. That is, fonts and decorations should be rendered as a separate
layers (as they do now). 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?
Regardless of any future changes to the display architecture, the
existing d.* modules need to work as well as possible with gis.m.
1. It should be possible to set the font used by d.legend etc. In
practice, this means running d.font[.freetype] before any command
which /might/ use R_text(). That means all command layers, plus any
other layers which run commands which are known to use R_text().
[For efficiency, it may be necessary to modify the driver library so
that the font is loaded the first time it is actually used, rather
than when it is selected. Freetype fonts are already handled this way;
I can make the changes for vector fonts if it is necessary.]
2. d.text[.freetype] should be usable in a command layer, which means
that it should be possible to pass arguments containing spaces. IOW,
the string obtained from the entry widget needs to be treated as a Tcl
list rather than a string.
Note that d.font[.freetype] currently won't work with driver-less
rendering, as no state is retained between d.* commands. The current
font probably needs to be stored in $GISRC for this case.
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).
--
Glynn Clements <glynn@gclements.plus.com>
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).
--
Glynn Clements <glynn@gclements.plus.com>
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.
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: Sat, 10 Jun 2006 02:22:16 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.mMichael 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).--
Glynn Clements <glynn@gclements.plus.com>
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.
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: Sat, 10 Jun 2006 02:22:16 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] Freetype fonts in gis.mMichael 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).--
Glynn Clements <glynn@gclements.plus.com>
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. If you only execute
the second command, it will use the default font (romans).
--
Glynn Clements <glynn@gclements.plus.com>