libs/newlib-cygwin
libs/newlib-cygwin
4
0
Fork 0
mirror of git://sourceware.org/git/newlib-cygwin.git synced 2025-01-18 12:29:32 +08:00
Code Issues Projects Releases Wiki Activity

* new-features.sgml (ov-new1.7-misc): Add new link libs.

Browse Source 
* setup2.sgml (setup-locale-ov): Explain locale-specific wcwidth
	feature.
This commit is contained in:
Corinna Vinschen 2009-06-19 09:33:45 +00:00
parent 344ea7b658
commit d66550cae6
3 changed files with 29 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
winsup/doc/ChangeLog
View File

@ -1,3 +1,9 @@
2009-06-19 Corinna Vinschen <corinna@vinschen.de>
* new-features.sgml (ov-new1.7-misc): Add new link libs.
* setup2.sgml (setup-locale-ov): Explain locale-specific wcwidth
feature.
2009-06-12 Ken Brown <kbrown@cornell.edu>
* faq-using.xml (faq.using.emacs): Update.

2
winsup/doc/new-features.sgml
View File

@ -268,6 +268,8 @@
<screen>
- New ldd utility, similar to Linux.
- New link libraries libdl.a, libresolve.a, librt.a.
- Fallout from the long path names: If the current working directory is
longer than 260 bytes, or if the current working directory is a virtual
path (like /proc, /cygdrive, //server), don't call native Win32 programs

25
winsup/doc/setup2.sgml
View File

@ -177,10 +177,27 @@ default ASCII-only behaviour.
</para>
<para>
Right now the language and territory content is not evaluated by Cygwin any
further. The only important part so far is the character set. How does that
work?
</para>
Right now the language and territory, as well as the modifier, are not
important to Cygwin, except to fix a single problem. There's a class of
characters in the Unicode character set, called the "CJK Ambiguous Width
Character set". For these characters the width returned by the
wcwidth/wcswidth function is usually 1. This is often a problem in
East-Asian languages, which historically use character sets in which
these characters have a width of 2. Kind of explains why they are
called "ambiguous"...</para>
<para>
The problem has been fixed for now like this. wcwidth/wcswidth usually
return 1 as the width of these characters. However, if the language is
specifed as "ja" (Japanese), "ko" (Korean), or "zh" (Chinese), wcwidth
returns 2 for these characters. Unfortunately this isn't correct in
all circumstances, so the user can specify the modifier "@cjknarrow",
which modifies the behaviour of wcwidth/wcswidth to return 1 for the
ambiguous width characters to return 1 even in those languages.</para>
<para>
Other than that, the only important part so far is the character set.
How does that work?</para>
</sect2>