[gnome-cyr] Re: broken i18n printing in gedit and gnumeric (fwd)

[Vlad Harchev <hvv hippo ru>]

 Привет!

 Грустная история про BSD.

 Best regards,
  -Vlad

---------- Forwarded message ----------
Date: Sat, 9 Mar 2002 15:43:08 +0400 (SAMT)
From: Vlad Harchev <hvv hippo ru>
Cc: gnumeric-list gnome org
To: Tomas Pluskal <plusik pohoda cz>
Subject: Re: broken i18n printing in gedit and gnumeric

On Sat, 9 Mar 2002, Tomas Pluskal wrote:

 Hi, 

 I believe BSD guys are just wrong. 
 There is no trace in any specs (I checked Unix98 specs) that mbstowcs and
friends should work only for multibyte encodings. So it should be treated as
"should work for any encoding". It's also obvious that singlebyte encoding can
be considered multibyte (but without shift states) - so their statement could 
work against themselves.

 BSD guys should fix locale support in their libc or modify all my patches not
to use some other portable and working way (probably using iconv(3)).

 I won't help with this for free.
 
 Best regards,
  -Vlad

> 
> Hello,
> 
> I was trying to make gnumeric and gedit print Czech characters on FreeBSD
> with no success, and after few hours of investigation I found out, that
> both rely on mbstowcs() functions, which don't work as expected on
> FreeBSD. In the i18n patch from Vlad Harchev, the function mbstowcs is
> used to convert a string from current locale's encoding to unicode. This
> works on linux (glibc), but I believe it is not correct (in the mean of
> portability), because multibyte(3) functions are supposed to be used to
> convert multibyte encodings (like Japanese) and not ISO8859-x charsets
> etc.  In fact, on FreeBSD it doesn't convert current locale to unicode,
> but ascii to unicode. I was consulting it on freebsd mailing lists and
> this was the answer:
> 
> ====cut================================================================
> 
> > I know that ISO8859-2 is not multibyte encoding, but in fact gnumeric,
> > gedit (and I believe a lot of other software) expect the multibyte
> > functions to work anyway (and to work as "translate characters from
> > current locale's encoding to UNICODE" and reverse).
> 
> They are broken.  (Or perhaps they are relying on new behavior in C99,
> but I rather doubt it.)
> 
> > Why does this work in linux ?
> 
> Because Linux (or rather, glibc) implements it the way these broken
> programs expect.
> 
> -GAWollman
> 
> ===cut=================================================================
> 
> Wouldn't it be possible to use another method to convert a string
> in current locale's encoding to utf8 ? For example glib.h function:
> g_locale_to_utf8() ?
> 
> Bye
> 
> Tomas Pluskal
>