[fitsbits] problems with fits readers

At the behest of some individuals who read the aips output FITS files
closely, I made a change so that variables we keep in double precision
internally are shown as double precision floats on output FITS
headers.

A user reports trouble with this:

My problem is that it seems that neither the 'kvis' task in KARMA,
or DS9 (the display and analysis programme used in conjunction with
Chandra and XMM data analysis, see http://hea-www.harvard.edu/RD/ds9/),
can handle correctly this new format.

She did a diff on the headers from the current AIPS and the previous
one and gets

diff 03dec-version 04dec-version
16,17c16,17
BSCALE = 3.16551153040E-06 /REAL = TAPE * BSCALE + BZERO
BZERO = 1.02674588561E-01 /
---
BSCALE = 3.16551153040D-06 /REAL = TAPE * BSCALE + BZERO
BZERO = 1.02674588561D-01 /
22,23c22,23
OBSRA = 2.50952791667E+02 /Antenna pointing RA
OBSDEC = 1.72636944444E+01 /Antenna pointing DEC
---
OBSRA = 2.50952791667D+02 /Antenna pointing RA
OBSDEC = 1.72636944444D+01 /Antenna pointing DEC
27c27
CRVAL1 = 2.50952791667E+02 /
---
CRVAL1 = 2.50952791667D+02 /
32c32
CRVAL2 = 1.72636944444E+01 /
---
CRVAL2 = 1.72636944444D+01 /
37c37
CRVAL3 = 1.49399000000E+10 /
---
CRVAL3 = 1.49399000000D+10 /
42c42
CRVAL4 = 1.00000000000E+00 /
---
CRVAL4 = 1.00000000000D+00 /

The FITS standard makes it clear that either format is acceptable and
that neither the E nor the D STATE anything about precision (although
they do carry an implication to knowledgable readers).

I guess that I will have to roll back the change to AIPS in defense,
but I would like to urge authors of FITS readers to check their code
immediately to make sure that the D form is understood as well as the
E form. This has been a part of the standard since day 1.

Eric Greisen