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

[G. Branden Robinson]

Update of bug #62296 (project groff):

                  Status:                    None => Wont Fix               
             Open/Closed:                    Open => Closed                 
         Planned Release:                    None => 1.23.0                 

    _______________________________________________________

Follow-up 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
<https://lists.gnu.org/archive/html/bug-groff/2009-09/txtK_u1liDhGR.txt> 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.
]]


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62296>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/