naftoli@aecom.UUCP (Robert N. Berlinger) (07/12/85)
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'm
working with a QMS 800 and QUICroff software. I have contacted
QMS and they seem to think (and I agree at first glance) that
ditroff is probably at fault. Anyone who could give me a lead
would be greatly appreciated. Thanks...
--
Robert Berlinger
...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!naftolijaap@mcvax.UUCP (Jaap Akkerhuis) (07/15/85)
In article <1793@aecom.UUCP> naftoli@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'm > working with a QMS 800 and QUICroff software. I have contacted No, it has nothing to do with ditroff. Tbl does a lot of work trying to get the boxes to line up. It sets registers etc. to get things lined up properly. But, since tbl has been written originally for the C/A/T-4, all the adjustments are done for the characters on that machine and if the characters on your output device don't have the same characteristics as the one used on the C/A/T, the adjustments will fail. The effect is stronger when using double lines, (so using doublebox, || or =). > QMS and they seem to think (and I agree at first glance) that > ditroff is probably at fault. Anyone who could give me a lead > would be greatly appreciated. Thanks... You should dive into tbl (or kick QMS in doing in) and make the appropriate changes in tbl (or add a -T flag what I ended up doing). jaap (mcvax!jaap)
jeff@mcnc.UUCP (Jeffrey Copeland) (07/17/85)
Your problem with tbl and ditroff sounds more like the line drawing characters aren't tuned correctly. The four characters, em, rn, ul, and ru should all meet at their ends, so horizontal lines can be drawn. The vertical character br should meet the rn on the top and the ul on the bottom. ul should run under the baseline; ru at the baseline. If the characters are tuned properly, the "smallest possible constructed box", \(br\z\(rn\(ul\(br (see Troff User's Man, sect 12.2) will have corners that match.
drw%computer-science.nottingham.ac.uk@ucl-cs.ar (Douglas Woodall) (08/01/85)
naftoli@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.)