Hi Branden,
Yes, I noticed the gaffe and then sent a proper PDF file.
tbl is quite strict in the type of input it accepts. I, too, tried to
use phantom characters of a bigger height to adjust the vertical
spacing, but so far did not succeed in an *exact* reproduction of
Bento's example.
On the other hand, given that he made the table with a Windows tool, it
may be possible that he himself is not satisfied with the first result.
I tried to make the code for my proposed solution as simple as possible.
In table definitions (e.g. row patterns), not even \" style comments are
allowed, tbl complains about "invalid column classifier '\'".
This reminds me that it is really time to finish my tbl primer. Last
year was totally blocked by two major publications (one of which uses
tbl extensively, in total more than 1,300 tables!), and only now I find
the time and the ease of mind to finish what has been way too long on my
list.
Best,
Oliver.
On 08/05/2025 11:38, G. Branden Robinson wrote:
Hi Oliver,
At 2025-05-08T10:44:58+0200, Oliver Corff via GNU roff typesetting system
discussion wrote:
you have to decide whether the following approach is a fair enough
approximation to your formatting needs.
The following command line was used:
$ groff -ms -t -k BBS_Example.ms > BBS.pdf
You generated (and attached) a PostScript file, not a PDF. I got
warnings when trying to open it with a PDF viewer.
I, too, tried to solve Bento's challenge, and so far have not come up
with a solution that satisfies me.
I tried a few tricks, all of which failed.
1. The 'V' column modifier applies only to text blocks. In my opinion,
Bento's scenario should be solvable without the use of text blocks;
none of his table cells have lengthy data or require breaks.
2. I tried using \H'20z' to set the font height to "double high", then
rendering a dummy character with it. tbl was not fooled and did not
update its idea of the row height. It also was not fooled by
formatting a double-height letter 'A' similarly, which caused the
letter to overprint the box lines and makes me wonder if that's a
bug. I furthermore notice that we don't have a syntax for restoring
a font's "previous" or "nominal" height, which is a missing point of
parity between the `\H` escape sequence and the similar `\S` one,
which applies a "slant" to a typeface. (`\S'0'` restores the font's
nominal slant.)
I'd like to return to those issues at some point, but decided for
the time being that this sort of solution was a hack.
3. I then remembered the `\x` escape sequence, which seems precisely
fit for purpose.
groff(7):
\x'N' Increase vertical spacing of pending output line by N vees
(or specified units; negative before, positive after).
It seems to be completely ignored.
It looks to me like GNU tbl is not perceiving alterations to the height
of the pending output line when they are caused by table data, _except_
when diverting table cell contents for a text block.
The `.a` register, dating back to Ossanna troff (it's in the 1976
version of CSTR #54) but seldom used, would seem to be relevant...
\n[.a] Amount of extra post‐vertical line space; see \x.
...but GNU tbl never consults this register.
Maybe it should. I've put experiments with DWB 3.3 tbl and Heirloom
Doctools tbl on my to-do list. It'd be nice to solve this problem, and
even nicer to claim bragging rights if ours is the only tbl that does.
A potential problem is that the `.a` register is defined to report only
the amount of extra post-vertical line space applied to the _previous_
output line. I suspect because it is only once the line has been
formatted and output that one knows for sure what the value is. But GNU
troff has other extension registers that disclose parameters of the
pending output line.
\n[.in] Indentation amount applicable to the output line
pending in the environment; see .ti.
\n[.ll] Line length applicable to the environment’s pending
output line.
...so it might not be crazy to add extension registers permitting access
to the pending line's maximum extra pre-vertical and post-vertical
spacings. Maybe call them `.xa` ("after") and `.xb` ("before").
GNU troff stuffs these additional spacings into the pending output line
by means of what's known internally as `extra_size_node` objects, but as
usual I'm of a mind to rename that data type for clarity, maybe to
`extra_vertical_space_node`.
Regards,
Branden
--
Dr. Oliver Corff
Wittelsbacherstr. 5A
10707 Berlin
G E R M A N Y
Tel.: +49-30-85727260
Mail:oliver.co...@email.de
