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 <t...@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 -- Corinna Vinschen Cygwin Project Co-Leader Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
