2009/5/21 Thomas Wolff <t...@towo.net>:
>> > Therefore, I propose to use *_cjk() when the language part of LC_CTYPE
>> > is 'ja', 'ko', 'vi' or 'zh'.
> The problem with this is
> 1. As you say, there is no standard.
But,
- I think that my proposal doesn't violate any specification.
- I heard that there is an existing implementation that behave like my
proposal. (Sorry, I didn't hear the system name.)
> 2. If you wish to handle character widths compliant with the terminal
> your application is running in, there is no guarantee that your
> assumption of CJK width (or the actual locale setting if that model
> would be implemented) does indeed reflect the terminal's width properties.
Yes, I understand it, too. My proposal is completely workaround.
But it is the best solution because we have no specification/standard
for my wish.
> 3. In mintty, you can dynamically change width properties by selecting
> different fonts; mintty changes CJK width behaviour according to certain
> font properties. "static" configuration in your shell using a locale
> variable would not reflect this change
It is no problem because we -- most Japanese language users -- need
not change the settings of mintty and locale after first setup.
We set LANG=ja_JP.UTF-8 and select a Japanese font for mintty.
> I see two ways to handle this:
> a) Ask Andy (author of mintty) to not do this switching;
It is not necessary bacause the mechanism is based on my another
poroposal. ("deenheart" is my handle on google code.)
> other terminals don't switch either.
If we use other terminals, we need switch CJK width option manually.
(xterm, mlterm, putty, ...)
> b) Determine the actual CJK width behaviour dynamically. That's what
> mined does (in addition to other width property detection in general).
It is the best solution. I think that we need specify the following:
- the escape sequence about language context for terminal emulater.
-- setting language context
-- getting language context
-- getting capability of language context
(context is fixed, static or dynamic / acceptable languages)
- new multilingualized string/terminal API for terminal based applications.
And, we need rewrite too many applications by new API.
> I'm not happy with the idea of a cygwin-specific solution (or workaround).
I think that it is not cygwin-specific solution.
--
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/
