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
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
> > 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
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
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
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
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
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
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 'troff'),
> > > the end macro exits as soon as it causes a page break and
> > > no remaining data is in the
Hi Doug,
At 2023-12-09T09:26:16-0500, Douglas McIlroy wrote:
> > For historical reasons (and for compatibility with AT '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
> For historical reasons (and for compatibility with AT '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 the end of a
document. Since day one, troff has occasionally emitted
a
[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 'troff'), the end macro
> exits
On Fri, Dec 08, 2023, G. Branden Robinson wrote:
> I propose that GNU troff stop behaving like AT 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
Hi folks,
I have a *roff language reform to suggest.
I propose that GNU troff stop behaving like AT troff in one aspect of
end-of-input macro processing, documented in our Texinfo manual.
-- Request: .em macro
Set a trap at the end of input. MACRO is executed after the last
line of
17 matches
Mail list logo
