17a18
> 
21,23c22
<     \documentclass[11pt,makeidx]{book}     % final version
<     \usepackage{iaufwg}
< %    \documentstyle[11pt,nost,epsf,makeidx]{book}     % final version
---
>     \documentstyle[11pt,nost,epsf,makeidx]{book}     % final version
25,27c24
<     \documentclass[11pt,makeidx,showidx]{book}% index debug version
<     \usepackage{iaufwg}
< %    \documentstyle[11pt,nost,epsf,makeidx,showidx]{book}% index debug version
---
>     \documentstyle[11pt,nost,epsf,makeidx,showidx]{book}% index debug version
30,32c27
<  \documentstyle[11pt]{book}                   % no index
<     \usepackage{iaufwg}
< % \documentstyle[11pt,nost,epsf]{book}                   % no index
---
>  \documentstyle[11pt,nost,epsf]{book}                   % no index
35c30,37
< %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
---
> %
> %%%%%%%%%%%%
> \newcommand{\FITS}{\em FITS\/}
> \newcommand{\eg}{{\it e.g.},}
> %%%%%%%%%%%%%
> %
> \author{ }
> \shorttitle{NOST {\em FITS\/} Definition} 
41,42c43,103
< %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
< 
---
> \title{  Definition of the Flexible Image Transport System (\FITS) }
> %\title{  Definition of the Flexible Image Transport System ({\em FITS\/}) }
> %
> \standardnumber{NOST 100-2.0}
> %
> \date{March 29, 1999}
> %
> \publisher{ NASA/Science Office of Standards and Technology \\
>             Code 633.2  \\
>             NASA Goddard Space Flight Center \\
>             Greenbelt MD 20771 \\ 
>             USA}
> \pubaddress{ NOST, Code 633.2, NASA Goddard Space Flight Center \\
>             Greenbelt MD 20771 \\
>             USA \\           
>             electronic mail: nost@nssdca.gsfc.nasa.gov \\
>             +1-301-286-3575 \\
>             http://ssdoo.gsfc.nasa.gov/nost/ }
> \offaddress{ FITS Support Office \\ Code 631, 
>              NASA Goddard Space Flight Center \\
>             Greenbelt MD 20771 \\
>             USA \\           
>             electronic mail: fits@fits.gsfc.nasa.gov \\
>             +1-301-286-6695 \\
>             http://fits.gsfc.nasa.gov/ }
> %
> \panel{  Robert J. Hanisch, Chair &
>              {\raggedright Space Telescope Science Institute} \\
>          William D. Pence, Secretary &
>              {\raggedright NASA Goddard Space Flight Center} \\
>          Barry M. Schlesinger, Past Secretary   &
>              {\raggedright Raytheon STX} \\
>          Allen Farris  &
>              {\raggedright Space Telescope Science Institute} \\
>          Eric W. Greisen  &
>              {\raggedright National Radio Astronomy Observatory} \\
>          Peter J. Teuben  &
>              {\raggedright University of Maryland} \\
>          Randall W. Thompson &
>              {\raggedright Computer Sciences Corporation} \\
>          Archibald Warnock &
>              {\raggedright A/WWW Enterprises} \\
>           \\
>          \multicolumn{2}{l}
>          {Members of the previous Technical Panels also included:} \\
>          Lee E. Brotzman &
>              {\raggedright Hughes STX} \\
>          Edward Kemper &
>              {\raggedright Hughes STX} \\
>          Michael E. Van Steenberg &
>              {\raggedright NASA Goddard Space Flight Center} \\
>          Wayne H. Warren Jr. &
>              {\raggedright Hughes STX} \\
>          Richard A. White &
>              {\raggedright NASA Goddard Space Flight Center} \\ }
> %
> %
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> %%%%%%%%%%%%%
> %%%%%%%%%%%%%%%%%%%%%%%
> %
44a106
> \maketitle  
46,64c108,109
< \begin{center}
< 
< \vspace*{2.5cm}
< {\LARGE \bf Definition of the Flexible Image Transport System ({\em FITS\/})} \\
< 
< \vspace{3.0cm}
< April 7, 2005 \\
< 
< \vspace{0.8cm}
< FITS Standard \\
< 
< \vspace{0.8cm}
< Version 2.1 \\
< 
< \vspace{4.0cm}
< IAU FITS Working Group \\
< {\tt http://fits.gsfc.nasa.gov/iaufwg/} \\
< 
< \end{center}
---
> \vspace*{7.6cm}
> \vfill
66,68d110
< 
< %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
< 
70,94c112
< {\bf \Large Preface to Version 2.1}
< \vspace*{1.5cm}
< \thispagestyle{empty}
< 
< This Version 2.1 of the {\em FITS\/} Standard  was created by the IAU
< {\em FITS\/} Working Group in April 2005.  It is very similar to the
< NOST 100-2.0 version of the {\em FITS\/} Standard that was developed
< in 1999, approved by the IAU {\em FITS\/} Working
< Group in October 2000, and published in the {\em Astronomy \&
< Astrophysics} scientific  journal in 2001 (volume 376, page 359). 
< The only significant change in this new version is that  the
< descriptions of the ``Variable-Length Array'' facility and the
< ``Multidimensional Array'' convention have been moved from the
< unofficial Appendix B into section 8.3 of the {\em FITS\/} Standard itself.  
< The IAU {\em FITS\/} Working Group officially approved these changes to the 
< {\em FITS\/} Standard on 7 April, 2005.  
< 
< Further information about the membership and role of the IAU FITS
< Working Group can be found on the  {\tt http://fits.gsfc.nasa.gov/iaufwg/}
< web site.
< 
< \newpage
< 
< \setcounter{page}{1}
< 
---
> \begin{authority}
132,201c150
< 
< \begin{center}
< \begin{tabular}[t]{lp{210pt}}
< 
< 
<  	Robert J. Hanisch, Chair &
<              {\raggedright Space Telescope Science Institute} \\
<          William D. Pence, Secretary &
<              {\raggedright NASA Goddard Space Flight Center} \\
<          Barry M. Schlesinger, Past Secretary   &
<              {\raggedright Raytheon STX} \\
<          Allen Farris  &
<              {\raggedright Space Telescope Science Institute} \\
<          Eric W. Greisen  &
<              {\raggedright National Radio Astronomy Observatory} \\
<          Peter J. Teuben  &
<              {\raggedright University of Maryland} \\
<          Randall W. Thompson &
<              {\raggedright Computer Sciences Corporation} \\
<          Archibald Warnock &
<              {\raggedright A/WWW Enterprises} \\
<           \\
<          \multicolumn{2}{l}
<          {Members of the previous Technical Panels also included:} \\
<          Lee E. Brotzman &
<              {\raggedright Hughes STX} \\
<          Edward Kemper &
<              {\raggedright Hughes STX} \\
<          Michael E. Van Steenberg &
<              {\raggedright NASA Goddard Space Flight Center} \\
<          Wayne H. Warren Jr. &
<              {\raggedright Hughes STX} \\
<          Richard A. White &
<              {\raggedright NASA Goddard Space Flight Center} \\
< 	     
< \end{tabular}
< \end{center}\par      
< 	     
< This standard is published and maintained by the NOST\@. Send comments and 
< orders for NOST documents to: \par
< \begin{center}
< \begin{tabular}[t]{l}
< 
<             NOST, Code 633.2, NASA Goddard Space Flight Center \\
<             Greenbelt MD 20771 \\
<             USA \\           
<             electronic mail: nost@nssdca.gsfc.nasa.gov \\
<             +1-301-286-3575 \\
<             http://ssdoo.gsfc.nasa.gov/nost/ 
< \end{tabular}
< \end{center} 
< 
< \vskip2\baselineskip\par
< Other information about {\em FITS\/} can be obtained from the {\em FITS\/} 
< Support Office.  The {\em FITS\/} Support Office 
< can be contacted as follows: 
< \par
< \begin{center}
< \begin{tabular}[t]{l}
< 
<             FITS Support Office \\ 
<             Code 662, NASA Goddard Space Flight Center \\
<             Greenbelt MD 20771 \\
<             USA \\           
<             electronic mail: fits@fits.gsfc.nasa.gov \\
<             +1-301-286-4599 \\
<             http://fits.gsfc.nasa.gov/ 
< \end{tabular}
< \end{center} 
< \vfil\null
---
> \end{authority}
268,270c217,218
< \setcounter{page}{0}
< \pagenumbering{arabic}
< 
---
> \startstandard
>   
367,370c315,322
<    \S\ref{s:valC}.  Appendix \ref{s:Bincon} 
<    describes a convention for handling 
<    arrays\index{array, substring} of substrings in  
<    binary table\index{binary table} extensions.
---
>    \S\ref{s:valC}.  Appendix \ref{s:Bincon} provides examples of 
>    widely accepted {\em FITS\/} conventions that are not part 
>    of the formal {\em FITS\/} standard. 
>    It describes three conventions in use with the 
>    binary table\index{binary table} extension --- one for handling            
>    multidimensional\index{array, multidimensional} arrays, one for 
>    including variable length\index{array, variable length} arrays,
>    and one for arrays\index{array, substring} of substrings.
1726,1731d1677
< Use of the word ``deprecated'' is understood to mean that binary 
< table extensions should be used in new astronomical application 
< areas instead of the random groups format where either is appropriate 
< and where there is no historical precedent for random groups. Existing 
< applications of the random groups structure (almost exclusively 
< interferometry) may continue to use random groups as needed indefinitely;
2502,2505c2448
<  {\tt B}, {\tt I}, or {\tt J},
<  or {\tt P} array descriptor fields (\S\ref{s:app_varlen}) that 
<  point to {\tt B}, {\tt I}, or {\tt J} integer arrays.
<  The keyword may not be used if field {\tt n} is 
---
>  {\tt B}, {\tt I}, or {\tt J}.  The keyword may not be used if field {\tt n} is 
2514,2516c2457,2459
<  of type {\tt P} is
<  defined in \S\ref{s:app_varlen}.
<  For fields with all other data types, the
---
>  of type {\tt P} is not
>  defined.  A proposed interpretation is described in 
>  Appendix \ref{s:app_varlen}.  For fields with all other data types, the
2530,2532c2473,2475
<  type {\tt P} is 
<  defined in \S\ref{s:app_varlen}.
<  For fields with all other data types, 
---
>  type {\tt P} is not
>  defined.  A proposed interpretation is described in 
>  Appendix \ref{s:app_varlen}. For fields with all other data types, 
2558,2560c2501,2503
<  be used.  In the case of fields of type {\tt P}, the {\tt TDISPn} value applies
<  to the data array pointed to by the array descriptor (\S\ref{s:app_varlen}), 
<  not the values in the array descriptor itself.
---
>  be used.  The meaning of this keyword is not defined
>  for fields of type {\tt P} in this standard but may be defined in conventions
>  using such fields. 
2598,2599c2541
<    heap.  The default value, which is also the minimum allowed value,
<    shall be the product\index{NAXIS1} 
---
>    heap.  The default value shall be the product\index{NAXIS1} 
2602,2603c2544,2545
<    be used if the value of {\tt PCOUNT} is zero.  The use of this
<    keyword is described in in \S\ref{s:app_varlen}.
---
>    be used if the value of {\tt PCOUNT} is zero.  A proposed application 
>    of this keyword is presented in Appendix \ref{s:app_varlen}.
2605c2547
<    \paragraph{{\tt TDIMn} Keywords} \label{s:app_dim}
---
>    \paragraph{{\tt TDIMn} Keywords}
2608,2636c2550,2553
<     the contents of field {\tt n} as a multidimensional array
<     with a format of {\tt '($l$,$m$,$n$\ldots)'} where $l$, $m$, $n$,
<     \ldots are the dimensions of the array. The data are ordered such 
<     that the array index of the first dimension given ($l$) is the most
<     rapidly varying and that of the last dimension given is the least 
<     rapidly varying.  The total number of elements in the array equals
<     the product of the dimensions specified in the {\tt TDIMn} keyword.
<     The size must be less than or equal to the repeat count on the 
<     {\tt TFORMn} keyword, or, in the case of columns that have a
<     ``{\tt P}'' {\tt TFORMn} datatype, less than or equal to the array length
<     specified in the variable-length array descriptor 
<     (see \S\ref{s:app_varlen}).  In the special case where the 
<     variable-length array descriptor has a size of zero, then the
<     {\tt TDIMn} keyword is not applicable.  If the number of elements
<     in the array implied by the {\tt TDIMn} is less than the allocated
<     size of the array in the {\em FITS\/} file, then the unused trailing
<     elements should be interpreted as containing undefined fill values.
< 
<     A character string\index{character string} is represented in a binary
< table by a one-dimensional character array, as described under ``Character''
< in the list of datatypes in
< \S\ref{s:MbinT} (``Main Data Table '').  For example, a
< Fortran~77 {\tt CHARACTER*20} variable could be represented in a
< binary table as a character array declared as
< {\tt TFORMn = } \verb*/'20A     '/.  Arrays of character strings, i.e.,
< multidimensional character arrays, may be represented using the
< {\tt TDIMn} notation.  For example, if {\tt TFORMn  = } \verb*/'60A     '/
< and \verb/TDIMn = '(5,4,3)'/, then the entry consists of a
< $4\times 3$ array of strings of 5 characters each. 
---
>     the contents of field {\tt n} as a multidimensional array,
>     providing the number of dimensions and the length along each axis.
>     The form of the value is not further specified by this standard.
>     A proposed convention is described in Appendix \ref{s:app_dim}.
2795,2796c2712,2714
<     The meaning of these integers is defined
<     in \S\ref{s:app_varlen}.
---
>     The meaning of these integers is not defined
>     by this standard.  The proposed application of this data type is 
>     described in Appendix \ref{s:app_varlen}.
2800,2803c2718,2721
<     The main data table shall be followed by an additional data area
<     containing zero or more bytes, as specified by the value of the 
<     {\tt PCOUNT} keyword. One use for this data area is described in 
<     \S\ref{s:app_varlen}. This does not preclude other uses for these bytes.
---
>     The main data table shall be followed by zero or more bytes,
>     as specified by the value of the {\tt PCOUNT} keyword.  
>     The meaning of these bytes is not further defined by this standard.  
>     One proposed application is described in Appendix \ref{s:app_varlen}.
2907,3120c2825
<                                     
< %\appendix A of BINTABLE paper
< \subsection{Variable-Length Arrays}
< \label{s:app_varlen}
< 
<     One of the most attractive features of binary tables is that any
< field of the table can be an array.  In the standard case this is a
< fixed size array, i.e., a fixed amount of storage is allocated in each
< record for the array data---whether it is used or not.  This is fine
< so long as the arrays are small or a fixed amount of array data will
< be stored in each record, but if the stored array length varies for
< different records, it is necessary to impose a fixed upper limit on
< the size of the array that can be stored.  If this upper limit is made
< too large excessive wasted space can result and the binary table
< mechanism becomes seriously inefficient.  If the limit is set too low
< then it may become impossible to store certain types of data in the
< table.
< 
< The ``variable-length array'' construct\index{array, variable length}
< presented here\index{variable length array} was devised to
< deal with this problem.  Variable-length arrays are implemented in
< such a way that, even if a table contains such arrays, a simple reader
< program which does not understand variable-length arrays will still be
< able to read the main table (in other words a table containing
< variable-length arrays conforms to the basic binary table standard).
< The implementation chosen is such that the records in the main table
< remain fixed in size even if the table contains a variable-length
< array field, allowing efficient random access to the main table.
< 
< Variable-length arrays are logically equivalent to regular static
< arrays, the only differences being 1) the length of the stored array
< can differ for different records, and 2) the array data are not stored
< directly in the table records.  Since a field of any datatype can be a
< static array, a field of any datatype can also be a variable-length
< array (excluding type {\tt P}, the variable-length array descriptor
< itself, which is not a datatype so much as a storage class specifier).
< Other established {\em FITS\/} conventions that apply to static arrays will
< generally apply as well to variable-length arrays.
< 
< A variable-length array is declared in the table header with a special
< field datatype specifier of the form
< %       \[ r\mbox{{\tt P}}t\mbox{(}maxelem\mbox{)} \]
< \[ {\tt rPt}({\tt e}_{\rm max}) \]
< where the ``{\tt P}'' indicates the amount of space occupied by the
< array descriptor\index{array descriptor} in the data record (64 bits), the
< element count {\tt r} should be 0, 1, or absent, {\tt t} is a character denoting
< the datatype of the array data ({\tt L},  {\tt X}, {\tt B},
< {\tt I}, {\tt J}, etc., but not {\tt P}), and ${\tt e}_{\rm max}$ is a
< quantity guaranteed to be equal to or greater than the maximum number
< of elements of type {\tt t} actually stored in a table record. There
< is no built-in upper limit on the size of a stored array
< (other than the fundamental limit imposed by the range of the 32-bit array
< descriptor, defined below);
< ${\tt e}_{\rm max}$ merely reflects the size of the largest array actually
< stored in the table, and is provided to avoid the need to preview the
< table when, for example, reading a table containing variable-length
< elements into a database that supports only fixed size arrays.  There
< may be additional characters in the {\tt TFORMn} keyword
< following\index{TFORMn} the ${\tt e}_{\rm max}$.
< 
< For example,
< \[\mbox{{\tt TFORM8  = 'PB(1800)'   / Variable byte array}} \]
< indicates that field 8 of the table is a variable-length array of type
< byte, with a maximum stored array length not to exceed 1800 array
< elements (bytes in this case).
< 
< The data for the variable-length arrays in a table are not stored in
< the actual data records; they are stored in a special data area, the
< heap\index{heap}, following the last fixed size data record. 
< What is stored in
< the data record is an {\em array descriptor}.  This consists of two
< 32-bit signed integer values: the number of elements (array length) of the
< stored array, followed by the zero-indexed byte offset of the first
< element of the array, measured from the start of the heap area.
< The meaning of a negative value for either of these integers is not
< defined by this standard.
< Storage for the array is contiguous.  The array descriptor for field
< $N$ as it would appear embedded in a data record is illustrated
< symbolically below:
< 
< \begin{center}
< $\ldots$ [field $N$--1] [(nelem,offset)] [field $N$+1] $\ldots$
< \end{center}
< 
< If the stored array length is zero there is no array data, and the
< offset\index{offset} value is undefined 
< (it should be set to zero).  The storage
< referenced by an array descriptor must lie entirely within the heap
< area; negative offsets are not permitted.
< 
< A binary table containing variable-length arrays consists of three
< principal segments, as follows:
< %\[ [table\_header] [record\_storage\_area] [heap\_area]  \]
< 
< \begin{center}
< [table\_header] [record\_storage\_area] [heap\_area]
< \end{center}
< 
< The table header consists of one or more 2880-byte {\em FITS\/} logical
< records with the last record indicated by the\index{END} 
< keyword {\tt END}
< somewhere in the record.  The record storage area begins with the next
< 2880-byte logical record following the last header record and is
< $\mbox{\tt NAXIS1} \times \mbox{\tt NAXIS2}$ bytes in length.  
< The\index{NAXIS1} zero\index{NAXIS2} indexed
< byte offset of the heap measured from the start of the record storage
< area is given by the {\tt THEAP} keyword\index{THEAP} in the header.  
< If this
< keyword is missing the heap is assumed to begin with the byte
< immediately following the last data record, otherwise there may be a
< gap between the last stored record and the start of the heap.  If
< there is no gap the value of the heap offset 
< is $\mbox{\tt NAXIS1}\times\mbox{\tt NAXIS2}$.   
< The total length in bytes of the
< heap area following the last stored record (gap plus heap) is given by
< the {\tt PCOUNT} keyword\index{PCOUNT} in the table header.
< 
< For example, suppose we have a table containing 5 rows each 168 bytes
< long, with a heap area 3000 bytes long, beginning at an offset of
< 2880, thereby aligning the record storage and heap areas on {\em FITS\/}
< record boundaries (this alignment is not necessarily recommended but
< is useful for our example).  The data portion of the table consists of
< 3 2880-byte {\em FITS\/} records:
< the first record contains the 840 bytes from the 5 rows of the main
< table followed by 2040 fill bytes; the heap completely fills the second
< record; the third record contains the remaining 120 bytes of the heap
< followed by 2760 filll bytes. {\tt PCOUNT} gives the total number of
< bytes from the end of the main table to the end of the heap and in this
< example has a value of $2040 + 2880 + 120 = 5040$.
< This is expressed in the table header as:  
< \begin{verbatim}
< NAXIS1  =    168 / Width of table row in bytes
< NAXIS2  =      5 / Number of rows in table
< PCOUNT  =   5040 / Random parameter count
<   ...
< THEAP   =   2880 / Byte offset of heap area
< \end{verbatim}
< 
< \vskip 1em
< The values\index{TSCALn} of {\tt TSCALn} and {\tt TZEROn}
< for\index{TZEROn} variable-length
< array column entries are to be applied to the values in the
< data array in the heap area, not the values of the array descriptor.
< These keywords can be used to scale data values in either
< static or variable-length arrays.
< 
< While the above description is sufficient to define the required
< features of the variable-length array implementation, some hints
< regarding usage of the variable-length array facility may also be
< useful.
< 
< Programs which read binary tables should take care to not assume more
< about the physical layout of the table than is required by the
< specification.  For example, there are no requirements on the
< alignment of data within the heap.  If efficient runtime access is a
< concern one may want to design the table so that data arrays are
< aligned to the size of an array element.  In another case one might
< want to minimize storage and forgo any efforts at alignment (by
< careful design it is often possible to achieve both goals).  Variable-length
< array data may be stored in the heap in any order, i.e., the data for
< record $N$+1 are not necessarily stored at a larger offset than that for
< record $N$.  There may be gaps in the heap where no data are stored.
< Pointer aliasing is permitted, i.e., the array descriptors for two or
< more arrays may point to the same storage location (this could be used
< to save storage if two or more arrays are identical).
< 
< Byte arrays are a special case because they can be used to store a
< ``typeless'' data sequence.  Since {\em FITS\/} is a machine-independent
< storage format, some form of machine-specific data conversion (byte
< swapping, floating point format conversion) is implied when accessing
< stored data with types such as integer and floating, but byte arrays
< are copied to and from external storage without any form of
< conversion.
< 
< An important feature of variable-length arrays is that it is possible
< that the stored array length may be zero.  This makes it possible to
< have a column of the table for which, typically, no data are present in
< each stored record.  When data are present the stored array can be as
< large as necessary.  This can be useful when storing complex objects
< as records in a table.
< 
< Accessing a binary table stored on a random access storage medium is
< straightforward.  Since the data records in the main table are fixed
< in size they may be randomly accessed given the record number, by
< computing the offset.  Once the record has been read in, any variable-length
< array data may be directly accessed using the element count and
< offset given by the array descriptor stored in the data record.
< 
< Reading a binary table stored on a sequential access storage medium
< requires that a table of array descriptors\index{array descriptor} be built
< up as the main
< table records are read in.  Once all the table records have been read,
< the array descriptors are sorted by the offset of the array data in
< the heap\index{heap}.  As the heap data are read, 
< arrays are extracted sequentially
< from the heap and stored in the affected records using the back
< pointers to the record and field from the table of array descriptors.
< Since array aliasing is permitted, it may be necessary to store a
< given array in more than one field or record.
< 
< Variable-length arrays\index{variable length array} are more complicated
< than\index{array, variable length} regular static arrays and
< may not be supported by some software systems.  The producers of
< {\em FITS\/} data products should consider the capabilities 
< of the likely recipients of their files when deciding whether or
< not to use this format, and as a general rule should use it only
< in cases where it provides significant advantages over the simpler
< fixed-length array format.  In particular, the use of variable-length
< arrays may present difficulties for applications that ingest the
< {\em FITS\/} file via a sequential input stream because the application 
< cannot fully process any rows in the table until after the entire fixed-length
< table and potentially the entire heap has been transmitted as outlined
< in the previous paragraph.
< 
---
>                                       
3297c3002
< \chapter{Proposed Binary Table Convention}
---
> \chapter{Proposed Binary Table Conventions}
3306,3309c3011,3015
< substring arrays.  
< The first 2 conventions were subsequently (April 2005) approved by the
< IAUFWG and have been incorporated into the official {\em FITS\/} standard.
< The draft text for the remaining appendix, available on-line in
---
> substring arrays.  These 
> conventions, discussed in appendixes to the proposal, are not part of the
> formal {\tt BINTABLE} rules adopted by the IAUFWG
> but are expected to enjoy wide
> acceptance.  The draft text for those appendixes, available on-line in
3314a3021,3269
> %\appendix A of BINTABLE paper
> \section{``Variable Length Array'' Facility}
> \label{s:app_varlen}
> 
>     One of the most attractive features of binary tables is that any
> field of the table can be an array.  In the standard case this is a
> fixed size array, i.e., a fixed amount of storage is allocated in each
> record for the array data---whether it is used or not.  This is fine
> so long as the arrays are small or a fixed amount of array data will
> be stored in each record, but if the stored array length varies for
> different records, it is necessary to impose a fixed upper limit on
> the size of the array that can be stored.  If this upper limit is made
> too large excessive wasted space can result and the binary table
> mechanism becomes seriously inefficient.  If the limit is set too low
> then it may become impossible to store certain types of data in the
> table.
> 
> The ``variable length array'' construct\index{array, variable length}
> presented here\index{variable length array} was devised to
> deal with this problem.  Variable length arrays are implemented in
> such a way that, even if a table contains such arrays, a simple reader
> program which does not understand variable length arrays will still be
> able to read the main table (in other words a table containing
> variable length arrays conforms to the basic binary table standard).
> The implementation chosen is such that the records in the main table
> remain fixed in size even if the table contains a variable length
> array field, allowing efficient random access to the main table.
> 
> Variable length arrays are logically equivalent to regular static
> arrays, the only differences being 1) the length of the stored array
> can differ for different records, and 2) the array data is not stored
> directly in the table records.  Since a field of any datatype can be a
> static array, a field of any datatype can also be a variable length
> array (excluding type {\tt P}, the variable length array descriptor
> itself, which is not a datatype so much as a storage class specifier).
> Conventions such\index{TDIMn} as {\tt TDIMn} 
> (see Appendix~\ref{s:app_dim})
> apply equally to both variable length and static arrays.
> 
> A variable length array is declared in the table header with a special
> field datatype specifier of the form
> %       \[ r\mbox{{\tt P}}t\mbox{(}maxelem\mbox{)} \]
> \[ {\tt rPt}({\tt e}_{\rm max}) \]
> where the ``{\tt P}'' indicates the amount of space occupied by the
> array descriptor\index{array descriptor} in the data record (64 bits), the
> element count {\tt r} should be 0, 1, or absent, {\tt t} is a character denoting
> the datatype of the array data ({\tt L},  {\tt X}, {\tt B},
> {\tt I}, {\tt J}, etc., but not {\tt P}), and ${\tt e}_{\rm max}$ is a
> quantity guaranteed to be equal to or greater than the maximum number
> of elements of type {\rm t} actually stored in a table record. There
> is no built-in upper limit on the size of a stored array;
> ${\tt e}_{\rm max}$ merely reflects the size of the largest array actually
> stored in the table, and is provided to avoid the need to preview the
> table when, for example, reading a table containing variable length
> elements into a database that supports only fixed size arrays.  There
> may be additional characters in the {\tt TFORMn} keyword
> following\index{TFORMn} the ${\tt e}_{\rm max}$.
> 
> For example,
> \[\mbox{{\tt TFORM8  = 'PB(1800)'   / Variable byte array}} \]
> indicates that field 8 of the table is a variable length array of type
> byte, with a maximum stored array length not to exceed 1800 array
> elements (bytes in this case).
> 
> The data for the variable length arrays in a table is not stored in
> the actual data records; it is stored in a special data area, the
> heap\index{heap}, following the last fixed size data record. 
> What is stored in
> the data record is an {\em array descriptor}.  This consists of two
> 32-bit integer values: the number of elements (array length) of the
> stored array, followed by the zero-indexed byte offset of the first
> element of the array, measured from the start of the heap area.
> Storage for the array is contiguous.  The array descriptor for field
> $N$ as it would appear embedded in a data record is illustrated
> symbolically below:
> 
> \begin{center}
> $\ldots$ [field $N$--1] [(nelem,offset)] [field $N$+1] $\ldots$
> \end{center}
> 
> If the stored array length is zero there is no array data, and the
> offset\index{offset} value is undefined 
> (it should be set to zero).  The storage
> referenced by an array descriptor must lie entirely within the heap
> area; negative offsets are not permitted.
> 
> A binary table containing variable length arrays consists of three
> principal segments, as follows:
> %\[ [table\_header] [record\_storage\_area] [heap\_area]  \]
> 
> \begin{center}
> [table\_header] [record\_storage\_area] [heap\_area]
> \end{center}
> 
> The table header consists of one or more 2880-byte {\em FITS\/} logical
> records with the last record indicated by the\index{END} 
> keyword {\tt END}
> somewhere in the record.  The record storage area begins with the next
> 2880-byte logical record following the last header record and is
> $\mbox{\tt NAXIS1} \times \mbox{\tt NAXIS2}$ bytes in length.  
> The\index{NAXIS1} zero\index{NAXIS2} indexed
> byte offset of the heap measured from the start of the record storage
> area is given by the {\tt THEAP} keyword\index{THEAP} in the header.  
> If this
> keyword is missing the heap is assumed to begin with the byte
> immediately following the last data record, otherwise there may be a
> gap between the last stored record and the start of the heap.  If
> there is no gap the value of the heap offset 
> is $\mbox{\tt NAXIS1}\times\mbox{\tt NAXIS2}$.   
> The total length in bytes of the
> heap area following the last stored record (gap plus heap) is given by
> the {\tt PCOUNT} keyword\index{PCOUNT} in the table header.
> 
> For example, suppose we have a table containing 5 rows each 168 byte
> records, with a heap area 2880 bytes long, beginning at an offset of
> 2880, thereby aligning the record storage and heap areas on {\em FITS\/}
> record boundaries (this alignment is not necessarily recommended but
> is useful for our example).  The data portion of the table consists of
> 2 2880-byte {\em FITS\/} records, 840 bytes of which are used by the 5
> table records, hence {\tt PCOUNT} is $2\times 2880-840$, or 4920 bytes;
> this is expressed in the table header as:  
> \begin{verbatim}
> NAXIS1  =    168 / Width of table row in bytes
> NAXIS2  =      5 / Number of rows in table
> PCOUNT  =   4920 / Random parameter count
>   ...
> THEAP   =   2880 / Byte offset of heap area
> \end{verbatim}
> 
> \vskip 1em
> The values\index{TSCALn} of {\tt TSCALn} and {\tt TZEROn}
> for\index{TZEROn} variable
> length array column entries are to be applied to the values in the
> data array in the heap area, not the values of the array descriptor.
> These keywords can be used to scale data values in either
> static or variable length arrays.
> 
> While the above description is sufficient to define the required
> features of the variable length array implementation, some hints
> regarding usage of the variable length array facility may also be
> useful.
> 
> Programs which read binary tables should take care to not assume more
> about the physical layout of the table than is required by the
> specification.  For example, there are no requirements on the
> alignment of data within the heap.  If efficient runtime access is a
> concern one may want to design the table so that data arrays are
> aligned to the size of an array element.  In another case one might
> want to minimize storage and forgo any efforts at alignment (by
> careful design it is often possible to achieve both goals).  Variable
> array data may be stored in the heap in any order, i.e., the data for
> record $N$+1 is not necessarily stored at a larger offset than that for
> record $N$.  There may be gaps in the heap where no data is stored.
> Pointer aliasing is permitted, i.e., the array descriptors for two or
> more arrays may point to the same storage location (this could be used
> to save storage if two or more arrays are identical).
> 
> Byte arrays are a special case because they can be used to store a
> ``typeless'' data sequence.  Since {\em FITS\/} is a machine-independent
> storage format, some form of machine-specific data conversion (byte
> swapping, floating point format conversion) is implied when accessing
> stored data with types such as integer and floating, but byte arrays
> are copied to and from external storage without any form of
> conversion.
> 
> An important feature of variable length arrays is that it is possible
> that the stored array length may be zero.  This makes it possible to
> have a column of the table for which, typically, no data is present in
> each stored record.  When data is present the stored array can be as
> large as necessary.  This can be useful when storing complex objects
> as records in a table.
> 
> Accessing a binary table stored on a random access storage medium is
> straightforward.  Since the data records in the main table are fixed
> in size they may be randomly accessed given the record number, by
> computing the offset.  Once the record has been read in, any variable
> length array data may be directly accessed using the element count and
> offset given by the array descriptor stored in the data record.
> 
> Reading a binary table stored on a sequential access storage medium
> requires that a table of array descriptors\index{array descriptor} be built
> up as the main
> table records are read in.  Once all the table records have been read,
> the array descriptors are sorted by the offset of the array data in
> the heap\index{heap}.  As the heap data is read, 
> arrays are extracted sequentially
> from the heap and stored in the affected records using the back
> pointers to the record and field from the table of array descriptors.
> Since array aliasing is permitted, it may be necessary to store a
> given array in more than one field or record.
> 
> Variable length arrays\index{variable length array} are more complicated
> than\index{array, variable length} regular static arrays
> and imply an extra data access per array to fetch all the data for a
> record.  For this reason, it is recommended that regular static arrays
> be used instead of variable length arrays unless efficiency or other
> considerations require the use of a variable array.
> 
> \vskip 1em
> This facility is still undergoing trials and is not part of the
> basic binary table definition.
> %\vfil\eject
> 
> %\appendix B of BINTABLE paper
> \section{``Multidimensional Array'' Convention}
> \label{s:app_dim}
> 
>    It is anticipated that binary tables will need to contain data
> structures more complex that those describable by the basic notation.
> Examples of these are\index{array, multidimensional} 
> multidimensional arrays and nonrectangular data
> structures.  Suitable conventions may be defined to pass these
> structures using some combination of keyword/value pairs and table
> entries to pass the parameters of these structures.
> 
>    One case, multidimensional arrays, is so common that it is prudent
> to describe a simple convention.  The ``Multidimensional array''
> convention consists of the following: any column with a dimensionality
> of 2 or larger will have an associated character\index{TDIMn} keyword
> {\tt TDIMn   ='($l$,$m$,$n$\ldots)'} where $l$, $m$, $n$,\ldots are the
> dimensions of the array.
> The data is ordered such that the array index of the first dimension
> given ($l$) is the most rapidly varying and that of the last
> dimension given is the least rapidly varying.  The size implied by the
> {\tt TDIMn} keyword will equal the element count specified in the
> {\tt TFORMn} keyword.  The adherence to this convention will be
> indicated by the presence of a {\tt TDIMn} keyword in the form
> described above. 
> 
>     A character string\index{character string} is represented in a binary
> table by a one-dimensional character array, as described under ``Character''
> in the list of datatypes in
> \S\ref{s:MbinT} (``Main Data Table '').  For example, a
> Fortran~77 {\tt CHARACTER*20} variable could be represented in a
> binary table as a character array declared as
> {\tt TFORMn = } \verb*/'20A     '/.  Arrays of character strings, i.e.,
> multidimensional character arrays, may be represented using the
> {\tt TDIMn} notation.  For example, if {\tt TFORMn  = } \verb*/'60A     '/
> and \verb/TDIMn = '(5,4,3)'/, then the entry consists of a
> $4\times 3$ array of strings of 5 characters each. (Variable length
> character strings are allowed by the convention described in
> Appendix~\ref{s:app_char}.  One dimensional arrays of strings should use
> the convention in Appendix~\ref{s:app_char} rather than the
> ``Multidimensional Array'' convention.)
> 
> \vskip 1em
> This convention is optional and will not preclude other conventions.
> This convention is not part of the binary table definition.
> 
3418c3373
< \S\ref{s:app_dim} of this paper provides a syntax using the
---
> Appendix~\ref{s:app_dim} of this paper provides a syntax using the
3430c3385
< \S\ref{s:app_varlen}.  In this case, the two
---
> Appendix~\ref{s:app_varlen} of this paper.  In this case, the two
4075c4030
<      described in in \S\ref{s:app_varlen}.  
---
>      described in in Appendix \ref{s:app_varlen}.  
4425,4426d4379
< 
< 
4428,4436c4381,4384
< 
< \setlength{\unitlength}{1cm}
< \begin{picture}(6,3)
< \put(1,2){\makebox(1.0,1.0){1}\makebox(3.4,1.0){8}\makebox(5.2,1.0){23}\makebox(3,1.0){....widths}}
< \put(1,1){\framebox(1.0,1.0){{\em s}}\framebox(3.4,1.0){{\em e}}\framebox(5.2,1.0){{\em t}}}
< \put(1,0){\makebox(1.0,1.0){ }\makebox(1.0,1.0){msb}\makebox(1.4,1.0){ }\makebox(1.0,1.0){lsb}
< \makebox(1.0,1.0){msb}\makebox(3.2,1.0){ }\makebox(1.0,1.0){lsb}
< \makebox(2.6,1.0){....order}}
< \end{picture}
---
> \begin{center}
>     \leavevmode
>     \epsffile{ieee1.eps}
> \end{center}
4462,4470c4410,4413
< 
< \setlength{\unitlength}{1cm}
< \begin{picture}(6,3)
< \put(1,2){\makebox(1.0,1.0){1}\makebox(3.4,1.0){11}\makebox(5.2,1.0){52}\makebox(3,1.0){....widths}}
< \put(1,1){\framebox(1.0,1.0){{\em s}}\framebox(3.4,1.0){{\em e}}\framebox(5.2,1.0){{\em t}}}
< \put(1,0){\makebox(1.0,1.0){ }\makebox(1.0,1.0){msb}\makebox(1.4,1.0){ }\makebox(1.0,1.0){lsb}
< \makebox(1.0,1.0){msb}\makebox(3.2,1.0){ }\makebox(1.0,1.0){lsb}
< \makebox(2.6,1.0){....order}}
< \end{picture}
---
> \begin{center}
>     \leavevmode
>     \epsffile{ieee2.eps}
> \end{center}
4686,4688d4628
< %   Also note possible LaTeX incompatibilities with \printindex at the 
< %   end of the document, which may become '\input standard.ind' on some 
< %   systems which do not understand the '\printindex' command...
4691,4692c4631
<   \input fits_standard.ind
< %  \printindex
---
>   \printindex
