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
signature.asc
Description: PGP signature
