Is this fixed now? Freetype text doesn't work on a Mac so I can't tell.
No, neither the gis.m part, nor the d.text.freetype part (for which I will post a separate bug report to make it more visible).
As Glynn wrote, the gis.m error can be "solved" by typing
d.text.freetype -n -b {text=Population totale}
instead of
d.text.freetype -n -b text="Population totale"
But I don't find this solution very intuitive, especially as on the command line the second works.
So maybe there should be some treatment in gis.m which translates the second version into something usable. Or at least the documentation has to be updated, but I would only consider this as a temporary solution.
Just for memory, the d.text.freetype part of the bug is that even when a space is accepted, it is not printed on the screen, making the above into:
On Aug 29, 2006, at 8:17 AM, Moritz Lennert wrote:
Michael Barton via RT wrote:
Is this fixed now? Freetype text doesn't work on a Mac so I can't tell.
Michael, just noticed this comment - how is FreeType text broken (besides the spaces problem)? I've been having problems with getting freetype to read dfonts and suitcase'd TT fonts in OS X (but unix-style .ttf fonts work). I found a fix that is in the freetype CVS waiting for the next version, but it's supposed to be an OSX Intel-only problem.
"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."
"Don't you even hate 'em?"
"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."
<Ha, ha> "And it might give 'em all stomach ulcers."
> Is this fixed now? Freetype text doesn't work on a Mac so I can't tell.
No, neither the gis.m part, nor the d.text.freetype part (for which I
will post a separate bug report to make it more visible).
As Glynn wrote, the gis.m error can be "solved" by typing
d.text.freetype -n -b {text=Population totale}
instead of
d.text.freetype -n -b text="Population totale"
But I don't find this solution very intuitive, especially as on the
command line the second works.
So maybe there should be some treatment in gis.m which translates the
second version into something usable. Or at least the documentation has
to be updated, but I would only consider this as a temporary solution.
Just for memory, the d.text.freetype part of the bug is that even when a
space is accepted, it is not printed on the screen, making the above into:
Populationtotale
There are two separate issues. gis.m has previously had problems with
arguments containing spaces, but there have been some fixes in that
area. If you come across this problem in the current CVS version, file
a bug report.
The problem with spaces disappearing is that FT_Render_Glyph() returns
an error for the space glyph, causing the code to ignore that glyph
(and, significantly, not advance the rendering position).
The code should probably still advance the rendering position in the
event that FT_Render_Glyph() fails.
D.text.freetype would not display any text the Mac, either using x11 tcltk
or aqua tcltk. That and other problems people were having is why I took it
off the GIS layer toolbar. You can still set default screen fonts using
freetype text. I think this does work OK.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
From: William Kyngesburye <woklist@kyngchaos.com>
Reply-To: William Kyngesburye <kyngchaos@kyngchaos.com>
Date: Tue, 29 Aug 2006 08:51:01 -0500
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does
not allow spaces in text
On Aug 29, 2006, at 8:17 AM, Moritz Lennert wrote:
Michael Barton via RT wrote:
Is this fixed now? Freetype text doesn't work on a Mac so I can't
tell.
Michael, just noticed this comment - how is FreeType text broken
(besides the spaces problem)? I've been having problems with getting
freetype to read dfonts and suitcase'd TT fonts in OS X (but unix-
style .ttf fonts work). I found a fix that is in the freetype CVS
waiting for the next version, but it's supposed to be an OSX Intel-
only problem.
"We are at war with them. Neither in hatred nor revenge and with no
particular pleasure I shall kill every ___ I can until the war is
over. That is my duty."
"Don't you even hate 'em?"
"What good would it do if I did? If all the many millions of people
of the allied nations devoted an entire year exclusively to hating
the ____ it wouldn't kill one ___ nor shorten the war one day."
<Ha, ha> "And it might give 'em all stomach ulcers."
Do you know what fonts you were trying to use that didn't work? Most of the common fonts that come with OSX are dfonts (Apple's fonts) and suitcase TT fonts (the M$ fonts). There are a few unix-style .ttf fonts in the system (but those tend to be other language script fonts), and some OTF Japanese fonts.
X11 vs Aqua shouldn't affect freetype itself. Though if you use Apple's X11-bundled freetype, I found that suitcase font support is disabled there, and only dfonts and unix-style fonts work.
On Aug 29, 2006, at 1:17 PM, Michael Barton wrote:
D.text.freetype would not display any text the Mac, either using x11 tcltk
or aqua tcltk. That and other problems people were having is why I took it
off the GIS layer toolbar. You can still set default screen fonts using
freetype text. I think this does work OK.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
From: William Kyngesburye <woklist@kyngchaos.com>
Reply-To: William Kyngesburye <kyngchaos@kyngchaos.com>
Date: Tue, 29 Aug 2006 08:51:01 -0500
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does
not allow spaces in text
On Aug 29, 2006, at 8:17 AM, Moritz Lennert wrote:
Michael Barton via RT wrote:
Is this fixed now? Freetype text doesn't work on a Mac so I can't
tell.
Michael, just noticed this comment - how is FreeType text broken
(besides the spaces problem)? I've been having problems with getting
freetype to read dfonts and suitcase'd TT fonts in OS X (but unix-
style .ttf fonts work). I found a fix that is in the freetype CVS
waiting for the next version, but it's supposed to be an OSX Intel-
only problem.
Do you know what fonts you were trying to use that didn't work? Most
of the common fonts that come with OSX are dfonts (Apple's fonts) and
suitcase TT fonts (the M$ fonts). There are a few unix-style .ttf
fonts in the system (but those tend to be other language script
fonts), and some OTF Japanese fonts.
X11 vs Aqua shouldn't affect freetype itself. Though if you use
Apple's X11-bundled freetype, I found that suitcase font support is
disabled there, and only dfonts and unix-style fonts work.
Hi,
just testing d.text.freetype on GRASS 6.3 (including just-now fix from
Glynn for main.c) I'm still getting a crash (SIGFPE) if the text=""
contains a space. The debugger traces it to this call in main.c (line
1040).
i.e. it breaks within FT_Render_Glyph() if ch=32; it doesn't make it as
far as Glynn's new code (the next line).
in the terminal:
Floating point exception
Monitor <x0>: Premature EOF
Similar problems with GRASS 6.0.2 and 6.1.0 (!). I'm a little surprised
to find this in 6.0.2 as I've been using the same Debian/stable setup
for a while so nothing has changed much. I guess I've been using
d.font.freetype + d.text mostly, but I'm surprised none the less. In
6.0.2 it gives a segmentation fault, not a FPE.
As I understand it, d.font.freetype + d.text works; d.text.freetype does
not.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
From: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 30 Aug 2006 15:16:04 +1200
To: <glynn@gclements.plus.com>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does
not allow spaces in text
for a while so nothing has changed much. I guess I've been using
d.font.freetype + d.text mostly, but I'm surprised none the less. In
Is this fixed now? Freetype text doesn't work on a Mac so I can't tell.
No, neither the gis.m part, nor the d.text.freetype part (for which I will post a separate bug report to make it more visible).
As Glynn wrote, the gis.m error can be "solved" by typing
d.text.freetype -n -b {text=Population totale}
instead of
d.text.freetype -n -b text="Population totale"
But I don't find this solution very intuitive, especially as on the command line the second works.
So maybe there should be some treatment in gis.m which translates the second version into something usable. Or at least the documentation has to be updated, but I would only consider this as a temporary solution.
Just for memory, the d.text.freetype part of the bug is that even when a space is accepted, it is not printed on the screen, making the above into:
Populationtotale
There are two separate issues. gis.m has previously had problems with
arguments containing spaces, but there have been some fixes in that
area. If you come across this problem in the current CVS version, file
a bug report.
That is what this bug report is actually about (what I call the "gis.m part of the bug") and it is still open as of CVS-head from yesterday.
The problem with spaces disappearing is that FT_Render_Glyph() returns
an error for the space glyph, causing the code to ignore that glyph
(and, significantly, not advance the rendering position).
But this only seems to be a problem with the current stable version of freetype, i.e. 2.2.1. Using latest CVS code of freetype, the problem is solved.
The code should probably still advance the rendering position in the
event that FT_Render_Glyph() fails.
Do you know what fonts you were trying to use that didn't work? Most of the common fonts that come with OSX are dfonts (Apple's fonts) and
suitcase TT fonts (the M$ fonts). There are a few unix-style .ttf fonts in the system (but those tend to be other language script fonts), and some OTF Japanese fonts.
X11 vs Aqua shouldn't affect freetype itself. Though if you use Apple's X11-bundled freetype, I found that suitcase font support is disabled there, and only dfonts and unix-style fonts work.
Hi,
just testing d.text.freetype on GRASS 6.3 (including just-now fix from
Glynn for main.c) I'm still getting a crash (SIGFPE) if the text=""
contains a space. The debugger traces it to this call in main.c (line
1040).
As I understand it, d.font.freetype + d.text works; d.text.freetype does
not.
The former uses ft_render_mode_normal, the latter ft_render_mode_mono.
Is there anything (useful) which the latter does but the former
doesn't? Or can we kill d.text.freetype?
Hmm. Immediate rendering doesn't work with FreeType fonts at present.
You can't use d.font/d.font.freetype as each d.* command is self
contained. The default font for immediate rendering is set with
GRASS_FONT, but that currently only supports the stroke fonts. I'll
fix this today.
Using the driver's built-in FreeType handling has the advantage that
we can implement anti-aliased text when using the PNG driver
(including immediate rendering) in true-colour mode.
The FreeType text rendering uses the driver's draw_bitmap operation,
which isn't directly exposed (i.e. there is no R_draw_bitmap() or
similar). d.text.freetype uses R_raster_char().
The draw_bitmap operation could easily be extended to support
anti-aliasing. Currently, the bitmap is one byte per pixel, with zero
indicating transparent and non-zero indicating opaque. Changing it to
an alpha channel would involve removing the "... > 128 ? 1:0" from
lib/driver/text3.c:272 and having the driver's draw_bitmap operation
either perform the check itself (for XDRIVER or for the PNG driver
using indexed colour) or using anti-aliasing (for the PNG driver using
true colour).
Actually, we could just make the draw_bitmap operation available
through an R_draw_bitmap() function for d.text.freetype to use.
Finally, there should probably be an option to select the rendering
mode (ft_render_mode_{normal,mono}); if you aren't using
anti-aliasing, ft_render_mode_mono will typically produce better
results (assuming that ft_render_mode_mono actually works).
> There are two separate issues. gis.m has previously had problems with
> arguments containing spaces, but there have been some fixes in that
> area. If you come across this problem in the current CVS version, file
> a bug report.
That is what this bug report is actually about (what I call the "gis.m
part of the bug") and it is still open as of CVS-head from yesterday.
So the gis.m bug is still present? I.e. you can't include spaces in
the text?
> The code should probably still advance the rendering position in the
> event that FT_Render_Glyph() fails.
Is this a problem with anything else then space ?
Probably not (well, it probably applies to all "blank" characters,
e.g. double-width space as well as the normall ASCII space character).
There are two separate issues. gis.m has previously had problems with
arguments containing spaces, but there have been some fixes in that
area. If you come across this problem in the current CVS version, file
a bug report.
That is what this bug report is actually about (what I call the "gis.m part of the bug") and it is still open as of CVS-head from yesterday.
So the gis.m bug is still present? I.e. you can't include spaces in
the text?
Yes, unless I use the curly braces solution you suggested, i.e.:
d.text.freetype -n {text=Population totale} ...
Just to make sure we understand each other: this is when adding the d.text.freetype command as a command layer to gis.m (I don't know of another way...).
>>> There are two separate issues. gis.m has previously had problems with
>>> arguments containing spaces, but there have been some fixes in that
>>> area. If you come across this problem in the current CVS version, file
>>> a bug report.
>> That is what this bug report is actually about (what I call the "gis.m
>> part of the bug") and it is still open as of CVS-head from yesterday.
>
> So the gis.m bug is still present? I.e. you can't include spaces in
> the text?
Yes, unless I use the curly braces solution you suggested, i.e.:
d.text.freetype -n {text=Population totale} ...
Just to make sure we understand each other: this is when adding the
d.text.freetype command as a command layer to gis.m (I don't know of
another way...).
Right. If you are using a command layer, then you need to use braces
for any arguments which contain spaces. More precisely, the string for
a command layer needs to be a well-formed Tcl list, where each item in
the list constitutes a single argument. Using a backslash should also
work, i.e.:
d.text.freetype -n text=Population\ totale ...
That isn't a bug; if you want to represent a list of strings (e.g. a
command) as a single string (i.e. the contents of a text field), and
you want list items to be able to contain the item separator, you
inevitably need some syntax to distinguish between use of the
separator as a separator and its use as a literal character.
With the Bourne shell, you need to use quotes; with Tcl, it's braces.
BTW, if an argument contains an unmatched brace, you have to use
backslashes, e.g.:
On Wed, Aug 30, 2006 at 11:49:23AM +0200, Moritz Lennert wrote:
Glynn Clements wrote:
>Moritz Lennert wrote:
>>>Is this fixed now? Freetype text doesn't work on a Mac so I can't tell.
>>No, neither the gis.m part, nor the d.text.freetype part (for which I will
>>post a separate bug report to make it more visible).
>>As Glynn wrote, the gis.m error can be "solved" by typing
>>d.text.freetype -n -b {text=Population totale}
>>instead of
>>d.text.freetype -n -b text="Population totale"
>>But I don't find this solution very intuitive, especially as on the command
>>line the second works.
>>So maybe there should be some treatment in gis.m which translates the second
>>version into something usable. Or at least the documentation has to be
>>updated, but I would only consider this as a temporary solution.
>>Just for memory, the d.text.freetype part of the bug is that even when a
>>space is accepted, it is not printed on the screen, making the above into:
>>Populationtotale
>There are two separate issues. gis.m has previously had problems with
>arguments containing spaces, but there have been some fixes in that
>area. If you come across this problem in the current CVS version, file
>a bug report.
That is what this bug report is actually about (what I call the "gis.m part of
the bug") and it is still open as of CVS-head from yesterday.
>The problem with spaces disappearing is that FT_Render_Glyph() returns
>an error for the space glyph, causing the code to ignore that glyph
>(and, significantly, not advance the rendering position).
But this only seems to be a problem with the current stable version of
freetype, i.e. 2.2.1. Using latest CVS code of freetype, the problem is solved.
On Wed, Aug 30, 2006 at 03:16:04PM +1200, Hamish wrote:
William Kyngesburye wrote:
> Do you know what fonts you were trying to use that didn't work? Most
> of the common fonts that come with OSX are dfonts (Apple's fonts) and
>
> suitcase TT fonts (the M$ fonts). There are a few unix-style .ttf
> fonts in the system (but those tend to be other language script
> fonts), and some OTF Japanese fonts.
>
> X11 vs Aqua shouldn't affect freetype itself. Though if you use
> Apple's X11-bundled freetype, I found that suitcase font support is
> disabled there, and only dfonts and unix-style fonts work.
Hi,
just testing d.text.freetype on GRASS 6.3 (including just-now fix from
Glynn for main.c) I'm still getting a crash (SIGFPE) if the text=""
contains a space. The debugger traces it to this call in main.c (line
1040).
i.e. it breaks within FT_Render_Glyph() if ch=32; it doesn't make it as
far as Glynn's new code (the next line).
in the terminal:
Floating point exception
Monitor <x0>: Premature EOF
Similar problems with GRASS 6.0.2 and 6.1.0 (!). I'm a little surprised
to find this in 6.0.2 as I've been using the same Debian/stable setup
for a while so nothing has changed much. I guess I've been using
d.font.freetype + d.text mostly, but I'm surprised none the less. In
6.0.2 it gives a segmentation fault, not a FPE.
Hamish,
I've changed FT_LOAD_DEFAULT to FT_LOAD_NO_BITMAP not to try to load
embedded bitmaps. Could you please test this code?
On Wed, Aug 30, 2006 at 02:28:53PM +0100, Glynn Clements wrote:
Michael Barton wrote:
> As I understand it, d.font.freetype + d.text works; d.text.freetype does
> not.
The former uses ft_render_mode_normal, the latter ft_render_mode_mono.
Is there anything (useful) which the latter does but the former
doesn't? Or can we kill d.text.freetype?
Unlike d.text, d.text.freetype is able to locate text more precisely on
the screen (mouse, relative position, geographic coordinates, alignment)
and supports line spacing and different colors in the same line (no
linefeed).
Huidae Cho
Hmm. Immediate rendering doesn't work with FreeType fonts at present.
You can't use d.font/d.font.freetype as each d.* command is self
contained. The default font for immediate rendering is set with
GRASS_FONT, but that currently only supports the stroke fonts. I'll
fix this today.
Using the driver's built-in FreeType handling has the advantage that
we can implement anti-aliased text when using the PNG driver
(including immediate rendering) in true-colour mode.
The FreeType text rendering uses the driver's draw_bitmap operation,
which isn't directly exposed (i.e. there is no R_draw_bitmap() or
similar). d.text.freetype uses R_raster_char().
The draw_bitmap operation could easily be extended to support
anti-aliasing. Currently, the bitmap is one byte per pixel, with zero
indicating transparent and non-zero indicating opaque. Changing it to
an alpha channel would involve removing the "... > 128 ? 1:0" from
lib/driver/text3.c:272 and having the driver's draw_bitmap operation
either perform the check itself (for XDRIVER or for the PNG driver
using indexed colour) or using anti-aliasing (for the PNG driver using
true colour).
Actually, we could just make the draw_bitmap operation available
through an R_draw_bitmap() function for d.text.freetype to use.
Finally, there should probably be an option to select the rendering
mode (ft_render_mode_{normal,mono}); if you aren't using
anti-aliasing, ft_render_mode_mono will typically produce better
results (assuming that ft_render_mode_mono actually works).
> > As I understand it, d.font.freetype + d.text works; d.text.freetype does
> > not.
>
> The former uses ft_render_mode_normal, the latter ft_render_mode_mono.
>
> Is there anything (useful) which the latter does but the former
> doesn't? Or can we kill d.text.freetype?
Unlike d.text, d.text.freetype is able to locate text more precisely on
the screen (mouse, relative position, geographic coordinates, alignment)
and supports line spacing and different colors in the same line (no
linefeed).
Is there any reason why those features can't be added to d.text?
On Wed, Aug 30, 2006 at 06:55:05PM +0100, Glynn Clements wrote:
Huidae Cho wrote:
> > > As I understand it, d.font.freetype + d.text works; d.text.freetype does
> > > not.
> >
> > The former uses ft_render_mode_normal, the latter ft_render_mode_mono.
> >
> > Is there anything (useful) which the latter does but the former
> > doesn't? Or can we kill d.text.freetype?
>
> Unlike d.text, d.text.freetype is able to locate text more precisely on
> the screen (mouse, relative position, geographic coordinates, alignment)
> and supports line spacing and different colors in the same line (no
> linefeed).
Is there any reason why those features can't be added to d.text?
No, it's simply because nobody did it. Hopefully, I'll sometime.
> > Is there anything (useful) which the latter does but the former
> > doesn't? Or can we kill d.text.freetype?
>
> Unlike d.text, d.text.freetype is able to locate text more precisely
> on the screen (mouse, relative position, geographic coordinates,
> alignment) and supports line spacing and different colors in the
> same line (no linefeed).
Is there any reason why those features can't be added to d.text?
while we are on the topic, and assuming we want to continue to use
interactive d.mom X-monitors for a while, it is a long standing wish of
mine that d.barscale's mouse placement routine be used for d.text.freetype.
> > > Is there anything (useful) which the latter does but the former
> > > doesn't? Or can we kill d.text.freetype?
> >
> > Unlike d.text, d.text.freetype is able to locate text more precisely
> > on the screen (mouse, relative position, geographic coordinates,
> > alignment) and supports line spacing and different colors in the
> > same line (no linefeed).
>
> Is there any reason why those features can't be added to d.text?
while we are on the topic, and assuming we want to continue to use
interactive d.mom X-monitors for a while, it is a long standing wish of
mine that d.barscale's mouse placement routine be used for d.text.freetype.
In particular, note that d.barscale adds the non-interactive
equivalent to the command list (D_add_to_list()), so that redraw
works.