On Wed, 2005-03-02 at 05:36, Neil Williams wrote: > To me, it seems that we are passing a const char * to pango_layout_set_text() > when it is expecting a UTF-8 wchar_t wide char string.
Actually, I think that's slightly wrong. pango wants UTF-8 strings, which conveniently fit into char* ... since the whole point of UTF-8 was to traffic ASCII unmodified and everything else within ASCII [via escaped multi-character sequences]. The wchar_t types are a different, 32-bits-per-character [!] type that I believe is UCS-4 encoding. I'm almost positive we want UTF-8. > Is this a character set issue (i.e. am I the only one seeing this) or should > these functions be converting const char to const wchar_t* using the C > library before calling pango? Hmm. I'm not sure where this is creeping in. I'm definitely not seeing the warnings, so it may be something on your side or in non-US locale [which I should have but didn't check yesterday]. I've not looked, but I imagine libxml/xml-parsing should return UTF-8, char* strings; we may need to set some settings to ensure this. GTK/Pango should traffic in UTF-8 char* strings. Since those [data-file, user-interface] are the two main ways to get data into memory, that should cover our bases. Do you see the issues on new-file-creation? Can you isolate the source of the strings? Certainly both US and English date strings should be ASCII-only. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel