This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
[Bug localedata/19852] New: [2.22 Regression] Incorrect wcwidth for U+3099 and U+309A
- From: "egmont at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: libc-locales at sourceware dot org
- Date: Tue, 22 Mar 2016 09:12:18 +0000
- Subject: [Bug localedata/19852] New: [2.22 Regression] Incorrect wcwidth for U+3099 and U+309A
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=19852
Bug ID: 19852
Summary: [2.22 Regression] Incorrect wcwidth for U+3099 and
U+309A
Product: glibc
Version: 2.23
Status: NEW
Severity: normal
Priority: P2
Component: localedata
Assignee: unassigned at sourceware dot org
Reporter: egmont at gmail dot com
CC: libc-locales at sourceware dot org
Target Milestone: ---
(After running setlocale() with en_US.UTF-8 or something similar)
wcwidth() for U+3099 and U+309A (and presumably a few others) returns:
 0 in glibc up to 2.21,
 2 in glibc 2.22 & 2.23.
Quoting from Unicode 8.0:
http://unicode.org/reports/tr11/
"ED4. East Asian Wide (W): All other characters that are always wide."
"6.2 Combining Marks [...] nonspacing marks used only with wide characters are
given a W."
http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt
"3099..309A;W # Mn [2] COMBINING [...]"
According to these, I believe the correct return value would be 0 (it's a
non-spacing mark).
Markus Kuhn's wcwidth (https://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c) also
returns 0.
We found this originally being reported against VTE (the terminal emulation
widget behind gnome-terminal and others) causing incorrect look there:
https://bugzilla.gnome.org/show_bug.cgi?id=762052. The conclusion there
(beginning at comment:22) was also the same: it should return 0.
--
You are receiving this mail because:
You are on the CC list for the bug.