Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8

2008-03-15 Thread VDR dai (deb)
Package: locales Version: 2.7-9 Severity: normal First, this has been reported to upstream, but there is no progress for a while. Please allow me to report same one. http://sourceware.org/bugzilla/show_bug.cgi?id=4335 Accor

Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8

2009-01-08 Thread GOTO Masanori
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? According to UAX#11, your point doesn't make sense because your reference just mention about character mapping. Instead, "When processing or displaying data"

Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8

2009-01-08 Thread d+deb
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 U

Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8

2009-01-10 Thread Masanori Goto
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

Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8

2009-01-11 Thread d+deb
On Sun, Jan 11, 2009 at 11:17:48AM +0900, Masanori Goto wrote: > 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

Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8

2009-01-11 Thread Masanori Goto
It'd be great that you propose the good way to do so alternatively. 2009/1/11 : > On Sun, Jan 11, 2009 at 11:17:48AM +0900, Masanori Goto wrote: >> wcwidth() is legacy function so that it cannot handle wide, RTL and >> combined characters correctly. An environment value to select its >> behavior

Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8

2009-01-11 Thread d+deb
On Sun, Jan 11, 2009 at 11:53:21PM +0900, Masanori Goto wrote: > >> 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(). > > But each application implements each a

Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8

2013-06-05 Thread SATOH Fumiyasu
Hi, FYI. I've created a $LD_REPLOAD-able library and a wrapper script to run a command with CJK-friendly wcwidth(3) implementation for fixing "East Asian Ambiguous Width chars" problem. https://github.com/fumiyas/wcwidth-cjk Regards, -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas