[Bug localedata/21750] column width of characters incompatible with classical wcwidth
maiku.fabian at gmail dot com
sourceware-bugzilla@sourceware.org
Mon Sep 4 14:33:00 GMT 2017
https://sourceware.org/bugzilla/show_bug.cgi?id=21750
--- Comment #16 from Mike FABIAN <maiku.fabian at gmail dot com> ---
(In reply to Mike Frysinger from comment #15)
> i've forked soft hyphen (U+00AD) into bug 22073 and Hangul Jamo into bug
> 22074. feel free to take follow ups for those topics to those respective
> bugs so the discussion can stay focused and not get cluttered up.
>
> i haven't looked into the other codepoints raised in the original comment,
> so if they aren't resolved, feel free to fork them out too.
For the code points
3248..324F;A # No [8] CIRCLED NUMBER TEN ON BLACK SQUARE..CIRCLED NUMBER EIGHTY
ON BLACK SQUARE
I asked on the unicode mailing list:
http://www.unicode.org/mail-arch/unicode-ml/y2017-m08/0007.html
And the response makes me think that we are free to use wcwidth 2 for
these in glibc if that fits our “context” best:
http://www.unicode.org/mail-arch/unicode-ml/y2017-m08/0023.html
> "A" means, you get to decide whether to treat these as "W" or "N" based on context.
>
> There's really not strong need to change an "A" towards "W", because
> "A" doesn't get in your way if you decided that "W" works better for
> you.
>
> Remember that all the EAW properties ares supposed to be "resolved"
> down to W or N. For some, like Na that resolution is deterministic,
> for A it is context/application dependent, but when you finally
> process your data, only W(ide) or N(arrow) remain after resolution.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Libc-locales
mailing list