Re: Discography

[uli@zoodle.robin.de (Ulrich Grepel)]

Graham says:
> m0o0epX-000Nm6C@zoodle.robin.de sez...
> >well - there are not too many files missing on MY computer. [...]
> >email these 80 or so Megabytes (unpacked) to anyone. Hey! What about a 

> >CD-ROM?)

Actually it's 91 MB by now on my computer, including ~10 MB Digital Librarian
indices. And I estimate I have about 80 to 90 percent of the ftp server. If we 

take in the stuff missing from that and the stuff we will continue producing till 

then I think we stand at about 120, max. 150 MB. Fine CD-ROM, with enough space 

for anything of the following:

- some software to read/process the data, esp. the pics (converters, there
  are plenty in the public domain, and displayers). Software should be in
  binary and in source.
- some prebuilt indices for the stuff (i.e. NeXT's Digital Librarian indices)
- different data formats for the compiled texts (i.e. not the bunch of ~50 MB
  direct gaffa archive and not the bunch of ~35 MB of gifs et al).
- archive of Ecto & rdt. Together with the pictures on the corresponding
  ftp servers. I dunno how many MBs there are in the Ecto archive, but I 

  doubt it's approaching the ftp.uu.net:/usenet/rec.music.gaffa stuff.
- pictures of love-hounds people. At the moment I have exactly ONE tiff in my
  /LocalLibrary/Images/People directory (for non-NeXTies: this directory 

  contains 64*64 pixel tiffs that are shown together with mail of that person).
- important sound files
- perhaps some mpegs? (just to fill the CD up to its limits...)
- perhaps we can persuade Kate to let us add Suspended in GAFFA as track 2 of
  the CD (most audio CD players make ugly noise/nothing of track 1 (data track)
  but could cope easily with track 2 (sound).)

Any additional ideas? (e.g. important other archives/picture sources. Or does
Dave Datta have anything that's not on ftp.uu.net + my love-hounds mailbox of
the last six months?)

Peter (D.F.M.): Would you have something against including your Homeground
text files? Pictures? (Anyone out there with scanner + good OCR software?)

CD-ROM file format: it's nice and completely understandable that you want
to have 8+3 characters filenames. But that's UGLY. If your computer can't
do better, then that's ok with me. But I am thinking of additionally having
a better name space. Isn't there something called 'Rockridge extension'?
Or does this make the CD unreadable for others? An idea that came into my
mind is to produce a .tar file that contains a BUNCH of softlinks with
the long names. This .tar file could be expanded on a harddisk and would
point to the CD-ROM. That way I get my long file names and I won't corrupt
any data structures on the CD. And I would be able to scan the directories
FAST. But I really think this should be automated and am I dreaming if I want 

to have a STANDARD for that kind of stuff? Any CD-ROM format experts out here?

Ok. Now for the data format. As said above this only applies to the compiled
stuff. I think the standard archive should be in either mailbox or news
directory structure. What is better? Should we remove superfluous headers? 

Back to the compiled texts. I list all of the ideas until now, together 

with pros and cons:

- plain ASCII
    pro: everyone can read it, searchable (gee - what about those EBCDIC 

         machines ;-)?)
    con: no structure, no hypertext, no formatting, no nothing
- PostScript
    pro: looks nice, if you have a printer/previewer, you can read it. Most
         computers do have the possibility to (be upgraded to) do that.
         Clearly defined standard.
    con: PostScript is impossible to edit & search. That upgrading above might be
         quite expensive. But there's GhostView. That doesn't run on every 

         machine. Consumes A LOT of space. Well, we're going to CD it...
- TeX/LaTeX:
    pro: Clearly defined standard. Looks good. Most machines can (be made to) 

         read/display it. Searchable in source form
    con: no hypertext capabilities, if it's looking good it's impossible to 

         search
- info:
    pro: hypertext (albeit limited). Runs under emacs (and others). Searchable.
    con: looks ugly. Isn't availlable everywhere. Runs under emacs.
- TeX/LaTeXinfo: (that's a combination of info & TeX/LaTeX)
    pro: see TeX/LaTeX, see info
    con: if looking good there's no hypertext/search. If there's hypertext/search 

         it's ugly.
- MS-rtf:
    pro: Standard format for formatted text on MS-Windows systems. Searchable.
    con: no hypertext, nowhere outside Windows & perhaps NeXT
- NeXT-rtf:
    pro: Standard format for formatted text on NeXT systems, hypertext. 

         Searchable.
    con: nowhere outside NeXTSTEP & perhaps MS-Windows (but then w/out hypertext)
- MS-Windows helpfile format:
    pro: hypertext, searchable
    con: Chris, what is this format? Any chance to use it outside Windows?
- some data base:
    pro: especially good for a discography or suchlike things. SEARCHABLE.
    con: difficult to read on many platforms, difficult to produce nice-looking
         output

Any other good ideas?

Now what about automatic format converters? The rtf formats are quite easy to
interprete and I don't think it would be too difficult to create an rtf->LaTeX
converter. The hypertext links in the NeXT version of rtf are quite easy. 

Just a command giving a file name and a lable. Or a command giving a lable.
Looks like something to feed to makeindex. To produce a plain ASCII document
out of an (NeXT-)rtf document all I have to do is to load the file into Edit
and to press command-shift-R. No problems here (if we are not going to make a few
thousand files ;-) ). Similar with PostScript. Just print-to-file. Command-p 

and >*Click!*<. Now I don't think a converter from NeXT-rtf to MS-rtf should
be too difficult, but it probably is neccessary. Last things that're missing
are the info stuff and MS-W-helpfiles. I don't know much about these. Anyone 

else?

Bye,

m0o0epX-000Nm6C@zoodle.robin.de (That's obviously me... looks like a good .sig!)