[GRASS5] [bug #2129] (grass) d.text.freetype: bad rendering

[Hamish]

> Looking at the d.text.freetype source code, it appears to be guessing
> the pitch[1] of the rendered bitmap from the width, rather than
> reading it from the FT_Bitmap structure. That would certainly explain
> your symptoms, although there may be other problems.
> 
> [1] The number of bytes between the start of one row and the next.
...
> The most likely mode of failure is that the conversion is wrong,
> probably because it's making certain assumptions about the layout of
> the bitmap data which turn out to be incorrect (at least, for you; the
> minimal testing which I did worked, and presumably the same applies to
> Huidae).
> 
> Actually fixing this will require reading the FreeType documentation
> rather than trial-and-error.


You're correct, it is the pitch.

The line should be j = face->glyph->bitmap.pitch;

I wonder if the remaining (7 ... % 8) etc in the bitwise algebra that
follows is damaging the crispness of the characters..

Anyway it seems to work with any TrueType font I have sitting around on
my system using the path=/a/b/c/fontname.ttf option.

The freetype documentation is actually extraordinarily good, and I
think it would not be all that hard to get libfreetype's anti-aliasing
or some crude alpha-blending to work if anyone felt so inclined.

What's the feeling on changing the meaning of parameters for 5.3?
d.text.freetype has a -p flag which changes the east_north= location-
setting option to use window-pixel coordinates instead. I'd prefer to
change this to mean "percent" not "pixel" or add an at= option like
d.barscale to set position as a percentage of the screen width/height.
Having all three -p, e_n=, and at= seems a bit crowded, but maybe
preferred?


thanks,
Hamish