On Wed, 31 Jan 2001, Tomohiro KUBOTA wrote:
> Now I have no plan of improvement. Though I wrote about great rewriting
> using ucs4_t instead of wrong wchar_t and unsigned int, I think this is
> of low priority. I have not found any bugs so far. However, I think the
> following points should be fixed.
>
> - we will have to insert more #ifdef's for nl_langinfo() and wcwidth()
> and modify ./configure script. (I entirely don't know how to use
> autoconf and automake.)
Agreed. I should be able to take care of that.
I guess we should also check for iconv() too.
> - I am now rewriting the manpage. I will at least write about my
> options (-8, -u8, -lc, and -wc*) and my resources (encodingMode and
> widthMode).
Good to hear.
> > Does ISO-2022 see much/any use as the locale encoding, or it it just used
> > for interchange?
>
> I think the fullset of ISO-2022 is not used as the locale encoding.
> (It cannot be used as locale encoding for Linux/Glibc because Glibc
> adopts UCS-4 as wchar_t.) However, a few (but popular in Japan)
> softwares such as jless, lv, and so on use ISO-2022 as the default
> encoding for output. This is because ISO-2022 is almost free from
> 'mojibake' - broken characters caused by encoding mismatching.
Isee. Well, maybe one day.
--
Robert Brady
[EMAIL PROTECTED]
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
