[GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text

[Glynn Clements]

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.

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.

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