This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


https://sourceware.org/bugzilla/show_bug.cgi?id=21750

--- Comment #5 from Mike FABIAN <maiku.fabian at gmail dot com> ---
Summary of the chatlog in the last comment

https://sourceware.org/bugzilla/show_bug.cgi?id=21750#c4

in English:

Thorsten and me agree that setting the width of U+3248..U+324F
to 2 because the glyphs for these characters are quadratic in
most fonts.

(I also asked on the
Unicode mailing list now whether this could be a bug in
the Unicode data:
http://www.unicode.org/mail-arch/unicode-ml/y2017-m08/0007.html
But even if it is not a bug, setting these to 2 seems to be
much better for users of terminals and that is what wcwidth
in glibc is mostly used for after all).

We also agree to set the width of the hexagrams U+4DC0..U+4DFF is
considerably wider than single width in most fonts. In some
classic Xorg fonts they are fully double width. In most scalable fonts
they are somewhat narrower than double width but considerabely wider
then single width. So marking them as width 1 would cause
problems in terminals, even if they are not fully double width
it makes sense to mark them as width 2 because they certainly
won’t fit in a single character cell in a terminal.

We also agree that the Hangul Jamo U+1160‥U+11FF are sort
of "combining characters" although they are not marked as such
in the Unicode data. But they are fragments of Hangul characters
which combine. So it seems correct to mark them as width 0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]