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

[Ruslan Ermilov]

On Thu, Oct 24, 2002 at 05:53:26PM +0200, Werner LEMBERG wrote:
> > > 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.
> 
OK.

> > 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.
> 
OK.

> > $ 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.
> 
OK, got it.

> > 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 :-)
> 
Thanks, I don't get these spurious warnings with the latest node.cc
anymore.

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

> > 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).
> 
Yes, as it turns out, you can only see the difference if you run
groff with -o1-, the way roff documents are formatted in FreeBSD.
With the stock troffrc and troffrc-end this causes no ABSTRACT
in this document.  After a bit of thinking, -o1- *should* cause
this document to skip the ABSTRACT, but it isn't with this SGR
disabling stuff in troffrc:

.\" Disable SGR support in grotty(1).
.if n \{\
.  do nop \X'tty: sgr 0'
.  sp -1
.  nr nl 0-1
.  nr % -1
.\}

I tried playing with \n[%] for a while, to no avail.  Can this
version be fixed somehow so that -o1- works again?  (Hope I'm
not asking for too much.)


Cheers,
-- 
Ruslan Ermilov          Sysadmin and DBA,
address@hidden          Sunbay Software AG,
address@hidden          FreeBSD committer,
+380.652.512.251        Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age