There doesn't appear to actually be a space, but the same problem
occurs when running d.text.freetype from the command line, i.e. it's a
problem with d.text.freetype.
Actually, the fact that the space is missing it is a problem with freetype 2.2.1:
So apparently not much we can do about it, just have to wait for the fix to propagate to distributions or tell people to compile the cvs version ...
Unless we can use ft_render_mode_normal, instead of ft_render_mode_mono, but trying that I just get completely garbled output on the screen, and I don't have the time now to look into this any further.
So apparently not much we can do about it, just have to wait for the fix
to propagate to distributions or tell people to compile the cvs version ...
Unless we can use ft_render_mode_normal, instead of ft_render_mode_mono,
but trying that I just get completely garbled output on the screen, and
I don't have the time now to look into this any further.
I see this on Debian/stable using an older version of Freetype,
So apparently not much we can do about it, just have to wait for the fix to propagate to distributions or tell people to compile the cvs version ...
Unless we can use ft_render_mode_normal, instead of ft_render_mode_mono, but trying that I just get completely garbled output on the screen, and I don't have the time now to look into this any further.
I see this on Debian/stable using an older version of Freetype,