[GRASS5] Freetype failure

[Glynn Clements]

roger at spinn.net wrote:

> A couple weeks ago I wrote for help with my problem using freetype.  In 
> short, when I tried to display characters using the freetype library the X 
> driver crashed.  I later found that the PNG driver had the same behavior. 
> 
> In the absence of input, I managed to track the problem down to 
> grass-6.0.2/display/drivers/lib/Text3.c (currently renamed to text3.c).  The 
> convert_str function calls iconv.  The third and fifth parameters in the 
> iconv prototype are pointers to size_t variables.  The convert_str function 
> instead passed pointers to int.  iconv misinterpreted the values and that 
> lead to a corruption of the code.  With the parameters changed to size_t the 
> code works OK. 
> 
> This is the first problem I recall arising from using int and size_t 
> interchangeably.  This may reflect my environment (gcc 4.0.2 prerelease, GNU 
> libc 2.3.5, SuSE Linux 10.0 on AMD64). 
> 
> The initial fix was pretty easy, but in studying the code I found other 
> problems (e.g., arguments to memset in convert_str are in the wrong order).  
> Also, the approach in the code to be rather indirect.  It works by 
> converting UTF-8 codes to UCS-2BE codes and then converting the UCS-2BE 
> codes to FT_ULong for the freetype library.

To be precise, it converts strings from the selected encoding (which
may be UTF-8 or something else) to UCS2-BE.

> Not all UTF-8 codes can be represented in UCS-2BE.

But does FreeType support anything beyond the 16-bit range?

> I wrote a UTF-8 to FT_ULong converter to get a more direct solution and 
> eliminated convert_str from the code.  This is a working solution and 
> probably in most respects a better solution than the current text3.c. 

Except for the most important issue, namely that the input string is
not necessarily in UTF-8; the encoding is specified by the charset=
option to d.font.freetype. As the FreeType support in the display
drivers was originally written to support Japanese, I suspect that
most of the existing users of this functionality probably won't be
using UTF-8.

> I no longer maintain a CVS installation of GRASS but I think these changes 
> need to be made.  I can provide the code to someone who can introduce it to 
> CVS.  As it stands the code is largely complete.  I would like it to be 
> checked by someone who is a more proficient programmer than I. To be 
> formally complete the UTF-8 decoder needs code added to catch malformed 
> UTF-8 2-byte codes in the range of 0xD800 to 0xDFFF.  I think other 
> malformations are caught by my existing code, but their efficiency might be 
> improved. 

Whilst a hard-coded UTF-8 to UCS-2 or UCS-4 decoder might be a useful
fall-back for systems which don't have iconv, the iconv code needs to
stay to support other encodings.

The int/size_t and memset() issues need to be fixed, and converting to
32-bit Unicode should be harmless (although pointless unless FreeType
supports it).

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