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
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
At 2023-12-17T21:13:27+, Deri wrote:
> Add .fl after Hello. :-)
A quick experiment reveals that `br` has the same effect, which means
that a different documentary statement of mine is wrong:
--snip--
What if the file ends before enough words have been collected to fill
an output line? Or
At 2023-12-17T21:13:27+, Deri wrote:
> > I challenge you to explain! :D
>
> Add .fl after Hello. :-)
That's not an explanation! Just more magic! :-O
Anyone want to spare me some time in GDB? >cringe<
Regards,
Branden
signature.asc
Description: PGP signature
On Sunday, 17 December 2023 20:53:52 GMT G. Branden Robinson wrote:
> Hi Deri,
>
> At 2023-12-10T18:43:42+, Deri wrote:
> > On Saturday, 9 December 2023 19:25:27 GMT G. Branden Robinson wrote:
> > > When a line of output is "finished" and sent to the device
> > > (device-independent output is
Hi Deri,
At 2023-12-10T18:43:42+, Deri wrote:
> On Saturday, 9 December 2023 19:25:27 GMT G. Branden Robinson wrote:
> > When a line of output is "finished" and sent to the device
> > (device-independent output is prepared for it), the vertical
> > position advances by one vee, and, (in groff,
Hi Holger,
At 2023-12-11T19:35:42+0100, Holger Herrlich wrote:
> As far as I got, by playing around, the '\c' doesn't matter.
I think it does; I think it was Werner who put the cautionary language
(which I quoted) in our Texinfo manual about this, and this seemed to be
squarely on point when I fi
As far as I got, by playing around, the '\c' doesn't matter. It seems
that the additional page comes from an additional call to the
default page break.
Using a custom trap, just disable it in your end trap:
8<
.\"
.\" run: groff em-test.groff > em-test.ps
.\"
.nr PAGE-trap 20c
.nr PAG
On Saturday, 9 December 2023 19:25:27 GMT G. Branden Robinson wrote:
> At 2023-12-09T09:26:16-0500, Douglas McIlroy wrote:
> > > 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 partia
Hi Doug,
At 2023-12-09T09:26:16-0500, Douglas McIlroy wrote:
> > 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.
>
> This isn't the only anomalous behavior at
[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
On Fri, Dec 08, 2023, G. Branden Robinson wrote:
> I propose that GNU troff stop behaving like AT&T troff in one aspect of
> end-of-input macro processing, documented in our Texinfo manual.
I'm all for it, for all the reasons given.
--
Peter Schaffter
https://www.schaffter.ca
12 matches
Mail list logo
