[Groff] Re: Disabling SGR in grotty(1): gory details

[Werner LEMBERG]

> > Reason for the failure is that the ms package plants a trap at
> > position zero to call cov*first-page-init; after executing the
> > .output request *before* loading the ms macros this trap isn't
> > called at the right time.
> > 
> So technically, this is the result of .output changing the \n[nl]
> register, right?

Yes, from -1 to 0, since the page has been started.

> > Because the error is based on a not-called macro, and not of an
> > internal failure of groff; since .output is called in the top
> > diversion, a new page is started automatically.
> > 
> Let me see if I got you right.  Not-called macro here being .br?

No.  address@hidden isn't called -- a trap is only called if the
previous position is *before* the trap's position.

> With the .output at the end of troffrc-end, I get:
> 
> $ troff -Tascii /dev/null
> x T ascii
> x res 240 24 40
> x init
> p1
> x X tty: sgr 0
> x trailer
> V2640
> x stop

And address@hidden has been successfully called since the trap
in ms has been planted while the current value of nl was still -1.

> $ troff -Tascii -ms /dev/null 2>&1
> x T ascii
> x res 240 24 40
> x init
> p1
> /usr/share/tmac/troffrc-end:21: fatal error: sorry, I didn't manage to begin 
> the first page in time: use an explicit .br request
> x trailer
> V2640
> x stop
> 
> Is the difference in the -ms case because .output is run while in a
> diversion?

No.

> I don't quite get it because in both cases I see the `p' command
> that is supposed to start a new page.

In this case the `p' doesn't have a meaning; it is output immediately
before the fatal error message.  The very problem is the vertical trap
at position 0.  As mentioned in the last mail, the first real output
(glyphs, .br, etc.) sets the horizontal and vertical position, but
.output doesn't do that.  Nevertheless, it causes the beginning of a
page which consequently means that nl is increased to 0 which in turn
triggers the execution of the trap at position zero.  But groff hasn't
yet set up its internal structures, so it aborts.

> Seems like what I need.  BUT...  You missed my point.  I get these
> spurious warnings when SGR output is on, i.e., with the stock
> troffrc and troffrc-end, yet I get them when I set the GROFF_NO_SGR
> in environment:

This is a completely different problem, not related to GROFF_NO_SGR at
all -- actually, it is a bug which I've fixed right now :-)

Anyway, the bug is really harmless and doesn't affect correct
operation.

> Without SGR disabling stuff in troffrc and troffrc-end, with
> the above example -ms chunk, I get:
> 
> $ troff -Tascii -ms x |head
> x T ascii
> x res 240 24 40
> x init
> p1
> DFd
> x font 3 B
> f3
> s10
> V400
> H648
> 
> $ troff -Tascii -ms x |grotty >/dev/null
> grotty:<standard input>:5: character above first line discarded
> 
> This is fatal for some -ms documents.  For example, the attached
> rcs.ms document loses its Abstract section.  The funny thing is
> that the SGR disabling stuff you proposed "fixes" this.  :-)

??? Not for me.  Both

  groff -pt -ms -Tascii rcs.ms > rcs.txt

and

  GROFF_NO_SGR=1 groff -pt -ms -Tascii rcs.ms > rcs.txt1

yield the expected result (with plain troffrc and troffrc-end).


    Werner