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

[Glynn Clements]

Glynn Clements wrote:

> Hmm. Immediate rendering doesn't work with FreeType fonts at present. 
> You can't use d.font/d.font.freetype as each d.* command is self
> contained. The default font for immediate rendering is set with
> GRASS_FONT, but that currently only supports the stroke fonts. I'll
> fix this today.

Done. As well as all of the environment variables understood by the
PNG driver, immediate rendering now supports:

	GRASS_FONT
	GRASS_FT_FONT
	GRASS_FT_ENCODING

corresponding to the stroke font, FreeType font and encoding for
FreeType fonts. If both GRASS_FONT and GRASS_FT_FONT are set, the
latter takes precedence; if neither are set, the "romans" stroke font
is used.

> Using the driver's built-in FreeType handling has the advantage that
> we can implement anti-aliased text when using the PNG driver
> (including immediate rendering) in true-colour mode.

I've also done this. With the PNG driver (and immediate rendering) in
true-colour mode, text drawn using FreeType fonts is now anti-aliased. 
Additionally, if translucency is enabled (GRASS_TRANSPARENT), the
translucency is propagated to the image's alpha channel (plotting
translucent on top of opaque results in opaque, while translucent on
top of transparent results in translucent).

> The FreeType text rendering uses the driver's draw_bitmap operation,
> which isn't directly exposed (i.e. there is no R_draw_bitmap() or
> similar). d.text.freetype uses R_raster_char().
> 
> The draw_bitmap operation could easily be extended to support
> anti-aliasing. Currently, the bitmap is one byte per pixel, with zero
> indicating transparent and non-zero indicating opaque. Changing it to
> an alpha channel would involve removing the "... > 128 ? 1:0" from
> lib/driver/text3.c:272 and having the driver's draw_bitmap operation
> either perform the check itself (for XDRIVER or for the PNG driver
> using indexed colour) or using anti-aliasing (for the PNG driver using
> true colour).
> 
> Actually, we could just make the draw_bitmap operation available
> through an R_draw_bitmap() function for d.text.freetype to use.

I've also done this (it's just called R_bitmap()). The prototype is:

int R_bitmap(int ncols, int nrows, int threshold, const unsigned char *buf)

It should be relatively straightforward for d.text.freetype to use
this instead of R_raster_char().

The format of the data (buf) is exactly what FreeType produces for
ft_render_mode_normal, i.e. each byte is an opacity between 0
(transparent) and 255 (opaque). Text is drawn using the current colour
(i.e. the same as lines, polygons etc).

The threshold parameter is used by drivers which don't support
translucency (i.e. XDRIVER, or the PNG driver in indexed-colour mode). 
In that case, values above the threshold result in a opaque pixel,
those below produce a transparent pixel (i.e. no pixel).

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