Re: [groff] page location traps

2018-10-25 Thread Tadziu Hoffmann
> [...] and groff's devascii: I was (partly) wrong about the devascii behavior. In the example I had shown, some newer traps actually *replace* older traps due to the limited vertical resolution (because the position rounded to the nearest vertical resolution unit is the same as that of a simi

Re: [groff] page location traps

2018-10-25 Thread Tadziu Hoffmann
> However, the nroff stderr output is unaccountably different: > groff's implementation triggers traps 2, 4, 5, and 6, > while Heirloom's triggers 1, 3, 4, and 6. I just tried this with (a ported version of) Plan 9 troff, and get the following: vertical resolution is 720/in / 1 trap 1 sprung

Re: [groff] page location traps

2018-10-25 Thread Dave Kemper
On 10/24/18, Peter Schaffter wrote: > Where is the generic end-of-page trap in relation to the last output > line of the page? In one instance, the end-of-page trap sits at position 527981u.* On the last line, .tm reports the value of \n(nl to be 523346u.** So my code places the new trap at 523

Re: [groff] page location traps

2018-10-24 Thread Peter Schaffter
Dave -- On Wed, Oct 24, 2018, Dave Kemper wrote: > To elaborate on point (3): I encountered this while trying to place a > trap that gets triggered at the end of the current output line (that > is, the next time the output's vertical position is advanced). I did > this by placing the trap a singl

Re: [groff] page location traps

2018-10-24 Thread Werner LEMBERG
> Since this behavior is (1) undocumented, (2) inconsistent across > historic roffs, and (3) arguably undesirable, is it accurate to call > it a bug and open a bug report on it? It's certainly worth to open a report so that the behaviour can either be fixed or accurately documented (whatever is

Re: [groff] page location traps

2018-10-24 Thread Dave Kemper
On 6/16/18, Ralph Corderoy wrote: >> Werner wrote: >> > In other words, while your first trap is active, it moves down one >> > line, which passes some traps without triggering them. >> >> That bit of information is missing from the manual > > And from CSTR 54. Werner, are you sure about that? I

Re: [groff] page location traps

2018-06-18 Thread Dave Kemper
Hi Ralph, On 6/16/18, Ralph Corderoy wrote: > It's odd that for `ps' it's the first trap to a rounded position that > springs, but for `ascii' it's the second. True, but it's odd that there should be rounding in the ps device at all, given that the device has a much finer granularity than 1/10 o