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

[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
graphics one.

ECMA-48 says for 0x84:
8.3.132 SPI - SPACING INCREMENT

Hm.

If you want to know why I ignore preconv, read the last mail.)



On Thu, 28 Dec 2023 17:43:12 +0000
Lennart Jablonka <humm@ljabl.com> wrote:

> Quoth holger.herrlich@posteo.de:  
> >echo ä | gpic | hexStream
> >0x2e 0x69 0x66 0x20 0x21 0x64 0x50 0x53  | .if !dPS
> >0x20 0x2e 0x64 0x73 0x20 0x50 0x53 0x0a  |  .ds PS.
> >0x2e 0x69 0x66 0x20 0x21 0x64 0x50 0x45  | .if !dPE
> >0x20 0x2e 0x64 0x73 0x20 0x50 0x45 0x0a  |  .ds PE.
> >0x2e 0x6c 0x66 0x20 0x31 0x20 0x2d 0x0a  | .lf 1 -.
> >0xc3 0xa4 0x0a                           | ...
> >
> >echo Ä | gpic | hexStream
> >gpic:<standard input>:1: invalid input character code 132
> >0x2e 0x69 0x66 0x20 0x21 0x64 0x50 0x53  | .if !dPS
> >0x20 0x2e 0x64 0x73 0x20 0x50 0x53 0x0a  |  .ds PS.
> >0x2e 0x69 0x66 0x20 0x21 0x64 0x50 0x45  | .if !dPE
> >0x20 0x2e 0x64 0x73 0x20 0x50 0x45 0x0a  |  .ds PE.
> >0x2e 0x6c 0x66 0x20 0x31 0x20 0x2d 0x0a  | .lf 1 -.
> >0xc3 0x0a                                | ..
> >
> >The character emerges from a input file name. So it is missed by
> >preconv somewhere, however why is 'ä' working properly/ just passed
> >through?    
> 
> You don’t seem to be running preconv.  Are you?
> 
> gpic is reading from standard input the bytes a4 c3 (ä) or 
> 84 c3 (Ä).  It interprets those as Latin 1: a4 c3 is ¤ Ã.  
> 84 c3 is a control character followed by Ã.  The control 
> characters 80–9f are invalid.  



On Fri, 8 Dec 2023 18:48:50 -0600
g.branden.robinson@gmail.com wrote:

> [self-follow-up]
> 
> Some clarifications, to our Texinfo manual and to my own remarks...
> 
> At 2023-12-08T15:34:28-0600, G. Branden Robinson wrote:
> >      The '\c' in the above example needs explanation.  For
> > historical reasons (and for compatibility with AT&T 'troff'), the
> > end macro exits as soon as it causes a page break and no remaining
> > data is in the partially collected line.
> 
> Clearer would be:
> 
> "as soon as it causes a page break and no output line is pending."
> 
> >      To always force processing the whole end macro independently of
> >      this behaviour it is thus advisable to insert something that
> > starts an empty partially filled line ('\c') whenever there is a
> > chance that a page break can happen.
> 
> "An empty partially filled line" is somewhat baffling wording.
> Clearer would be:
> 
> "to ensure that an output line is pending, even if it has no visible
> content, whenever a page break might occur during end-of-input macro
> processing."
> 
> > I would prefer to just make `em` behave the way people expect, but
> > retain the weird old behavior for the benefit of historical
> > documents.
> 
> ...in AT&T compatibility mode ("groff -C") only.
> 
> Regards,
> Branden

pgp8I0bgydo79.pgp
Description: OpenPGP digital signature