Subject: Re: shortcomings in XPG locale

From: Erik M. van der Poel <[email-masked]>
Date: Fri, 19 Apr 91 23:38:21 +0900

> > > 1. There is no LC_BIDI database to store direction information.
> > > 	Did X/Open ever think about Hebrew and Arabic?
> > 
> > While we're at it, we might as well consider vertical printing, as is
> > sometimes used in Japan. So maybe we should call it LC_DIRECTION, or
> > LC_TEXTDIRECTION, or maybe just include it in LC_CTYPE?
> 
> Yes, LC_DIRECTION sounds like a good name.  And perhaps text direction
> really is related to character type.

Adding a new category may be a good idea if one wants to give the user
and/or application more control over the settings of each category. At
the POSIX level, each category can be set through environment
variables. At the C level, the setlocale() function can be called on
each category.

On the other hand, we may not want to add too many new categories,
since a large number of e.g. LC_* environment variables may be
confusing. I guess this is a kind of trade-off.

Also, I'm not sure that LC_DIRECTION can just be put in LC_CTYPE.
POSIX says that LC_CTYPE is for character classification and case
conversion, while C says that LC_CTYPE affects the behavior of the
character handling functions (isalpha, etc) and the multibyte
functions (mbtowc, etc). LC_DIRECTION is not really related to
character type, since e.g. Kanji can be printed horizontally *or*
vertically.

Come to think of it, isn't it strange that LC_CTYPE affects the
behavior of the multibyte functions? This would seem to indicate that
the character encoding depends on the locale, which may be true in
many locales, but there are also locales where the user may be using
e.g. one codeset in the terminal and a different codeset in the files,
or even several different codesets in remote filesystems.

We are trying to achieve codeset independence, but shouldn't this be
separated from the locale model? POSIX has done a lot about this
already, by putting the encoding in the charmap file, and by
specifying character *names* (rather than codes) in the locale
definitions.

On the other hand, the locale setting may be used to determine the
default codeset, assuming a different codeset only when explicitly
told to do so, e.g. in tagged data such as ISO 2022 with its escape
sequences. I.e. if the data does not contain an identifier, you look
at the locale setting to decide what codeset to assume.

Erik M. van der Poel                                      [email-masked]
Software Research Associates, Inc., Tokyo, Japan     TEL +81-3-3234-2692