[Bug localedata/21750] column width of characters incompatible with classical wcwidth

[maiku.fabian at gmail dot com]

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.