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  
 
Severity: 3 - NormalItem Group: None
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: None

Add a New Comment (Rich MarkupRich 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.

Anonymous
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'

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #31272:  0002-Unhook-GNUlib.patch added by None (7kB - text/x-diff)
file #31273:  uniwidth.c added by None (3kB - 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 click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 3 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Tue 29 Apr 2014 11:20:30 AM UTCNoneAttached 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.1-cleanup