[fitsbits] Blank strings in FITS keywords.

[Thomas McGlynn]

Peter Bunclark wrote:

> Tom McGlynn wrote:
> 
>> Here's a little FITS lawyer nit.
>>
>> Section 5.2.1 of the FITS standards document
>> notes that
>>
>>   KEYWORD1= ''
>>
>> is distinct from
>>
>>   KEYWORD1= ' '
>>
>> However I am unclear as to whether either of these are
>> distinct from
>>
>>   KEYWORD1= '        '
>>
>> (where there are at least 8 blanks between the quotes).
>>
>> The first two examples clearly use the free format for
>> the headers, but the third example could be in the fixed format.
>> Since a fixed format line cannot have fewer than 8 characters
>> in a character string header value, a sequence of 8 blanks is the only
>> way to specify these strings in the format that that standard
>> recommends people use.
>>
>> Since one is allowed to intermix free and fixed format
>> cards in the header there is no context that can tell you which format 
>> the
>> card is in.
>>
>> So it looks like
>>
>>   Example 1 EQV example 3
>>   Example 2 EQV example 3
>> but
>>   Example 1 NOT EQV example 2.
>>
>> Is this true?    If so I think this may be the only example
>> where this is the case and seems a little inelegant to me. Probably 
>> too late to change
>> but it might have been better to have the first two examples
>> equivalent too.
>>
>> Not a big issue, but it actually has come up in practice!
>>        Regards,
>>     Tom McGlynn
> 
> 
> Trailing blanks are not significant:
> KEYWORD1= ''         / null string
> KEYWORD1= ' '        / value is a single blank
> KEYWORD1= '       '  / value is a single blank
> KEYWORD1= '                                        ' /value is a single 
> blank
> 
> Pete.


The problem is that since the first FITS paper (and still in the standard),
the fixed format is recommended for header cards.  In the fixed format there
must be at least 8 characters in a character value.  Reading that paper
if I wished to specify a string with the value of '' in the fixed format
I believe I would have written it as
    ABCDEFGH= '      '
and felt that I was following the recommendations of the standard.

If that is not the case, then I'd regard this as a minor violation
of the once FITS, always FITS rule.  If we were to follow that
rule strictly, then imho a header value of at least 8 blanks is indeterminate
as to whether it represents a single blank or a zero length string.

In either case an explicit statement in the of this would be appropriate
if the standard is ever revised.  Either there is a value that cannot be represented
in the recommended format (which implies that a null string value cannot ever be
used for a mandatory keyword) or there is a peculiar ambiguity in the meaning
of blank strings.

		Regards,
		Tom

P.S., my own feeling is that the ability to represent a single blank but
not, say, two blanks is not really such a big deal, and it might have been better
for all four of the examples above to be the same, but that's not
a feasible outcome today.