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 <schwa...@usta.de> > 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) <ted.hard...@wlandres.net> Fax-to-email: +44 (0)870 094 0861 Date: 07-Jul-11 Time: 18:52:40 ------------------------------ XFMail ------------------------------
