Subject: Rewriting NAXIS2

From: SWEETLAND at rsdps.gsfc.nasa.gov
Date: Fri, 29 Oct 1993 14:07:44 -0400 (EDT)

Nothin' to it, guy!

After the:

ftcrhd
ftphtb
ftmcom (optional)
ftadef
ftpcls (probably)
 
you can then: FTMKYJ(unit,'NAXIS2',new_naxis2_value,'&',status)
(new_naxis2_value is I*4, the '&' says don't change the comment field)

Then you FTDDEF(unit,bytlen,status)
(to redefine the size of the extension. bytlen is the count of your
records going into your file times the byte length of the records,
obviously mush easier when they are fixed-length).

BTW, the FTMKYJ and FTDDEF are calls, of course.\

And, when all is said and done, you call FTCLOS (trusting that you
have done an FTINIT to open the sucker, of course, and that's all
there is to it.

--Sallyo

---

From: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Fri, 29 Oct 93 15:04:37 EDT

[Sorry, my previous message on this subject mysteriously posted itself
before I had completed it!   Also "Sallyo"  gave basicaly the same
answer to the original question.]

There is one thing to watch out for when creating ASCII FITS tables
with FITSIO that initially have an unknown number of rows.  The FITS
Standard requires that any fill bytes at the end of an ASCII table be
set equal to ASCII Spaces, not NULs as is done in all other types of
extensions.  FITSIO does this in the ftadef subroutine, so obviously if
the correct number of rows are not passed to the subroutine, then it
will not correctly initialize the table.  In practice this does not
matter as long as

  a)  the writing program explicitly writes a value to every element of
      the table.  Otherwise, any unwritten table cell will contain
      ASCII NUL values, which are illegal

  b) there are no gaps between the defined columns of the table.  Sometimes
     the ASCII table columns are defined such that there are one or more
     spaces between each data column, to improve human readibility.  If this
     this case, then these gaps bytes could end up uninitialized and have 
     an illegal ASCII NUL value.

There still remains a technical problem in that the fill bytes after the
last row in the table may not be set to ASCII Spaces, but FITS readers have
no reason to ever read these fill bytes, so this makes no difference
in practice (but it is still technically illegal!).

If this is a problem, it is possible for the FITS writing program to explicitly
set all the fill bytes to ASCII Spaces using the ftptbs subroutine, but
it is a little tedious figuring out how many fill bytes need to be written.
I may be able to find a workaround to this problem and put a fix in
future releases of FITSIO, but no guarantees.

Note that this is not a problem with Binary FITS tables, since
they are padded with ASCII NULs which happens by default in FITSIO.

-Bill Pence