Follow-up Comment #8, bug #67380 (group groff): [comment #7 comment #7:] > [comment #6 comment #6:] >> *roffs flush output lines (to the top-level diversion) >> as they go (that is, as they are "completed" and broken), > > This is where groff behavior diverges from its forebears. A break seems > sufficient to flush in groff, but not in DWB or Heirloom troffs, going by the > results in bug #56500 comment 4. Perhaps those implementations wait until > some buffer fills up.
Yeah, so I have to retract my generalized claim about *roffs.
They don't flush as they go.
Heirloom Doctools doesn't, DWB doesn't, Plan 9 from User Space doesn't,
Solaris 10 doesn't, Seventh Edition Unix doesn't.
I now share your hypothesis about a buffer.
>> and no known *roffs give `ab` any responsibilities
>> regarding any pending output line.
>
> That seems to be true. But I don't use .ab in real life; I'm merely going by
> the examples posted so far.
>
> Also, at least Plan 9 and neatroff would need to be tested before speaking of
> all known roffs. But I don't think we need to document anything beyond how
> groff works, and how it differs from AT&T troff.
I think we know enough to establish that, and to return to the topic of the
ticket. If you're using `ab` to troubleshoot a document *with _groff_*, break
the line (by any means) first.
[Another set of experiments later...]
This appears to be what `fl` is for!
$ DWBHOME=. ./bin/troff
Foobar
.br
'fl
x T post
x res 720 1 1
x init
V0
p1
x font 1 R
x font 2 I
x font 3 B
x font 4 BI
x font 5 CW
x font 6 H
x font 7 HI
x font 8 HB
x font 9 S1
x font 10 S
s10
f1
H720
V120
cF
56o50o50b50a44rn120 0
H1003
s10
f1
V120
<Control+D>
x trailer
V7920
x stop
I get analogous results with Heirloom Doctools, Solaris 10, Plan 9 from User
Space, and V7 Unix _troff_s.
An interesting difference is that a document consisting solely of `'fl`
produces the device-independent output "header" (and moves the drawing
position to the origin), whereas GNU _troff_ produces nothing. (By contrast,
in GNU _troff_ you can get that header from a document containing only `\c`.
That doesn't work with AT&T _troff_, presumably because that doesn't suffice
to fill this inferred "buffer".)
(Seventh Edition spits out a few bytes of noise that, I suppose, initialize
the C/A/T, but otherwise works like later AT&T device-independent _troff_s.)
I'm getting to a point where I think I can say intelligent things about `fl`
in our manual. That's good.
Also, we could change "`fl" to go ahead and write the document preamble. It
might be more intuitive than letting `\c` serve as the sole means of achieving
that (with no other input), without the side effect of starting a pending
output line.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67380>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
