bugGNU roff - Bugs: bug #62296, want special characters for...

 
 

bug #62296: want special characters for Unicode box-drawing glyphs

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Mon 11 Apr 2022 11:54:04 PM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  Rejected
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 12 Apr 2022 12:20:48 AM UTC, comment #1: 

Good news, neutral news, and bad news regarding this ticket.

The bad news is that the "groff glyph list"--the repertoire of special character identifiers predefined by the language is basically frozen, and will only change if a strong case can be made for doing so.

The addition of Unicode box-drawing characters does not seem like fertile ground for a strong case; the troff language--even the nroff language before it--already has provision for the drawing of horizontal and vertical rules (lines) of any length, and using any existing glyph.

For typesetter devices, rules can be drawn at any angle, intersect arbitrarily, and don't require a glyph for rendering.

Further, the suggested special character identifiers are of the form "U2500", which is extremely close to the existing (as of 2022, but for the past several years) syntax for arbitrary Unicode code point access.  Why ask a user to type "\[U2500]" when "\[u2500]" will get what they want?

Here's some text from groff_char(7) in groff Git HEAD.


       Unicode encodes far more characters than groff has glyph names
       for; special character escape forms based on numerical code
       points enable access to any of them.  Frequently used glyphs or
       glyph combinations can be stored in strings, and new glyph names
       can be created with the char request, enabling the user to devise
       ad hoc names for them; see groff(7).

       \[unnnn[n[n]]]
              is a Unicode numeric special character escape sequence.
              With this form, any Unicode character can be accessed by
              code point using four to six hexadecimal digits, with
              hexadecimal letters accepted in uppercase form only.
              Thus, \[u02DA] accesses the (spacing) ring accent,
              producing “˚”.

       Unicode code points can be composed as well; when they are, GNU
       troff requires NFD (Normalization Form D), where all Unicode
       glyphs are maximally decomposed.  (Exception: precomposed
       characters in the Latin‐1 supplement described above are also
       accepted.  Do not count on this exception remaining in a future
       GNU troff that accepts UTF‐8 input directly.)  Thus, GNU troff
       accepts “caf\['e]”, “caf\[e aa]”, and “caf\[u0065_0301]”, as ways
       to input “café”.  (Due to its legacy 8‐bit encoding
       compatibility, at present it also accepts “caf\[u00E9]” on ISO
       Latin‐1 systems.)

       \[ubase‐glyph[_combining‐component]...]
              constructs a composite glyph from Unicode numeric special
              character escape sequences.  The code points of the base
              glyph and the combining components are each expressed in
              hexadecimal, with an underscore (_) separating each
              component.  Thus, \[u006E_0303] produces “ñ”.


The above syntax wholly subsumes the purpose of the proposed patch, extending it beyond the box drawing characters to the entirety of the Unicode character set.

The foregoing amounts to a refusal of the originally submitted patch even in principle, that is apart from any technical defects in it.

Speaking of technical defects, the groff_char(7) man page has since 2009 been rewritten in man(7) instead of mdoc(7), and the page-local macro `C2` has been retired.  So the patch would need to be rewritten on those grounds anyway.

Bottom line: whatever defects existed in the `C2` macro have been refactored out of existence, the groff_char(7) man page is comprehensive for the set of predefined groff ordinary and special character identifiers, and it is neither intended to or would it be practical to extend it beyond that purpose (to attempt to list all defined Unicode characters, for instance).

But see the "rfc1345" package in the forthcoming groff 1.23 release.

[[
o The new rfc1345 macro package, contributed by Dorai Sitaram, defines
  special character glyph names implementing RFC 1345 mnemonics (plus
  some additions from Vim, which itself uses RFC 1345 for its digraphs).
  It is documented in the groff_rfc1345(7) man page.
]]

G. Branden Robinson <gbranden>
Group administrator
Mon 11 Apr 2022 11:54:04 PM UTC, original submission:  

Way back in 2009[1], Roger Leigh reported the following issue to the groff mailing list.  It appears to have received no follow-up; I checked the next 3 months of the archive and searched it for "C2".


Dear groff maintainers,

[I'm not subscribed to the list, so a CC on any reply would be
appreciated]

GROFF VERSION: 1.20.1
MACHINE:       amd64 generic
OS:            Debian GNU/Linux
COMPILER:      GCC 4.3.2
INPUT FILES:   groff_char-box.man (attached)
COMMAND LINE:  groff -Tutf8 -man groff_char-box.man > groff_char-box.utf8
               (groff_char-box.man and groff_char-box.utf8 are attached)

DESCRIPTION OF INCORRECT BEHAVIOUR:

Many UCS codepoints fail to display.

A general trend is that all codepoints ending (or containing?) A-F
completely fail to display.  Is the .C2 macro not handling hexadecimal
input correctly?  Does it only work if you use 0-9 rather than 0-F?

Additionally, some codepoints fail to display even though their numbers
are only using 0-9.

The complete list of codepoints failing is:

2500 2501 2502 2503 2504 2505 250a 250b 250c 250d 250e 250f 251a 251b
251c 251d 251e 251f 252a 252b 252c 252d 252e 252f 253a 253b 253c 253d
253e 253f 254a 254b 254c 254d 254e 254f 255a 255b 255c 255d 255e 255f
256a 256b 256c 256d 256e 256f 257a 257b 257c 257d 257e 257f 258a 258b
258c 258d 258e 258f 259a 259b 259c 259d 259e 259f 25a0 25a1 25a2 25a3
25a4 25a5 25a6 25a7 25a8 25a9 25aa 25ab 25ac 25ad 25ae 25af 25b0 25b1
25b2 25b3 25b4 25b5 25b6 25b7 25b8 25b9 25ba 25bb 25bc 25bd 25be 25bf
25c0 25c1 25c2 25c3 25c4 25c5 25c6 25c7 25c8 25c9 25ca 25cb 25cc 25cd
25ce 25cf 25d0 25d1 25d2 25d3 25d4 25d5 25d6 25d7 25d8 25d9 25da 25db
25dc 25dd 25de 25df 25e0 25e1 25e2 25e3 25e4 25e5 25e6 25e7 25e8 25e9
25ea 25eb 25ec 25ed 25ee 25ef 25f0 25f1 25f2 25f3 25f4 25f5 25f6 25f7
25f8 25f9 25fa 25fb 25fc 25fd 25fe 25ff

SUGGESTED FIX:

If I use the .C2 macro as used on other lines in groff_char, I would
expect groff to display the glyph.  The glyphs all display perfectly
well on my terminal, so I would expect groff to pass them through
correctly.  There may be two issues, firstly the fact that codepoints
containing/ending in A-F are not displayed at all; secondly that
others containing only 0-9 do not display for some ranges.

I'm afraid I'm not familiar with the new unicode support in groff, so
I don't have a good suggestion as to the cause.  Does every codepoint
need listing in the font description (I'm looking at font/devutf8/R*)
or can groff use wcwidth() for formatting decisions for missing glyphs?


I have also provided a patch to man/groff_char.man to add Unicode
box-drawing, block elements and geometric shapes to groff_char.  Please
feel free to apply it--I find it useful for myself (except for those
glyphs that don't display!).  I assigned all current and future
copyrights on my groff work to the FSF in 2003, so it's all OK from
that POV.

This is also recorded as Debian bug #541688
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541688


Regards,
Roger


[1] https://lists.gnu.org/archive/html/bug-groff/2009-09/msg00004.html

G. Branden Robinson <gbranden>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (original reporter)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-06-16 gbranden Planned Release1.23.0 None
    2022-04-12 gbranden StatusNone Rejected
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2022-04-11 gbranden Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code