On Sat, Oct 26, 2013, James K. Lowden wrote:
> My basic approach is
>
> .mk
> .TS
> ... table 1 ...
> .TE
> .rt
> .DS 3i
> .TS
> ... table 2 ...
> .TE
>
> If the table is too long for the current page, and lands on the next
> one, that doesn't work well at all, so I have
>
> .KS
> .mk
> .TS
> ... table 1 ...
> .TE
> .KE
> .rt
> .DS 3i
> .TS
> ... table 2 ...
> .TE
>
> In both cases, though, the second table isn't quite lined up with the
> fisrt. I use .sp to move it down, sometimes by 5p, sometimes by 5
> lines, depending on whether or not a keep was needed.
>
> I'm obviously doing something wrong, because 1) the second table doesn'
> line up, and 2) the way it doesn't line up varies, and 3) the keep
> behavior varies according to where the table falls.
I've just spent a couple of weeks delving into tbl, so I sympathize.
The root of the problem is twofold:
- tbl creates it own diversion, '3table'
- tbl code is processed before everything else, so registers like
'nl', 'dn', '.d' and '.h', or the internal register that stores
positions marked with '.mk', are meaningless, as are absolute
spacing requests (ie '.sp |n')
In addition, if tbl has the 'box' flag, the box exceeds the table
dimensions, and if your table has the 'allbox' flag (or uses '_' to draw
rules between table rows), the leading between the rows is greater
than the leading currently in effect.
The combination of these factors makes tables very tricky to
position when wrapped in .KS/.KE, and impossible to deal with if you
use '.TS H' with a boxed table (from tbl(1): "Do not enclose a
multi-page table within keep/release macros, or divert it in
any other way.")
I'm not an ms guru, so I can't offer specific suggestions to help. I
can, however, confirm that the version of mom I'll be committing
shortly (hopefully by the end of next week), has resolved most of
the issues, and that a mommified version of your example, whether in
a FLOAT (mom's version of .KS/.KE) or not, produces properly aligned
side-by-side tables. Which is to say, there is a solution to your
problem; hopefully, someone with more ms experience will see it.
--
Peter Schaffter
http://www.schaffter.ca
