gpic and 8-bit characters (was: Proposed GNU troff behavior change: require end-of-input macros to exit)

2024-01-01 Thread G. Branden Robinson
For one thing, this sub-thread needs to be retitled. Doing so. At 2024-01-02T07:15:53+, hoh...@posteo.de wrote: > If gpic gets Ä (0xc3 0x84) it complains about 0x84. > If gpic gets ä (0xc3 0xa4) it does not complain about 0xa4. > > gpic says: "invalid input character". > > So because both b

Re: Proposed GNU troff behavior change: require end-of-input macros to exit

2024-01-01 Thread hohe72
If gpic gets Ä (0xc3 0x84) it complains about 0x84. If gpic gets ä (0xc3 0xa4) it does not complain about 0xa4. gpic says: "invalid input character". So because both being above ASCII (8 bit area), what makes 0x84 wrong? It seems that 0x84 is located in a control area whereas 0xa4 in an graphic

cu underlines as escape sequence?

2024-01-01 Thread aackmann
Is it possible to get the .cu underlines with something like \fI? Essentially I am looking for an escape sequence (user defined possible?) that would generate a .cu style underline that doesn't break on spaces.