bug using doublebox in tbl with ditroff

[Douglas Woodall]

naftoli at aecom.UUCP (Robert N. Berlinger) writes:

 > Does anybody know of a bug in ditroff which causes the box
 > produced by the doublebox option of tbl not to line up properly?
 > The boxes don't quite come into agreement at the edges.

I assume from this that "box" works correctly but "doublebox" doesn't.
You will certainly get this problem if the rounding caused by
the resolution of your output device is such that two successive
motions of 1p do not give the same result as a single motion of 2p.
(The output from "tbl" contains things like

.if \n(#a>=0 \h'|0'\h'-1p'\v'1p'\s\n(33\h'-\n(#~u'\
\L'|\n(#au-1v-2p'\s0\v'\n(\*(#du-\n(#au+1v+1p'\
\h'2p'\v'-1p'\s\n(33\h'-\n(#~u'\
\L'|\n(#au-1v+2p'\s0\v'\n(\*(#du-\n(#au+1v-1p'\h'|\n(TWu'

and you will have problems later if this lot leaves you in the
wrong place because of rounding errors.)  Assuming that the
resolution of the device is immutable, the problem can only be
solved by changing "tbl".  My solution was to add two new flags,
-h and -v, to specify the distance to be used between the rules.
These are set by the user (or, preferably, by a table-driven
command program) so as to give no rounding errors on the output
device in question.  On the Diablo Hyterm, for example,
		tbl -h1.2p -v1.5p
produces very nice double-boxed tables.  (In the output, things of
the form "1p" and "+2p" turn into things of the form "1u*1.2p" and
"+(2u*1.5p)".  The changes are mainly in tu.c and tv.c.)