This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Fwd: [1.7] wcwidth failing configure tests]


2009/6/13 Thomas Wolff <towo@towo.net>:
> I have checked source data files in /usr/share/i18n/charmaps on my Linux system, e.g. "UTF-8.gz".
<snip>
> character widths are the same for all locales with the same "charmap".

It was reported as a bug, but it isn't fixed now...X-(

http://sourceware.org/bugzilla/show_bug.cgi?id=4335
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471021

> If you think you can get your proposal passed "up-stream",
> go ahead and try it, please! If you succeed, everything is fine.

 Hmmm, I think that you have misunderstood something because my
explanation is bad.
 I called "up-stream" as the maintainance team of each OS, library, or
application.
 I don't think that there is something single "up-stream".

Japanese language users have tried to fix of the problem for many
years, but it doesn't progress so much now.

>> - In NetBSD, the change to which wcwidth of East Asian Ambiguous Characters returns 2 by CJK locale is planned.
> So the same issue (of compliance and portability, especially in the
> remote case) should be discussed in the NetBSD community.
> (Is there a suitable forum or mailing list to check?)

Sorry, I don't know it because I was personally advised by one of the
NetBSD maintainer ( http://www.hi-matic.org/ (written in Japanese) ).

>> I think that ALL locale implementations should treat East Asian
>> Ambiguous Character Width as 2 for CJK locale.
> Again, I agree that IF you manage to get ALL implementations to follow
> this approach, the solution is fine. Please go ahead.

I will do so, but I want to solve the problem on Cygwin first of all.

>> How to detect it? The application using wcwidth is not necessarily
>> executed with terminal emulator. (e.g. text formatter)
> OK, my arguments refer to an interactive application that wants to
> control the precise representation of text on the screen.
> If for example a text formatter formats for paper printing, it would
> need to apply completely different assumptions anyway. The dreadful
> single/double width issue of cell-based terminals isn't relevant at
> all in that case.

I am assuming the application that depends on the fixed-pitch font as
text-formatter. (like 'indent' command)

I hope the following two results become the same.
- the auto-format filter program using 'wcwidth'.
- run auto-format command on editor. (e.g. "fill-paragraph",
"indent-region", etc on Emacs)
-- 
IWAMURO Motnori <http://vmi.jp/>

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]