Re: [Groff] Tips & Tricks: Tables with abutting rules

[Ted Harding]

On 07-Jul-11 16:19:28, Ingo Schwarze wrote:
> Hi,
> 
> Werner LEMBERG wrote on Thu, Jul 07, 2011 at 02:01:04PM +0200:
>> Ted Harding wrote:
> 
>>> There is no 'tbl' option which allows a "no space" to be set in this
>>> context. However, there is a trick.  This is to use dummy columns at
>>> the left and/or right, with associated zero column spacings.  [...]
> 
>> Very nice!  Could you convert this small tutorial into something which
>> I can add to the tbl manpage?
> 
> Ugh.  This looks like an extremely ugly hack abusing tbl(1) in a way
> it was never meant to be used.
> 
> In general, you are better off in programming if you avoid using
> counter-intuitive quirks near the borders of languages (in this case,
> empty columns and mixing low-level roff with high-level tbl).
> In general, that kind of hackery will be hard to understand, of
> questionable portability at best, and will likely break with the
> next shift in implementation-defined behaviour.
> 
> Are you really sure that you want to *document* such stuff?
> I think it would be a saner approach to clearly advise against
> it instead of advertising it.
> 
> Yours,
>   Ingo
> -- 
> Ingo Schwarze <address@hidden>
> OpenBSD mandoc and groff maintainer

I have to disagree with this comment.

1: (trivially) The method I proposed, to be used within the
context of a table description (between ".TS" and ".TE"),
contains no "low-level roff" at all. There is part of my
posting which generates a result using "raw troff", but
that is put in as a reference object (where we can predict
from troff rules what will happen) with which to compare
the result of the 'tbl' code. This does not occur between
".TS" and ".TE" and so is not part of the suggested method.

2: 'tbl' can be used in any way which is consistent with its
design and functionality, to achieve (if possible) a desired
result. That is surely how it was "meant to be used". That
is what was being done there.

3: The capability to have zero spacing between a bordering
vertical rule and the adjacent column is not provided for
explicitly by 'tbl' as an option. However, there are some
circumstances where that is exactly what one may want to do.
The method I described does just that, using nothing that
is not present by design in 'tbl'. I therefore do not accept
that this is "abusing tbl(1) in a way it was never meant to
be used."

4: I agree that it is a "hack" in a somewhat broad sense
of that word; in my view it is not an "ugly hack", though
it is a bit cumbersome perhaps. Here the somewhat broad
sense of "hack" includes "Tips & Tricks" as in the Subject
of my posting -- a legitimate usage of the resources of
a program to achieve an effect that users might not readily
think of, but which is available if they do think of using
that "Trick". It does involve an extension [by one invisible
zero-width column on either side ... :)] of how a routine
user would normally think of a table (i.e. a series of columns
each of which contains content that the user wishes to present).

It does this by adjoining invisible zero-content (therefore
zero-width) "virtual" columns with separation 0 from the
adjacent "real" columns, thereby ensuring that the vertical
rule (now no longer bordering the table as seen by 'tbl')
has zero separation from its adjacent "real" column.

The result is that the user sees what he wanted to see, and
the invisible "virtual" columns are not there at all in the
resulting output.

5: I do not accept that this is "hard to understand". It is
perfectly straightforward!

6: As to whether it is "portable" -- I think it is probably
portable to all versions of 'tbl' and troff, whether GNU
or not. However, I am not expert on variants of 'tbl' which
may be implemented in non-GNU versions of roff, so cannot
be absolutely certain. However, the method is so close to
the very basic elements of how 'tbl' is designed that I
would expect it to have worked when troff first came out
in the early 1970s!

7: Unless something very fundamental changes in groff's
functionality, the method should cntinue to work as desacribed
in all future versions of groff. I cannot agree that it "will
likely break with the next shift in implementation-defined
behaviour."

With best wishes,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 07-Jul-11                                       Time: 18:52:40
------------------------------ XFMail ------------------------------