Follow-up Comment #1, bug #42233 (project groff): Hm. After updating my ArchLinux the test program `uniwidth.c' shows two errors which i haven't seen a month ago.
For one wcwidth(3) now returns `2' for 64 HEXAGRAM's (U+4DC0-U+4DFF; HEXAGRAM FOR THE CREATIVE HEAVEN - HEXAGRAM FOR BEFORE COMPLETION). This i claim wrong again, because the Unicode `EastAsianWidth.txt' clearly classifies them with the East_Asian_Width property `N' (<http://www.unicode.org/reports/tr11/>). Second, when compiled with `-DLIBUNISTRING -lunistring' the program crashes because the GNULib function uc_width() doesn't seem to allow NULL now; when changing the NULL to "utf-8" i know get 107 inequalities. What i yet have looked at i am right: e.g., U+2EF4 is not currently assigned in Unicode and therefore must be treated as `N'; it is very likely that it will be fullwidth once it is assigned, since it is in the CJK range, however. Ditto U+3040 (HIRAGANA), U+A48D (YI SYLLABLE) ... and most likely etc. P.S.: oops, i have no account! this is sdaoden AT yandex DOT com. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?42233> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ bug-groff mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-groff
