This bug is still present in 2.1 Beta 4 and has been tested under Windows 98 and Windows XP SP2.

Same behaviour as before: When entering Umlaute or ß the whole line of text becomes invisible.

I already needed to compile libiconv to be able to compile gettext/libintl, so I guess that should work.
This fixes it: (void)bind_textdomain_codeset(PACKAGE, "UTF-8");
-> r4118

Actually, the only encodings that GLC is aware of are : UCS-1, UCS-2, UCS-4 and UTF-8. If you try to use GLC with any other encoding, the result is undefined.

In Warzone, the string is not displayed by QuesoGLC because GLC fails internally to convert the string from UTF-8 to UCS-4. Indeed, when the string is not UTF-8 encoded, the GLC converter reports an error about an ill-formed UTF-8 string which causes glcRenderString() to raise a GLC_PARAMETER_ERROR and to abort. This error is not raised for other encodings because the conversion from UCS-1 (or UCS-2) to UCS-4 never fails. However, this conversion leads to rubbish in most cases.

I already received e-mails of complaints of users who tried to use QuesoGLC with a "locale encoded" string. So far, there is nothing to do but to convert the locale string into one of the encoding that QuesoGLC knows about. At first, I would say that libiconv is our friend but I do not know if it is portable or not (especially for Windows).

Finally, the escape sequence "\<xxx>" is obtained when the character is correctly interpreted by GLC but the corresponding glyph can not be found out. In other words, escape sequence are issued because the font coverage is insufficient not because the encoding is unknown.

I hope this helps.

If we use glcStringType(GLC_UTF8_QSO); while the locale is not an UTF-8 locale, this happens. (In reversion: If we do not set the string type to utf-8 for those locales, they seem to work.)