mwm@eris.berkeley.edu (Mike Meyer) (10/03/86)
Having finally gotten around to my hypertext system for the Amiga, I took a look at the IFF FTXT format dated November 1985. It looks like just what I want for representing the textual part of the hypertext. However, I also need to put in the cross-document links. There's nothing there to do this. So... Is there a later IFF FTXT document that includes program-specific chunks? Or maybe an more complete IFF document (covering things other than FTXT, graphics and sound)? More importantly, how do I get copies of the most recent IFF docs? Thanx, mwm@berkeley.edu, ucbvax!mwm <mike
hadeishi@husc4.harvard.edu (mitsuharu hadeishi) (10/04/86)
If you need specific program-oriented chunks, you can make up your own chunk and "register" it with Commodore-Amiga. A good thing to do first is check with C-A to see if someone else has already defined what you need. If what you want is a fairly general idea, its a good thing to contact C-A first and to make your chunk definition as general as possible so many other people will be encouraged to use it. IFF was made to be extensible; you should take advantage of this design. An editor which is truly IFF-compatible should be able to read your FORM FTXT and ignore the extra chunk(s); this is what is meant by an IFF-reader; it can read what it understands and skip over what it doesn't. A good example of this is the Mandelbrot Set Explorer. MSE writes an IFF FORM ILBM which can be read by DPaint; however it includes extra information about the region (in the complex plane) the picture is an image of. This information can be read and understood by the MSE but not by DPaint; DPaint reads the image and discards this information. If you edit the file and subsequently write the file to disk from DPaint, that information is lost; this is well and good, however, to prevent programs from writing gibberish (since DPaint knows NOTHING about the contents of that chunk, it doesn't write it back out again.) At this juncture I would like to make a call for C-A or some programmer's group of SOMEBODY to come up with a good, well-thought-out standard for sharing clipboard.device information. I mean a WELL THOUGHT OUT standard, perhaps something that could even someday support "hot" links between concurrent applications, or something which could support real-time links between concurrent applications (similar to pipelining). IFF should be a part of this standard, defining the data, but C-A should make an effort to STRONGLY ENCOURAGE people writing software NOW to adhere to some sort of convention for sharing data and data streams between programs. At least the clipboard's cut/paste ability should be better documented, and perhaps an AmigaDOS device driver written to ease access to the device (i.e., so you could just Open() and Close() the device and read/write to it like a RAMdisk file.) Data standards could include plain Amiga console.device text, FORM FTXT formatted text, FORM ILBM images, or perhaps the standard should simply be "what's on the clipboard will be either raw text, raw image data, or an IFF file." This could certainly be done by saving IFF data to the RAMdisk, going to the other program, and loading from the RAMdisk, but this seems like an awful waste of time (and counter-Intuitive.) We should be able to just cut, for example, a brush from DPaint and immediately move it into Images without having to go through saving the thing to disk first. I mean, look guys, we have a bunch of fine quick-and-dirty tools and applications ported from other environments. Now is the time to start thinking about how we can make life better for the rest of the world, by supporting these things (read: clipboard and pipelining.) True, there are a few text editors that use the clipboard, but they are frequently awkward (i.e., selecting and cutting text is rather awkward). But, actually, I have to say that IFF has made life so much better for us Amigans that I should be thankful that we at least have this extensible data standard to work with. Now lets see some people really put this standard to work! -Mitsu