wcwidth() is legacy function so that it cannot handle wide, RTL and combined characters correctly. An environment value to select its behavior is one way, but it's just a hack and it's hard to specify in libc.
So, according to UAX#11 definition, it says we should return 1 for EastAsiasnAmbiguous characters unless a rigid signal (like "language tag, script identification, associated font, source of data") is available in UTF-8. It's sure that we can introduce such kind of change for SJIS/EUC-JP, but it's hard to decide for ja_JP.UTF-8. Overall, we have no way to expand wcwidth() correctly and rightly, so I think each application should handle the actual font size of characters instead of using wcwidth(). 2009/1/9 <d+...@vdr.jp>: > On Fri, Jan 09, 2009 at 01:56:20AM +0900, GOTO Masanori wrote: >> I don't agree with the concept of "UTF-8-CJK" because it's over >> exaggerated. Is it a locale dependent issue, or character encoding >> issue? > > I treat ``UTF-8-CJK'' locale as just workaround. > Nothing could be better than using only UTF-8 locale. > >> According to UAX#11, your point doesn't make sense because your >> reference just mention about character mapping. Instead, "When >> processing or displaying data" section says, >> >> "Ambiguous characters behave like wide or narrow characters depending >> on the context (language tag, script identification, associated font, >> source of data, or explicit markup; all can provide the context). If >> the context cannot be established reliably, they should be treated as >> narrow characters by default." > > I see. > >> If the all legacy applications use wcwidth() supposing the width of >> ambiguous font size = 2, it's OK to introduce your idea - but I'm not >> sure it's true or not. >> >> Font rendering application should basically consider the font size. >> Why doesn't rxvt consider about such font rendering size? Or should >> we introduce special environment variable or locale tag to decide the >> behavior of wcwidth value for ambiguous characters? > > For legacy applications' concern, it is good that selectable. > If legacy applications are negligible, > settled setting is better for users' convenience. > But libc and locales are so fundamental, > it is possible that its rigidity is a cause of concern... > > Regards, > dai > -- > > > > -- > To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
