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 <h...@ljabl.com> wrote:
> Quoth holger.herrl...@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.robin...@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
pgpfLMrklFkmI.pgp
Description: OpenPGP digital signature
