Subject: Re: CHARSET environment variable

From: Olivier Chapuis <[email-masked]>
Date: Fri, 1 Feb 2002 08:54:18 +0100

On Thu, Jan 31, 2002 at 09:41:39PM -0500, Dan Espen wrote:
> 
> I have multibyte enabled.
> With the latest CVS I get this warning:
> 
> [FVWM][FInitCharset]: WARN -- Cannot get charset with CHARSET env variable
> 
> Where do I find the documentation on this env variable?
>

Hum, I do not know if there is a documentation somewhere. This variable
is used by some programs in the gnu world to get the charset associated
to your locale if your libc does not have nl_langinfo which can do the
job (it seems that you do not have nl_langinfo). It can also be used to
override the charset returned by nl_langinfo.
Now, it is not used in mb support but in the ewmh support for iconv
conversion from/to UTF-8 and your charset. If you have iconv
you can get the list of charsets by using "iconv --list".
There are multiple problems here:

1 - FInitCharset is run by fvwm even if you do not have iconv
support (easy to fix).
2 - nl_langinfo may return a different charset than the "X charset".
3 - iconv is not an X function.

So nl_langinfo and iconv should not be used :o) but it does not
seem that there are obvious (portable) replacement (XFree >=4.0.2
has some Xutf8 functions, we may try to use if available).
I will try to fix these problems progressively. I begin to understand
the X i18n stuff. Any way these problems are small and these concern
only applications with ewmh support (but these should be fixed).

Olivier

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Fri, 1 Feb 2002 16:01:33 +0600

> has some Xutf8 functions, we may try to use if available).

	Please, please, please don't use Xutf8*() functions -- they are
absolutely unportable.  They were introduced due to the inadequacy (sp?)
of the current X locale model: only one locale at one moment, so Xutf8*()
are "current-locale"-independent.  But their unportability completely
outweighs their advantage.

	_________________________________________
	  Dmitry Yu. Bolkhovityanov
	  The Budker Institute of Nuclear Physics
	  Novosibirsk, Russia

---

From: Dan Espen <[email-masked]>
Date: Fri, 01 Feb 2002 11:16:18 -0500

> only applications with ewmh support (but these should be fixed).

I looked at the various codesets iconv supports to try to figure out
a default value.

It looks like if  CHARSET is not set,  is should default to ISO_8859-1
(on Linux).

On Solaris and AIX, the default should be ISO8859-1.

On HPUX, it looks like it should be either "amere", "iso81", or "engle".

I'd be happy if it just didn't print any warning.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 1 Feb 2002 16:30:18 +0100

> outweighs their advantage.

Do there are bad or only unprotable? If there are bad only because
there are not protable this may be fixed as xterm do: xterm has
a file with these functions in the case the "locale" Xlib does
not have it (xterm -u8 work fine with XFree-3.3.6 and old glibc).

What happen is that for ewmh support fvwm should deal with
utf8 strings for window names: a window can gives its names
with an UTF-8 string and fvwm should set on the window
the names that it really used in UTF-8 (this name may be
different form the original window name: xterm, xterm (1),
xterm (2) ...). Moreover, more and more utf-8 strings will
appear in the future.

So now what we should do for performing conversion?
In the average (lib)iconv seems to give good result but
it speaks an other language than X. Maybe the Xutf8*
function may help at some points? Any other ideas?
Also what to do for displaying directly utf8 strings
(with a libc which does not support utf8 locales)?
Is XRender/Xft can do that? Really any suggestion is
welcome. But, any way at the present time the most
important thing is to centralize all the fvwm text
rendering and locale stuff in 2 or 3 libs file so that
we can really works on all this locale stuff which is
a real (interesting) mess IMHO.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 3 Feb 2002 07:34:19 +0100

> On HPUX, it looks like it should be either "amere", "iso81", or "engle".

How to set this default? Do we have "cpp variables" which allows to write
down somthing like:

#ifdef SYS_A
#define DEFAULT_CHARSET   "FOO"
#endif
#ifdef SYS_B
#define DEFAULT_CHARSET    "XYZ"
#endif

...etc in libs/defaults.h ?

> I'd be happy if it just didn't print any warning.

Why are you against such warning? This may help to debug
the (experimental) iconv stuff. For example, with the error
message you send to me I can see that you do not have
nl_langinfo and  that no iconv conversion will be performed
at all. On the other hands, we can document our use
of the CHARSET variable. But as our UTF-8 support is not
finalized this should wait a bit. Any way, if you really want
I can suppress such warnings now or only in the future beta
version of 2.5.x.

Olivier

---

From: Dan Espen <[email-masked]>
Date: Sun, 03 Feb 2002 11:06:44 -0500

Olivier Chapuis <[email-masked]> writes:
> > > > [FVWM][FInitCharset]: WARN -- Cannot get charset with CHARSET env varia
...

> ...etc in libs/defaults.h ?

Run configure tests using iconv trying to find the one that works?

> I can suppress such warnings now or only in the future beta

I just didn't want to see the  warning generated in official releases,
we'll get loads of email about it.  As long as 2.5.x is an unsupported
release, its OK.