[Fwd: [1.7] wcwidth failing configure tests]
Sat Jun 13 00:28:00 GMT 2009
On Jun 12 17:38, Thomas Wolff wrote:
> IWAMURO Motonori wrote to me by private mail:
> > I oppose your proposal because I think that it is useless for us.
> > 2009/6/6 Thomas Wolff <email@example.com>:
> >> the intention is that the "codepage" information should be the same
> >> for all locales having thbe "UTF-8" (or any other) charmap. So you
> >> cannot freely change width information among locales with the same
> >> charmap.
> > I don't think that there is such a restriction.
> > The standard of the character doesn't provide for the width of the
> > character as a standard.
> I'm not sure which "standard" you are referring to.
The problem appears to be that there is no standard for the handling
of ambiguous characters.
> I have checked source data files in /usr/share/i18n/charmaps on my Linux system, e.g. "UTF-8.gz".
> These files are used when creating a new locale with the "localedef" command.
> They contain not only the mapping but also (by the end of the file) a
> list of combining and double-width characters. So obviously, even
> stronger than I had argued, this would imply a scheme of predefined
> character widths defined by each such "charmap", thus assuming that
> character widths are the same for all locales with the same "charmap".
I'm not sure the Linux solution is overly flexible. AFAICS, when using
the UTF-8 charset, the ambiguous characters always have width 1. Only
when switching to GB18030, the width of these chars is two. That seems
to be a bit unsatisfying for CJK users.
> >> Also, if ja_JP.UTF-8 would mean "CJK width", how would you specify a
> >> working locale setting for a terminal that does not run a CJK width
> >> font but should yet use other Japanese settings? E.g. with rxvt
> >> which does not support CJK width.
Wouldn't that be covered by using your own proposal just backwards?
Define the default for ja, ko, and zh to use width = 2, with a
@cjknarrow (or whatever) modifier to use width = 1.
> The approach I've taken in mined is quite successful. The other
> approach, via locale names, will also have limited success provided it
> is taken "up-stream".
Whatever "upstream" means.
Cygwin Project Co-Leader
More information about the Newlib