2009/6/15 Corinna Vinschen:
Define the default for ja, ko, and zh to use width = 2, with a
@cjknarrow (or whatever) modifier to use width = 1.
I think it is good idea.
If everybody agrees to this suggestion, here's the patch. Tested
with various combinations like
Hi.
2009/6/27 Andy Koppe andy.ko...@gmail.com:
And then there's the Linux compatibility angle, where ja_JP.UTF-8
means ambiguous width 1 not 2.
I want you not to judge it based on the behavior of current Linux.
Because:
- I don't think the behavior is correct.
- Now, I am creating the patch
I wrote:
Despite IWAMURO Motonori's withdrawal, I think symmetry would be the
right approach to take. The major aspect is how to reflect the actual
behaviour of existing terminal environments. ...
...
The locale interface (syntax and semantics of LC_* strings) is defined
in a modular way
On Jun 19 13:02, Thomas Wolff wrote:
I wrote:
Despite IWAMURO Motonori's withdrawal, I think symmetry would be the
right approach to take. The major aspect is how to reflect the actual
behaviour of existing terminal environments. ...
...
The locale interface (syntax and semantics of
2009/6/16 Corinna Vinschen corinna-cyg...@cygwin.com:
On Jun 15 23:35, IWAMURO Motonori wrote:
2009/6/15 Corinna Vinschen:
If everybody agrees to this suggestion, here's the patch.
Is the name of modifier prefix cjk- good? It influences not CJK
characters but a part of symbols and European
On Jun 18 14:09, thomas.wo...@nsn.com wrote:
2009/6/16 Corinna Vinschen
However, besides of being unnecessary, other systems like Linux or BSD
use the language string as directory name relative to the
/usr/share/locale directory. ?If this gets ever used on non-Cygwin
systems, the
2009/6/18 Thomas.Wolff:
And as a matter of fact,
you can run both xterm and MinTTY with a non-CJK locale and ambiguous
characters being wide. This is achieved by invoking xterm -cjk_width or
by selecting an according font in MinTTY, e.g. Ming, SimSun, MS Mincho,
or even just the popular
On Jun 14 22:18, IWAMURO Motonori wrote:
2009/6/13 Corinna Vinschen
The problem appears to be that there is no standard for the handling
of ambiguous characters.
Yes, but the guideline exists.
http://cygwin.com/ml/cygwin/2009-05/msg00444.html
A single mail in a single mailing list of a
2009/6/15 Corinna Vinschen corinna-cyg...@cygwin.com:
Yes, but the guideline exists.
http://cygwin.com/ml/cygwin/2009-05/msg00444.html
A single mail in a single mailing list of a single project. That's rather
a suggestion than a guideline...
Sorry, my writing was bad. My quotation is a part
On Jun 15 23:35, IWAMURO Motonori wrote:
2009/6/15 Corinna Vinschen:
If everybody agrees to this suggestion, here's the patch.
Is the name of modifier prefix cjk- good? It influences not CJK
characters but a part of symbols and European characters.
Please refer to Andy's opinion:
OK. I withdraw my proposal.
2009/6/16 Corinna Vinschen corinna-cyg...@cygwin.com:
On Jun 15 23:35, IWAMURO Motonori wrote:
2009/6/15 Corinna Vinschen:
If everybody agrees to this suggestion, here's the patch.
Is the name of modifier prefix cjk- good? It influences not CJK
characters but a
2009/6/13 Thomas Wolff t...@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-(
2009/6/13 Corinna Vinschen vinsc...@redhat.com:
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.
Yes, but the guideline exists.
http://cygwin.com/ml/cygwin/2009-05/msg00444.html
2) Unicode Standard
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
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
2009/6/5 Thomas Wolff:
the locale syntax allows for an optional modifier which can be used to
specify deviations, e.g.
de_DE has charmap ISO-8859-1
de...@euro has charmap ISO-8859-15
uz_UZ has charmap ISO-8859-1
uz...@cyrillic has charmap
On Jun 5 18:25, Thomas Wolff wrote:
IWAMURO Motonori wrote:
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
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
nit-picking
Thomas, couldn't you have discussed this in the two weeks I was on
vacation? Why did you wait until I implemented the language-based
approach?
/nit-picking
Sorry, that's largely my fault. Among a bunch of other MinTTY issues
we were privately discussing various more or less mad
# Continuation of discussion.
#
# I hope that all the applications work correctly only by setting
LANG=ja_JP.UTF-8.
# I don't hope that I give up the use of the binary packages and that
I keep applying many local patches.
I don't think that it is the good idea because:
- It is a
2009/6/6 Andy Koppe andy.ko...@gmail.com:
However, to make the locale setting more convenient for CJK users,
there could be modifiers for both widths. Without modifier, the CJK
locales would default to Ambiguous Wide, while everything else would
default to Ambiguous Narrow.
It is acceptable
2009/6/6 Corinna Vinschen corinna-cyg...@cygwin.com:
I vote for @cjkwide, regardless of Andy's objection. People using CJK
will know the meaning and it has the additional advantage to be a rather
simple to memorize identifier.
I oppose @cjkwide approach because I don't think that I need make
IWAMURO Motonori wrote:
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
I correct my proposal.
2009/5/15 IWAMURO Motonori deenhe...@gmail.com:
I propose to use *_cjk() when the language part of LC_CTYPE
is 'ja', 'ko', 'vi' or 'zh'.
LC_CTYPE is 'ja', 'ko', or 'zh'. I remove 'vi'. (advice from a NetBSD
locale part maintainer)
--
IWAMURO Motnori http://vmi.jp/
--
Corinna Vinschen wrote:
On May 12 17:56, Andy Koppe wrote:
And here's another question. ?The utf8*.h files claim they have been
generated from the unicode.txt file of the Unicode 3.2 standard. ?Do we
have the script which generated the utf8*.h files? ?Can we regenerate
the files to
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
On May 14 17:51, Jeff Johnston wrote:
Corinna, I have no problem with checking the new patch in and extending
this later, assuming you have thoroughly tested this implementation.
I tested it with _MB_CAPABLE defined and with _MB_CAPABLE undefined.
Both variations worked as expected, the
2009/5/13 Corinna Vinschen vinsc...@redhat.com:
http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
This looks nice.
Do you import Markus Kuhn's wcwidth implementation?
Trouble is, there's the thorny issue of the CJK Ambiguous Width
category of characters, which consists of things like Greek and
On May 15 00:58, IWAMURO Motonori wrote:
2009/5/13 Corinna Vinschen vinsc...@redhat.com:
http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
This looks nice.
Do you import Markus Kuhn's wcwidth implementation?
Trouble is, there's the thorny issue of the CJK Ambiguous Width
category of
Corinna Vinschen wrote:
On May 15 00:58, IWAMURO Motonori wrote:
2009/5/13 Corinna Vinschen vinsc...@redhat.com:
http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
This looks nice.
Do you import Markus Kuhn's wcwidth implementation?
Trouble is, there's the thorny
2009/5/12 Corinna Vinschen:
Trouble is, there's the thorny issue of the CJK Ambiguous Width
category of characters, which consists of things like Greek and
Cyrillic letters as well as line drawing symbols. Those have a width
of 1 in Western use, yet with CJK fonts they have a width of 2.
On May 13 20:04, Andy Koppe wrote:
2009/5/12 Corinna Vinschen:
Trouble is, there's the thorny issue of the CJK Ambiguous Width
category of characters, which consists of things like Greek and
Cyrillic letters as well as line drawing symbols. Those have a width
of 1 in Western use, yet with
How should that work? The first half of the surrogate pair has not
enough information to decide that. For instance, take the ranges
0x10A01, 0x10A03 }, { 0x10A05, 0x10A06 }. The information about the low
10 bits of the Unicode value is in the second half of the pair. From
the first half
Forwarded to newlib.
- Forwarded message from Eric Blake -
Date: Tue, 12 May 2009 16:02:04 + (UTC)
From: Eric Blake
Subject: [1.7] wcwidth failing configure tests
To: cygwin AT cygwin DOT com
I noticed this failure in various configure scripts (findutils, coreutils,
...):
And here's another question. The utf8*.h files claim they have been
generated from the unicode.txt file of the Unicode 3.2 standard. Do we
have the script which generated the utf8*.h files? Can we regenerate
the files to match the current Unicode 5.1 standard?
There's Markus Kuhn's wcwidth
On May 12 17:56, Andy Koppe wrote:
And here's another question. The utf8*.h files claim they have been
generated from the unicode.txt file of the Unicode 3.2 standard. Do we
have the script which generated the utf8*.h files? Can we regenerate
the files to match the current Unicode 5.1
36 matches
Mail list logo
