[comp.os.vms] DSR RUNOFF bug?

J_CERNY@UNHH.BITNET (10/26/87)

[I've tried sending this before and it never seemed to appear on
INFO-VAX, so I'm giving it another try.]

I'm wondering if anyone can shed any light on what seems to be
the following bug in Digital Standard RUNOFF.  (We are running
VMS 4.5 on an 8650.)
When I use the table of contents (toc) feature and index feature of
RUNOFF, it generates a reasonably nice looking toc and index, BUT most
of the page numbers are wrong.  Over the length of a 50-page
document the numbers gradually (but not in any noticible pattern) increase
so that they are off by 4 (too many).  It is hard to believe that this
is a bug in such a mature product and that if it is a bug that it
could remain unknown for very long.
I've pondered the situation at considerable length, but can see nothing
to do as an alternative.  By way of more detail, I generate the lines
to enter in the toc by .header commands, treating them as an .if/.endif
conditional since I do not really want these headers in the final
document.  The index entries are just generated with .x and .y commands.
I run RUNOFF in four passes: (1) to generate a .BRN file, (2) to
generate a .RNT file (I also use a /REQUIRE qualifier to add a couple
of lines), (3) to generate a .RNX file (again, a /REQUIRE qualifier to
add a couple of lines), and (4) a final pass in which the conditional
settings ignore the previous .header commands, but do turn on .require
commands for the .rnt and .rnx files.
The only two other users at this site whom I can find who have tried
to use these features in long (30-55 pages) documents tell me they have
had the same problem (earlier, 4.x releases of VMS) ... we have all
given up in the end and munged the page numbers by hand in the final
version.  Argh!

        Jim Cerny
        University Computing, Univ. N.H.
        J_CERNY@UNHH.BITNET

miw@uqcspe.OZ (Mark Williams) (11/05/87)

In article <8710262017.AA09044@ucbvax.Berkeley.EDU> J_CERNY@UNHH.BITNET writes:
>RUNOFF generates a reasonably nice looking toc and index, BUT most
>of the page numbers are wrong.  Over the length of a 50-page
>document the numbers gradually (but not in any noticible pattern) increase
>so that they are off by 4 (too many).
....
> By way of more detail, I generate the lines
>to enter in the toc by .header commands, treating them as an .if/.endif
....
>(4) a final pass in which the conditional
>settings ignore the previous .header commands, 

Well, what is happening is that the table of contents is generated on the 
assumption that the headers are to be allowed space, but the actual document
is generated without the headers, and hence no space allowed for them. If
you have a lot of .header commands, this could easily add up to 4 pages or so.

Mark Williams
ARPA: ccwilliams%wombat.decnet.oz@uunet.uu.net


-- 
The views expressed above are not necessarily those of my employer. In a
couple of hours they may not even be my own.

Small boys throw stones in fun, but the frogs die in ernest. -- Mark Twain.