"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> Sure. Perhaps CleanupPath() should better be implemented using nls-safe
> emx lib C string macros internally, only if this not so nice toward
> LString? Or even better make LString clean for Double/triple Byte
> Character Strings?
There are many encodings for even a single language. Consider, for
example, German. There are at least two commonly used encodings:
ISO8859-1 and codepage850. Except for ASCII characters, they
represent the same characters differently in bytes. Next, consider
the situation from the side of application programs. There are
3 places where German characters must be displayed:
- user interfaces, such as menu,
- contents of documents
- file names.
Encodings used in these places must be determined somehow.
We have agreed that the C locale of the |process| specifies the language
together with its encoding of the user interface display string.
The encoding to be used in the contents of a document must be a
property of the |buffer|. LyX 1.0 cannot handle this but fixes the
document encoding to ISO8859-1. Since ISO8859-X for X>1 is mechanically
the same as ISO8859-1, users can use LyX 1.0 for these encodings by
setting the "font norm". However, this is not the real i18n.
LyX 1.1 encoding class will take care of this. See the documentation
for LString (development/Design/encodings.lyx).
Now the encoding used for file names should be the |system| property,
since file systems are mounted by the system. On some flavor of UNIX,
it is allowed to use non-ASCII characters in file names, although
there is no common convention for the encoding used for such character
sets. It is determined site by site. So we will use the standard
C++ string for the maximal configurability for that purpose. However,
on DOS (read Windows 95/98) and OS/2 codepage encodings are used for
file systems, and on Windows NT Unicode is used for the file systems.
On these systems with encoding conventions, it is natural to implement
system specific routines in the operating system interface. Besides,
DOS and Windows NT use '\' as the directory separator, while OS/2
uses both '/' and '\', in contrast to '/' on UNIX and ':' on VMS.
And '\' in a 8 bit string might not be a character but the second byte
of a double byte code character. So the special routines are indeed
required.
Now back to EMX. _nls_* functions in EMX are codepage based but not
locale based internationalization. So the function must be used in
file handling classes rather in string classes.
Regards,
SMiyata
