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

[Moritz Lennert]

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.

> 
> 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 ?

Moritz