Josh Sled jsled at
Mon Mar 14 09:09:40 EST 2005

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.


-- - `a=jsled;; echo ${a}@${b}`

More information about the gnucash-devel mailing list