[bug #65109] [troff] no diagnostic in nroff mode when composite character unavailable

[G. Branden Robinson]

Follow-up Comment #1, bug#65109 (group groff):

The following commit does not resolve the problem, but is adjacent to it, and
helps distinguish problems with composite characters that are independent of
the selected output device from those that arise because a device doesn't have
support for a (composite) glyph.


commit 6008b6b7aa2920035e09d1dea44d262d30391195
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jan 18 12:45:57 2024 -0600

    [troff]: Diagnose bogus composite char escapes.
    
    [troff]: Diagnose bogus composite character escape sequences.  That is,
    when a composite character escape sequence like \[a ~] has a bogus
    modifier (as opposed to base) character, meaning one that has not been
    defined as the source _or_ destination of a `composite` request, warn
    about it.  For instance, \[a $] is nonsense, barring a request like
    `.composite $ \[uFF00]`, which would map `$`, when used as a modifier
    character in a composite special character escape sequence, to U+FF00,
    which would be a modifier form of the dollar sign in an alternate
    universe.
    
    * src/roff/troff/input.cpp (is_codepoint_composite): New function
      searches `composite_dictionary` for the presence of the given
      four-digit hexadecimal string as a key _or_ value.
    
    * src/roff/troff/input.h: Expose foregoing function to other translation
      units.
    
    * src/roff/troff/node.cpp (make_glyph_node): Check input `charinfo` for
      a Unicode code point sequence, and if it contains one, call
      `valid_unicode_code_sequence()` to check it for validity.  Then,
      iterate through each code point after the first {the base character},
      and call `is_codepoint_composite()` on it.  Diagnose invalid composite
      character and return null pointer if validation fails.
    
    Input:
    .nf
    \[A a~]
    \[A ~]
    \[u0041_0301]
    \[u0041_007E] \" should fail because 007E is explicitly spacing
    \[u0041_0041] \" same reason, more obviously
    \[u0041_0301_0301] \" should fail, would have a different meaning
    \[u0041_007E_0301] \" both problems above
    
    groff 1.23.0 and earlier:
    $ groff -T ps -z EXPERIMENTS/composite_character_construction.groff
    troff:...:5: warning: special character 'u0041_007E' not defined
    troff:...:6: warning: special character 'u0041_0041' not defined
    troff:...:7: warning: special character 'u0041_0301_0301' not defined
    troff:...:8: warning: special character 'u0041_007E_0301' not defined
    $ groff -Tutf8 -z EXPERIMENTS/composite_character_construction.groff
    [no output due to Savannah #65109]
    
    Now:
    $ ./build/test-groff -T ps -z
EXPERIMENTS/composite_character_construction.groff
    troff:...:5: warning: special character 'u0041_007E' not defined
    troff:...:6: error: cannot format glyph: 'u0041_0041' is not a valid
composite character
    troff:...:7: warning: special character 'u0041_0301_0301' not defined
    troff:...:8: warning: special character 'u0041_007E_0301' not defined
    $ ./build/test-groff -T utf8 -z
EXPERIMENTS/composite_character_construction.groff
    troff:...:6: error: cannot format glyph: 'u0041_0041' is not a valid
composite character




    _______________________________________________________

Reply to this item at:

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

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