Re: uppercase german umlaut

2024-01-02 Thread Dave Kemper
[moving this back to the thread where it belongs] On 1/2/24, hoh...@posteo.de wrote: > If gpic gets Ä (0xc3 0x84) it complains about 0x84. > If gpic gets ä (0xc3 0xa4) it does not complain about 0xa4. True, but irrelevant, because *in neither case will the character be interpreted the way you in

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

2024-01-02 Thread Lennart Jablonka
Quoth hoh...@posteo.de: 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 w

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

2024-01-02 Thread Lennart Jablonka
Quoth G. Branden Robinson: So because both being above ASCII (8 bit area), I'm going to stop you right there. ASCII is not an 8-bit code. It is a 7-bit code, per USAS (later ANSI) X3.4-1968 and ECMA-6. https://ia800800.us.archive.org/35/items/enf-ascii-1968-1970/Image070917151315.pdf https:/

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

2024-01-02 Thread Tadziu Hoffmann
> > So because both being above ASCII (8 bit area), > ASCII is not an 8-bit code. It is a 7-bit code, [...] Latin-1 is a superset of ASCII, with ASCII occupying the lower half, so technically I would argue that the above statement "being above ASCII" (namely, being in the area where the eighth