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

[Hamish]

Hamish wrote:
> > 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).
> > 
> >         if(FT_Render_Glyph(face->glyph, ft_render_mode_mono))
> > 	{
> > 
> > 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.

Huidae Cho wrote:
> I've changed FT_LOAD_DEFAULT to FT_LOAD_NO_BITMAP not to try to load
> embedded bitmaps.  Could you please test this code?

Hi, I've just updated to the latest HEAD code...

I still get the same result if text="" has a space in it.
  (my usual test is text="`g.version`")

Monitor <x0>: Premature EOF
Floating point exception

Without a space it works fine.

I expect I am seeing the 2.2.1 ft_render_mode_mono bugfix backported to
Debian/stable's libfreetype 2.1.7 (with the latest Debian secuirty fix),
and this is actually is breaking it!  (???)

Maybe we can get a non-Debian non-FT 2.2.1 tester to try? (otherwise we
are compounding bugs which makes things very difficult to trial)


Markus wrote:
> Anything which I should backport to 6.2?
..
> - recent freetype changes - no idea

I think it is better to wait until changes are settled and commit the
settled backport once rather than backport each individial change. This
keeps the CVS log tidier and easier to follow.


Hamish