[comp.text] tbl problems

raj@ursa.UUCP (Raj) (08/25/87)

tbl has a bug.  It manifests itself when you have a long table, spanning
several pages, and there are numeric fields.  The first few pages of the
table were alright, but the later pages have the problem.  The problem is
that blank spaces in the table are replaced by the decimal part of the
row above!  I have tried all kinds of ways and means to get around it.  The
only possible way is to declare the column as alphanumeric rather than 
numeric.  That makes the periods not aligned, and the whole thing looks ugly.

Has anyone experienced similar problems?  Does anyone know any solutions?
I have talked to the guys at ELAN as well as SUN, but unfortunately, they
were not much help.  

Please reply to sun!sunrise!ursa!raj

kathy@wrcola.UUCP (K.M.Vincent) (08/27/87)

In article <289@future.ursa.UUCP> raj@ursa.UUCP (Raj) writes:
>tbl has a bug.  It manifests itself when you have a long table, spanning
>several pages, and there are numeric fields.  The first few pages of the
>table were alright, but the later pages have the problem.  The problem is
>that blank spaces in the table are replaced by the decimal part of the
>row above!  I have tried all kinds of ways and means to get around it.  The
>only possible way is to declare the column as alphanumeric rather than 
>numeric.  That makes the periods not aligned, and the whole thing looks ugly.


Assuming the operative word is "long." Maybe your problem is
distantly related to the fact that tbl only looks at the first
100-200 or so (sorry, I forget the exact number now, but it's
in the docs) lines of the raw file when it's working up the
format for the table.  

Have you tried breaking up your table into several smaller
ones?  Probably using the  ".TS H" capability provided by the
memorandum macros.  For all tables but the first one, use
the "N" in the ".TH" macro that you put in after your header
lines - so that, as each new table shows up, the header is
only output if the processor is at the TOP of a new page.

You'll have to specify column widths, tho, in each new
table, so that as you carry over from page to page
it all looks like one continuous table.  You may have some
problems if you're trying to box your table.

And don't forget to use -mm to format.  The carryover head
business is an -mm feature, not a tbl feature.


	.TS H
	<global options> ; 
	<column formats>.
	<header lines>
	.TH
	  .
	  .
	<table data>
	  .
	  .
	.TE
	.TS H
	<global options> ;    \" Same as globals for first table
	<column formats>.     \" Same as formats for first table
	<header lines>        \" Same as header lines for first table
	.TH N                 \" 'N' added to suppress output of 
	  .                   \"    header lines unless top of page
	  .
	<table data>
	  .
	  .
	.TE




Kathy Vincent -----> AT&T: {ihnp4|mtune|burl}!wrcola!kathy
              -----> Home: {ihnp4|mtune|ptsfa|codas}!bakerst!kathy

roy@phri.UUCP (Roy Smith) (08/27/87)

In article <289@future.ursa.UUCP> raj@ursa.UUCP (Raj) writes:
> tbl has a bug.  It manifests itself when you have a long table, spanning
> several pages, and there are numeric fields.

	Please folks, when reporting a bug or asking for help, try and give
us some useful information like what kind of system you are using and what
version of the software.  In this case, I just happen to have recognized
the company name and know they have Suns because our Sun service-slug once
mentioned that company as another account they have.  So, I'm guessing that
they are running SunOS3.2.

	Anyway, it's documented in the Sun 3.2 release notes that tbl is
broken, and the the bug manifests itself with "n" format column.  Our work
around was to just replace the distributed tbl binary with the old binary
from 3.0.  Presumably if you have tbl source from another 4.2 system you
could get it to work on Sun3.2.  Presumably this was fixed in 3.3 or 3.4.

	Now, for the $64k question -- why the hell did Sun take tbl, which
has been working fine for many years and break it?  I don't know about
other places, but that single bug alone would have been enough to make 3.2
totaly unusable for us if we couldn't get a working tbl binary.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

henry@utzoo.UUCP (Henry Spencer) (08/31/87)

> 	Now, for the $64k question -- why the hell did Sun take tbl, which
> has been working fine for many years and break it? ...

Continuing in the fine Berkeley tradition? :-) :-)

More seriously, they may have been trying to fix it and ended up shipping
an inadequately-tested version.  Tbl is full of the ugliest grot you've
ever seen, and misbehaves nastily under stress.  It could stand fixing.
-- 
"There's a lot more to do in space   |  Henry Spencer @ U of Toronto Zoology
than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry