[Fwd: [1.7] wcwidth failing configure tests]

Corinna Vinschen vinschen@redhat.com
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 <towo@towo.net>:
> >> 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.


Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

More information about the Newlib mailing list