bugGNU troff - Bugs: bug #42233, wcwidth(3) used on UCS4/UTF-32...


bug #42233: wcwidth(3) used on UCS4/UTF-32 codepoints

Submitted by:  None
Submitted on:  Tue 29 Apr 2014 11:20:30 AM UTC  
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Tue 29 Apr 2014 12:09:54 PM UTC, comment #1:

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.

Tue 29 Apr 2014 11:20:30 AM UTC, original submission:

I think currently groff makes false use of wcwidth(3): if it finds the `unicode' property in a `DESC' file it uses wcwidth(3) to determine the visual width, not taking into account the current locale, but which wcwidth(3) depends upon.
Also groff uses UCS4 / UTF-32 code points, but (unfortunately) neither ISO C nor POSIX specify the character set that wchar_t uses, and in fact at least the Citrus project (*BSD and deriviatives) uses some homebrew bit pattern for several (asian) locales.

Whereas GNULib also offers wcwidth-replacement functions which are defined to use UCS4 / UTF-32 code points, one of my personal projects is a Unicode aware library, and, short, i'm attaching a patch that implements a `unicode_is_fullwidth()' functionality, which is what the current code requires to have.
The neat side effect of that is that the entire GNULib can be
unhooked and removed from groff(1).
The attached program `uniwidth.c' can be used to verify that the implementation is correct.

So, after applying patches `0001-Drop-wcwidth-3-in-favour-of-Unicode-6.3.0-homebrew-v.patch' and `0002-Unhook-GNUlib.patch' all that is needed to bring groff into a much nicer state is

$ git rm -rf src/libs/gnulib && git commit -m 'Drop GNUlib'



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #31272:  0002-Unhook-GNUlib.patch added by None (7KiB - text/x-diff)
file #31273:  uniwidth.c added by None (3KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.




Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2014-04-29 None Attached File- => Added 0001-Drop-wcwidth-3-in-favour-of-Unicode-6.3.0-homebrew-v.patch, #31271
    Attached File- => Added 0002-Unhook-GNUlib.patch, #31272
    Attached File- => Added uniwidth.c, #31273

Back to the top

Powered by Savane 3.3