ps documents Re: [fitsbits] Re: FITS vis a vis XML

[Rob Seaman]

Lucio Chiappetti <lucio at ifctr.mi.cnr.it> writes:

> It depends what are the purposes of a document. I am a strong supporter
> of Ockham's razor : file structures non sunt multiplicanda praeter
> necessitatem. I can in general envisage three purposes and usages :
> 
>  - the editing of the document. This is a business for a restricted
>    team of authors, and the choice of format is their own (Latex, Word
>    or whatever ; converters exist for the formats below). These sort of
>    documents need not to be made public.
> 
>  - the printing of a paper hardcopy. For this ftp retrieval of a postscript
>    version is the best. Can be printed with just an lpr commands.
> 
>  - the on-line browsing. For this HTML is the obvious choice. And
>    converters to HTML do exist, if one is not writing natively in it.
>    Again no extra s/w needed but a plain browser.
>    
>    I would consider bad practice using ps as a format for reading documents
>    online.
> 
> I would not mind if pdf is supplied as an addition, provided the ps version
> does not disappear (I willingly never bothered to install a pdf reader on my
> own workstation).

The offhand comment at the end here is the real issue.  Documentation
needs to support the folks who need to read it.

PostScript is certainly the easiest hardcopy choice currently for those
of us with Unix workstations and laser printers.  PDF is better supported
for generic PC and Mac users (which also includes many of us) - and is
also supported for Unix users - who choose to install it.

HTML is an obvious choice for online browsing - for simple documents.
The more technical the document, the less ideal HTML becomes.  PDF is
currently a bit clunky for online browsing, but serviceable.

But again, this assumes that the users are "online".  HTML is pretty
worthless for "offline" browsing.  PDF is much better for this.  Loading
a CD-ROM with PostScript files is equivalent to writing a backup tape.
Loading the same CD-ROM with PDF files is a much more "plug-and-play"
decision, for instance.  (You can also dump a HTML web site to CD-ROM,
but then have to deal with relative vs. absolute links and with the lack
of a server to run CGI scripts and so on.)

The choice of the native format of the master "source code" of the
document is indeed a free parameter.  However FITS (for instance) has
some constraints on this choice that might well be worth considering.

First of all, the master copy of much FITS documentation is the refereed
literature.  Each revision of one of these documents is, in effect, a
separate publication.  Secondly, FITS is intended to have a very long
lifetime indeed - this suggests selecting a source format that is very
stable - perhaps not some Microsoft product whose working format changes
with each software release.

> "These sort of documents need not to be made public."

Eventually these documents MUST be made public, or FITS is doomed on the
timescale of our various organizations.  NASA may be posited to continue
indefinitely (ignoring the still theoretical possibilities of the
commercialization of space) - but what about the FITS Office or NOST
or HEASARC or GSFC?  The IAU remains the owner of FITS - should the IAU
(which will presumably continue as long as the astronomical community)
rely on documentation whose archival format is outside their control?

One might expect the current spate of FITS changes and additions to
settle down at some point (even if 20 years hence) - at that point the
documentation and various other archival information from the FITS
community (like this newsgroup) would likely be dumped onto some
permanent media and distributed around the community for convenience
and safety.  We've created a very stable format - shouldn't the
documentation source be as stable as possible, too?  (Anybody want
to vote for anything other than (La)TeX or some other format whose
own source code we can include on the same media?)

But having selected some format for the source documentation, it seems
very reasonable to generate multiple user formats, just as our source
code is often recompiled for multiple platforms.  If we ignore the needs
(or even just the whims) of folks who want to use FITS, the only possible
outcome is that FITS will be less well supported, if it is supported at all.

Rob

-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B