<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear Bill,</p>
<p>In the following document:<br>
<a class="moz-txt-link-freetext"
href="https://fits.gsfc.nasa.gov/users_guide/users_guide/node7.html">https://fits.gsfc.nasa.gov/users_guide/users_guide/node7.html</a>, <br>
it is written:<br>
<font face="monospace">"Changes in the FITS rules may add new
structures that old software
cannot<br>
handle. Revised software will be required for new standard
extensions, but<br>
revising a software package is a far smaller effort than
updating a full <br>
data library would be. <br>
As far as is possible, however, FITS should be expanded in such
a way <br>
that the old software will still be able to process those parts
of the file <br>
which it is capable of handling. In such a case, software should
not fail <br>
or give incorrect results when confronted with the new extension
or <br>
conventions; it should simply ignore them and continue to
process<br>
those parts of the file that it can understand."</font><br>
</p>
<p>The text "as far as" is open to interpretation, and it seems from
you message<br>
that François may be interpreting it somewhat strictly.</p>
<p>I would therefore like to join Mark Taylor in thanking you for
the clarification,<br>
and I agree (also with Arnold) that solution 1 (adopted in
VOTable) is<br>
"fully consistent with this 'once FITS always FITS' rule".<br>
<br>
Adopting it may require software to be updated<br>
(or at least tested with UTF-8 data): I don't known what would be<br>
the behavior of current software encountering non-ASCII UTF-8
codepoints<br>
in a "<span style="white-space: pre-wrap">TFORM = xA" column...</span></p>
<p><br>
</p>
<p>Dear Rob,</p>
<p>As confirmed by Mark Taylor, the proposal concerns UTF-8 only in<br>
BINTABLE (or ASCII) columns, not in the header.<br>
For TFORM= 'rA', TFORM='PA(emax)', and TFORM='QA(emax)',<br>
the values of 'r', 'emax' and the stored "number of elements"<br>
would need to be interpreted as a number of bytes<br>
(which is the number of ASCII characters in an ASCII string,<br>
which is an ASCII-only UTF-8 string). </p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Le 04/04/2026 à 20:19, William Pence
via fitsbits a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:E7C6C3DF-B63B-4A55-8570-4E20C24C3D5C@yahoo.com">
<pre wrap="" class="moz-quote-pre">Roughly translated, Francois wrote: “it would have seemed important to keep the distinction between pure ascii and utf-8, because of the FITS logic to ensure that changes in the standard should not affect existing applications would be violated”.
Just to be clear, there has never been a requirement that changes to the definition of the FITS format must not cause problems for existing software applications. The actual requirement, as stated in section 3.7 of the FITS Standard is that “Any structure that is a valid FITS structure shall remain a valid FITS structure at all future times” (often referred to as the “once FITS, always FITS” rule).
Bill
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">On Apr 3, 2026, at 11:16 PM, Francois Ochsenbein via fitsbits <a class="moz-txt-link-rfc2396E" href="mailto:fitsbits@listmgr.nrao.edu"><fitsbits@listmgr.nrao.edu></a> wrote:
Bonjour FX,
Apparemment le « current draft of VOTable 1.6 » n'existe pas ?
Personnellement il m'aurait semblé important de conserver la
distinction entre pur ascii et utf-8, car la logique de FITS de
garantir que les changements dans le standard ne doivent pas affecter
les applications existantes serait violée… Mais je serais curieux de
savoir en quoi le HATS a besoin d'UTF-8 ?
En te souhaitant une belle fin de semaine, et peut-être à bientôt ?
Bien amicalement, François
==> Le jeudi 2026-03-26 à 14:43+0100,
Francois-Xavier PINEAU via fitsbits <a class="moz-txt-link-rfc2396E" href="mailto:fitsbits@listmgr.nrao.edu"><fitsbits@listmgr.nrao.edu></a> a
écrit:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Dear fitsbits,
# Background
VOTable (v1.5) is closely compatible with the FITS Binary Table format:
<a class="moz-txt-link-freetext" href="https://www.ivoa.net/documents/VOTable/20250116/REC-VOTable-1.5.html#tth_sEc2.3">https://www.ivoa.net/documents/VOTable/20250116/REC-VOTable-1.5.html#tth_sEc2.3</a>
In the current draft of VOTable 1.6
<a class="moz-txt-link-freetext" href="https://github.com/ivoa-std/VOTable/releases/download/auto-pdf-preview/VOTable-draft.pdf">https://github.com/ivoa-std/VOTable/releases/download/auto-pdf-preview/VOTable-draft.pdf</a>
,
UTF-8 strings replace the previous ASCII-only strings.
If FITS cannot store UTF-8, *lossless round-trip conversion from
VOTable to FITS will no longer be possible*.
Some limitations already exist (e.g., unsigned integer logical types),
but UTF-8 seems more critical.
Personal use cases include the usage of HEALPix sorted and indexed
BINTABLES to build on-the-fly HATS products
or intermediary HiPS catalogue representations from VizieR data (will
contains more and more UTF-8).
* HATS: <a class="moz-txt-link-freetext" href="https://www.ivoa.net/documents/Notes/HATS/">https://www.ivoa.net/documents/Notes/HATS/</a>
* HIPS catalogue: <a class="moz-txt-link-freetext" href="https://www.ivoa.net/documents/HiPS/">https://www.ivoa.net/documents/HiPS/</a>
* VizieR: <a class="moz-txt-link-freetext" href="https://vizier.u-strasbg.fr/">https://vizier.u-strasbg.fr/</a>
# Possible Solutions
## 1. Use UTF-8 in existing `TFORMn=rA`
Like in VOTAble 1.6, interpret `r` as bytes instead of characters.
May break truncation operations (TDIPS) if a multi-byte UTF-8
character is split.
## 2. Logical type "UTF-8" backed by a byte array
TFORMn = rB
TLOGTn = 'UTF-8' / LOGT stands for LOGical Type
Unaware readers see a byte array; UTF-8 aware readers interpret it as
a string.
Introduces two string types in FITS (ASCII and UTF-8).
## 3. New TFORM type (e.g., `TFORMn=rU`)
Definite breakage for current readers.
# Existing Implementations
* TOPCAT/STILTS (Java): Prototype supports Solutions 1 and 2 for
read/write (private communication with Mark Taylor).
* fitstable (Rust): Supports Solutions 1 and 2 for reading
(<a class="moz-txt-link-freetext" href="https://github.com/cds-astro/cds-fitstable-rust">https://github.com/cds-astro/cds-fitstable-rust</a>).
* VizieR: Appears to provide UTF-8 in TFORMn=rA columns (Solution 1).
* ??
# Feedback Requested
I am curious about:
* other possible approaches
* fitsbits opinions on the most practical solution
* other people interested in having UTF-8 in BINTABLE columns
Currently, Solution 1 seems the simplest and Solution 2 the safest,
but I welcome constructive comments and experience from the community.
Best regards,
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
--
======================================================================
Francois <a class="moz-txt-link-abbreviated" href="mailto:Ochsenbein@free.fr">Ochsenbein@free.fr</a> --- 67380 Lingolsheim
======================================================================
_______________________________________________
fitsbits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a>
<a class="moz-txt-link-freetext" href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
_______________________________________________
fitsbits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a>
<a class="moz-txt-link-freetext" href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a>
</pre>
</blockquote>
<div class="moz-signature">-- <br>
<p
style="font-family: Arial, sans-serif; color: black; font-size: 14px;"><span
style="font-weight: bold">Francois-Xavier Pineau</span><br>
Ingénieur de Recherche<br>
Tél : +33 (0)3 68 85 24 14,<br>
<a href="mailto:francois-xavier.pineau@astro.unistra.fr"
title="Contacter francois-xavier.pineau@astro.unistra.fr"
class="moz-txt-link-freetext">francois-xavier.pineau@astro.unistra.fr</a><br>
<br>
Centre de Données astronomiques de Strasbourg (CDS)<br>
11, rue de l'Université - E03<br>
<br>
<br>
</p>
</div>
</body>
</html>