colonel@sunybcs.UUCP (George Sicherman) (01/20/84)
This is a reposting of an article that got lost in the snarl. Our version (4.1BSD) of tbl produces spurious "delimiter" characters in the nroff lines for the fields themselves. Normally these are control-B's, with control-C's before the first field and after the last. This SEEMS to be a bug. If the fields themselves contain nroff-recognizable control characters, the delimiters may even be printable characters, which would certainly mess up a table. Even the non-printing delimiters undermine some features - try using the -me special characters in a troffed TBL table. Chaos! The obvious fix is, don't write the delimiters! But then why does tbl write them in the first place? If nobody supplies a good answer within a couple of weeks, I'm going to implement the fix and see what happens. Col. G. L. Sicherman ...seismo!rochester!rocksvax!sunybcs!colonel
phil%rice@sri-unix.UUCP (01/22/84)
From: William LeFebvre <phil@rice>
Those control Bs and control Cs are NOT delimeter characters. But
don't worry, that is what I thought they were, also. They are field
and padding characters. After tbl sets up a ton of number registes
that use those characters, it does a ".fc ^B ^C" which sets the field
delimeter to ^B and the padding indicator to ^C. The "Nroff/Troff
User's Manual" explains fields in section 9.2 (page 18). I am not
exactly sure how they work, be cause I only discovered their existence
a few days ago. Here is a section of the manual that describes their
use:
The field length is the distance on the input line from the
position where the field begins to the next tab stop. The
difference between the total length of all the sub-stings and
the field length is incorporated as horizontal padding space
that is divided among the indicated padding places.
Those control characters are not "spurious". They are used to position
strings inside the table segments. Take them out and your talbe won't
look very pretty. As for the me special characters not working inside
a table, I suspect that that is caused by "backslash confusion."
Backslashes don't work the same inside a keep as they do in straight
text. Try defining a string macro that overstrikes a slash and a
backslash that can be used both inside and outside a keep! It can be
done, but not obviously. The bottom line is that those control
characters should not interfere with anything. I would like to see a
case where they do!
William LeFebvre
ARPANet and CSNet: phil@rice
USENet: ...!lbl-csam!rice!philphil%rice@sri-unix.UUCP (01/22/84)
From: William LeFebvre <phil@rice>
Let me catch myself before everyone starts flaming me...
After defining a few macros, tbl sets up some number registers to help
determine the widest string for a field. At that point, it IS using a
control B as a delimiter. After the ".fc" statement, it uses control B
and control C as field and padding characters. Since the ^B is only
used as a delimiter for strings to "\w", the main thrust of the message
still applies. You have to use something for a delimiter. The only
time that [nt]roff will get confused is when there is a ^B in the
string in the "\w" and why would there be one there? For that matter,
why would there be a ^B anywhere in the normal text of the document?
William LeFebvre
ARPANet and CSNet: phil@rice
USENet: ...!lbl-csam!rice!phil