Subject: A question about the standard

From: gvacanti at estsa2.estec.esa.nl (Giuseppe Vacanti)
Date: 07 Nov 1997 12:00:55 +0100

Greetings.

I have a question about the FITS standard that I haven't been able to
address by reading NOST 100-1.1.

4.3.1 says that in the header of a primary HDU card imnages without
information shall be filled with ASCII blanks.

5.1.1 (syntax of card images) says that header (any header I suppose)
card images shall consist of key word (mandatory I suppose), optional
value, and optional comment.

Now my question is: is it legal to have (before the END key word) a
card image filled with blanks? 

I have this problem in the header of a binary table extension. Trying
to answer this question I noted that FTOOLS's fverify says the file is
ok, FTOOLS's fv cannot display the extension containing such cards
(but it doesn't complain), CFITSIO reports an error (202=key word does
not exist), FTOOLS's fdump will gladly show the header. 

So I'm getting mixed replies from the software. Would anybody care to
comment on this problem?

Thanks.

Giuseppe Vacanti

---

From: bschlesinger at ndadsb-f.gsfc.nasa.gov (Barry M. Schlesinger)
Date: 7 Nov 1997 15:02 EDT

In article <lh200t7yu0.fsf at sapc47.estec.esa.nl>, gvacanti at astro.estec.esa.nl (Giuseppe Vacanti) writes...
>card image filled with blanks? 

Yes.  5.2.2.4 (Commentary Keywords - Keyword Field is blank) addresses 
this question
     "Columns 9-80 may contain any ASCII text.  Any number of card
      images with blank keyword fields may appear in the header."
As is the case for the HISTORY and COMMENT keywords, a blank keyword 
field implies that the contents of columns 9-80 are to be treated as 
a comment.  The comment may be blank, and if the keyword field is also 
blank, the entire card is blank. 

> 
>... in the header of a binary table extension. 
>...  FTOOLS's fverify says the file is

This question should be answered by the FTOOLS team.

					Barry Schlesinger
					FITS Support Office
					GSFC/ADF

---

From: Clive Page <cgp at nospam.le.ac.uk>
Date: 10 Nov 1997 11:54:01 -0000

In article <lh200t7yu0.fsf at sapc47.estec.esa.nl>,
>address by reading NOST 100-1.1.
[snip]
>card image filled with blanks? 

My version of document NOST 100-1.1 "Definition of the Flexible Image
Transport System (FITS)" issued by GSFC says in section 5.2.2.4 entitled 
"Commentary Keywords", near the top of page 19:
 
"Keyword field is blank: Columns 1-8 contain ASCII blanks.  Columns
 9-80 contain any ASCII text.  Any number of card images with blank
 keywords may appear in a header"

So if columns 1-8 are blank, the rest of the card image may contain
anything, including all blanks, and is treated as a comment line.  This
seems clear enough to me.   Lots of our FITS data files contain blank lines
and fverify seems to think they are ok, and I have never had problems with
them (up to now).   But I'd welcome more authoritative comments...

-- 
-- 
Clive Page,
Dept of Physics & Astronomy,        
University of Leicester.

---

From: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Thu, 13 Nov 1997 16:46:29 -0500

> not exist), FTOOLS's fdump will gladly show the header. 

Clive Page sent me a FITS file with this problem and it turned out not
to be related to the blank keywords, but instead due to the following
TDISPn keywords:

TDISP3  = 'f8.4    '           / display format 
TDISP7  = 'i8      '           / display format 

The fv program requires that the Fortran display format be given only
in upper case (e.g., 'F8.4' and 'I8') as is implied by the definition
of the TDISPn keyword in the Binary Tables Extension FITS paper.

We plan to change fv to be more lenient and allow lowercase format
characters in the TDISPn keywords, but the question remains whether
this is really legal.  Fortran-90 (and Fortran-77) allow lowercase
format descriptors, but the Binary Table definition document
specifically lists only uppercase format characters.

What say other FITS experts on whether lowercase TDISPn values are
legal?

-Bill Pence
NASA/GSFC

p.s.  I was unable to reproduce the error=202 in CFITSIO, so I suspect
that it is unrelated to this TDISP issue.