Whatever the excuse, our last issue was plagued by error daemons. Unlike our more staid, paper-based counterparts, when we make a mistake, we admit it freely and explain the problem. No one's perfect and the weekly deadline doesn't leave much time to check facts and fiction. In light of last weeks problems, this week seems like a good time to acknowledge and correct errors from previous weeks.
Some time ago we accidentally released the article "Electronic Jabberwocky" (on getting the electronic version of the Alice in Wonderland books via FTP) with a typographical error. The address should be mrcnext.cso.uiuc.edu, not email@example.com. Our apologies to those of you who have been frustrated by our mistake.
In the continuing confession series, we've received two complaints about TidBITS-042, our special issue on compression programs. First, we failed to include contact information. Sorry about that. Second, the tests focussed on the compression times, but failed to mention the equally as important expansion times. We're working to rectify these oversights and will release that issue again in a week or so when everything is complete. There will be no change in issue number. If you've been archiving the issues, go ahead and delete the old items from your TidBITS Archive, then merge the new issue. If you have added this issue already, it will be slightly out of order, but no problems will arise from that. Waiting to merge this issue will ensure no gaps in your archive.
"ADB Oddities" and "GO's Green Light" both invoked the TidBITS error handlers. In "ADB Oddities" we talked about problems with typing certain key combinations on Mac keyboards. This isn't exactly a bug, but it is a design trade-off. Apparently, most, if not all, keyboards (the problem can occur any computer system) use a matrix to reduce the number of leads that must lead into the keyboard microcontroller. With 105-key keyboard, you would need close to 105 leads going into the microcontroller (the modifier keys don't count in the same way). Most companies, including Apple, organize the keyboard so that four keys share a lead, and are organized into a 2 x 2 matrix on their own. So the problem with typing "out" and getting "ou;" comes about because "o," "u," "t," and ";" are all in the same 2 x 2 matrix. When the first two keys are down, the controller can't distinguish between the other two, and probably picks more or less randomly. "But I'm not holding down both keys at once," you say. That's true, except when you type very quickly, at which point the controller can't tell the difference. The reason more problems don't stem from this design is that the controller can record the keystroke on keyUp, which will be more distinct. If you want to play with this stuff, try holding down several keys at once in KeyCaps.
With "GO's Green Light," we made one mistake and one omission. Our mistake, obviously caused by youth and inexperience, was saying that GO's Embedded Document Architecture was radically different from existing operating systems. Sak Wathanasin pointed out that the Xerox Star operating system did precisely this, allowing the user to include different types of data in a single document and have the appropriate tool be available when the chart or text was appropriately selected. I'd love to get my hands on a Xerox Star sometime. I would also like to ask an obvious question. How in hell did Xerox bungle this computer!?! It seems that only after a number of years have companies managed to pull themselves back up to the level of the Star in many respects. Sak also mentions that while handwriting is slow, shorthand is much faster and could be used for fast text input on a handwriting system. Of course, you have learn shorthand, but if it's speed you crave...
The data that we omitted from the GO article was the contact information, not for any malicious reason, but simply because none of our sources listed it. We do have it now, so here it is.
950 Tower Lane, Suite 1400
Foster City, CA 94404
Sak Wathanasin -- firstname.lastname@example.org