clive@drutx.ATT.COM (Clive Steward) (02/27/88)
From article <18323@topaz.rutgers.edu>, by webber@topaz.rutgers.edu (Webber): Well, I seem to remember Bob Webber being the person who went to the trouble to port the appropriate FidoNet to form the net.handicapped newsgroup. Makes me wish to see through the (does it have to be so usual) net.invective on both sides here. So Hypercard contents are readily translated to and from Unixbased/other database compatible formats. In principle. And it's a principle many of us very truly are interested in, in fact in finding ways to make practical. If you feel strongly about this, Bob, how about writing a prototype of a practical compatibility processing system. It would be interesting, I think. And certainly a very constructive move for the philosophies you're espousing. Two shareware ($10) programs might help. Scriptware Detective converts scripts to readible objects, hexified where text won't work. Script Report is a stack which extracts the scripts out of any stack. I tried something with them. Ansel is a pretty interesting and well-done biographical hypertext document for Ansel Adams. It's 94k long, and has 3 (only) pictures, counting the 1/3 page smiling Mr. Adams on the first card. Script Report says the scripts to do this are 17k long; it's a version of the Xreftext method. Let's think about what this means. It takes 17k to describe the unique linkage between information on this stack. A conversion would have to replicate a largish subset of Hypertalk language to know what it means. Then translate to something meaningful, in a way that another hyper text/image system could use. This linkage description would be arbitrarily different for most any other stack. Further, let's consider the information that's linked. Yes, there are others writing image compression algorithms, but Bill Atkinson's not exactly a slouch. This stack appears to the user as mostly text; its information is; about 20 screens. The 2-1/2 screens of pictures, though, I would estimate take up between 1/4 and 1/2 of the 94k, in their compressed form. Most PD database stacks are much heavier on the pictures, and seem to run to 250k or so; a bit under an hour's download time on public nets at 1200 baud. Many are longer. This compressed imagery must be decompressed, and then translated to the system we want to get to. Along the way, it's much bigger, at the least. My first conclusions seem to be that HyperCard may be a very reasonably efficient format to simply pass the information 'the world' may be interested in. If that's accepted, then there's also an existence proof that a reader of such material isn't an impossible task -- there's a commercial DA (small, surely < 100k, Mac program) available that does a reportedly not too complete job of reading stacks. So maybe we should concentrate on building conversion programs, if it's accepted that Usenet should be used at all for transferring such high-context information. Is that, perhaps, the real question of the debate? If so, let's say so. If not, let's throttle stacks, like anything else of size, and see what we can do with them. I personally agree with the throttling, (which we call here, approriately enough for a smile, moderation), especially considering the size. And perhaps commercial bbs's are exactly the right place for the idiosyncratic nature of many of the stacks I have seen. It's a lot of info, and costs to send. If so, let's say so. Clive Steward
webber@athos.rutgers.edu (Bob Webber) (02/28/88)
[The bottom line of this message (for those who don't want to process this text sequentially) is that information should not be distributed on the net in a format that is not publically documented.] In article <6848@drutx.ATT.COM>, clive@drutx.ATT.COM (Clive Steward) writes: > Well, I seem to remember Bob Webber being the person who went to > the trouble to port the appropriate FidoNet to form the net.handicapped > newsgroup. Makes me wish to see through the (does it have to be so usual) > net.invective on both sides here. Nope. Someone else gets credit for the port. However, since chuq and I have been bumping into each other for over a year on the net, doubtless we are both evolving discussion contexts that aren't shared with many readers. > ... > If you feel strongly about this, Bob, how about writing a prototype of > a practical compatibility processing system. It would be interesting, > I think. And certainly a very constructive move for the philosophies > you're espousing. True. Except for two things. One: I am working on an alternative more open system that will be evolving in alt.hypertext. Two: I prefer not to work in the restrictive environment of a Mac (its alot easier to prototype on a system where you can flip back and forth between shell scripts, awk, common lisp, C, and run GNU Emacs). > Two shareware ($10) programs might help. Scriptware Detective converts > scripts to readible objects, hexified where text won't work. Script > Report is a stack which extracts the scripts out of any stack. Both of these would indeed be useful (since I so far have seen no documentation on the hypertext binary format -- indeed recall rumours of it being proprietary). However, as mentioned above, I am really not interested in being Mac-bound. As soon as there is a way of getting the data in a readable format, I will be happy to write whatever conversions are necessary to make the data useable off a Mac. > Further, let's consider the information that's linked. Yes, there are > others writing image compression algorithms, but Bill Atkinson's not > exactly a slouch. I have heard only good things about his programming. However, the Mac has been haunted by resolution dependent graphics for quite some time and the observation that this is not a good design decission is not unique to me. It is understandable that some things would be implemented that way simply because it is easier and the system is already getting too messy. But it is ironic that a system that organizes data in such a fexible way uses such a flat representation for the image data of a given card (doubtless one thing encouraging people to use foreign code to generate imagery). Also, for anything other than raw scanned data, object-oriented representations will be much more compact. > So maybe we should concentrate on building conversion programs, if > it's accepted that Usenet should be used at all for transferring such > high-context information. > > Is that, perhaps, the real question of the debate? If so, let's say so. While I disagree that conversion programs are the only way to produce stacks that are usable on non-Mac systems, clearly they would make it easier to create such stacks. The problem is that the person who writes such a conversion program would have to have sufficient knowledge and access to the Mac as to not need such a program. > And perhaps commercial bbs's are exactly the right place for the > idiosyncratic nature of many of the stacks I have seen. It's a lot of info, > and costs to send. > > If so, let's say so. Personally, I think that once someone has gone to the trouble of organizing a significant body of knowledge in a stack and is willing to make it freely available, it should be distributed as maximally as possible. It should not be distributed in a publically undocumented format anymore than the net should be used for passing around DES encrypted versions of unix source. ------- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)
jac@steppenwolf.rutgers.edu (Jonathan A. Chandross) (02/29/88)
The point was made several times about "the hypercard is graphically oriented, and this precludes portability." Something has been overlooked in all the discussions: postscript. Postscript is not only portable, but interpreters exist on a wide variety of machines. This hypothetical Mac to postscript converter need not be terribly efficient - i.e. large, slow programs are acceptable. It just has to work. This converter would seem to be fairly easy to write given a description of how the stacks store images. Sound is a totally different matter. But I don't think not having sound facilities would render a the hypercard stacks completely useless. Maybe now is the time for an portable music format which functions analogously to postscript. This would take care of machines which have sound capability like the Mac, Atari, Apple ][ GS, and Amiga, to name a few. Jonathan A. Chandross ARPA: jac@paul.rutgers.edu UUCP: rutgers!jac@paul.rutgers.edu