Regular readers of GEOWORLD probably remember the article Accessing Laser Printers, which appeared in this column (March 1988). That article details what I now fondly refer to as the Antigrav method of sending GEOS laser printer output over a modem to a laser printer or a computer connected to a laser printer. For those of you fortunate enough to have access to a laser printer that isn't connected to a Commodore running GEOS, the Antigrav method is a real convenience. It might also be the fastest way to get your GEOS work to a local laser printing service that doesn't use Commodore equipment. At the very least, it eliminates the need to move your Commodore system to another location just to do some printing.
Brian Dougherty, Berkeley Softwork's CEO, doesn't agree one hundred percent. In an interview with GeoSync columnist D. Roderick Eamon, (COMPUTER SHOPPER, September 1988) Mr. Dougherty admits that while the methods are definitely workable, they are both unwieldy and inelegant.
What exactly does that mean? First of all, geoLaser and geoPublaser were never intended to output PostScript files to anything other than a PostScript laser printer. However, it's hardly coincidental that a computer's RS-232 port (the Commodore 64/128 requires an interface) which connects to a laser printer also connects to most modems. That PostScript programs are files consisting only of printable ASCII characters is also not unintentional. Since the pieces fit together so nicely, why blast it?
Continuing with the GeoSync interview, our CEO adds that BSW's new geoTerminal program will handle PostScript program file transfers with greater ease.
That's probably true. BSW's new geoTerminal program might very well be excellent, include a decent manual, support PostScript file transfers, and be reasonably bug free! As the GEOS world continues to turn, I haven't heard anything more about geoTerminal. So, if you need to transfer PostScript files now, don't hold your breath waiting for a chance to stand in line for geoTerminal. Just reread Accessing Laser Printers, and get your files laser printed right away using software and hardware you probably already own.
Unwieldy?
Not too unwieldy, really. The Antigrav method is really just a few more steps than laser printing with a direct Commodore to laser printer hookup.
Almost every modem user has probably transferred files. The only thing unusual about the Antigrav method is that after setting up a file transfer with another computer, you have to exit the terminal program and run geoLaser, geoPublaser, or print a document with the LaserWriter printer driver selected. When that step is finished, it's a decent idea to run the terminal program again and do whatever is necessary to finish up the transfer and log out.
Since I wrote that article way back in March, Bill Coleman has finished his geoTerm (on the GEOS Power Pack from RUN). Although Bill's program doesn't deal with PostScript, since it runs under GEOS it doesn't require booting GEOS before running geoLaser. With the 1750 REU, I can switch between geoTerm and geoLaser in about four seconds.
I've happily laser printed many GEOS documents over the last year and a half using the Antigrav method. It's one of those "computer things" that seem so difficult at first, then, with a little practice becomes routine.
Here comes the part I don't care to mention. The inelegant part.
If this were a perfect world, the Antigrav method would work perfectly every time. Unfortunately, this is not always the case. It used to be mildly distressing to me to find that a file I had transferred wouldn't print. Sometimes it would print, but be messed up in some way. Noise on the phone lines sometimes hits a byte or two along the way, resulting in garbage on the receiving end.
The Antigrav method uses what is known as ASCII protocol. It is more like a "dump some characters on the line and hope" protocol. geoLaser sends characters to the modem, and if they don't get to their destination, then too bad.
Typical file transfers, such as those done with XMODEM or Punter, use some form of error checking protocol. An error checking protocol sends a file in small parts. Both the sending and receiving computers do calculations on the part just sent, then compare results. If the results on both ends don't match, that part of the data gets resent until both ends agree.
There are some powerful concepts involved in error checking protocols. Although the Antigrav method doesn't do any error checking, some of these concepts can still be applied, but you'll be responsible for doing it yourself.
Essentially, all error checking methods rely on probability. Even with XMODEM or Punter, it is still possible to get bad data that will fool the protocol to accept it. Common sense probability says that chances are the protocol won't accept bad data.
First lesson: break the file into small parts. If you want to transmit a nine page geoWrite file, do it one page at a time, as nine separate transfers. This requires a little more work, and the receiving computer will have nine files instead of just one. If just one byte gets garbled, you'll still end up with eight good pages. You'll have to resend only the bad page.
Suppose the phone lines act up a little more than you hope they would. You might want to be reasonably sure that everything you send makes it without errors. The simplest solution is to send the file the file twice. Assuming the phone lines aren't always perniciously against you, one of the copies is bound to be alright. It's because the probability is slightly in your favor.
There are, however, even more elegant solutions. The next two methods, although similar to the previous one, tip the odds even more in your favor.
One method I often use is to send the file twice. Following the transfer, I compare the sizes of the two files. If they are both the same number of bytes in length, it's a good indication that I didn't loose or gain any bytes during the transfer. Both files are probably alright. If the sizes don't match, I send another copy of the file and again compare sizes until two copies do match.
To use this method, you'll need some way of checking file sizes. On many of the systems to which you might send a PostScript file, a directory listing of the files will display file sizes in bytes. Failing that, you might be able to remotely run a program that will provide file size information. If there is someone attending the machine you are uploading to, they might be able to tell you the file sizes.
The next method provides even greater accuracy. It is almost identical to the previous method, except that instead of comparing the sizes of two files, the two copies are compared byte for byte. Utilities to compare two files often have names like COMPARE or DIFF. Again, as in the previous method, the goal is to get two copies of the file which agree with each other.
A major benefit of using a file compare utility is that even if one of the files is bad, often it can be determined which copy is bad. For example, suppose the compare utility reports the following:
Line 335 in file GEOTEST1.PS :
showpage
Line 335 in file GEOTEST2.PS :
sho@pa#eThe word showpage is a common PostScript operator. It's pretty obvious which file has the error. In the rare case that both files have errors, if the errors are glaring enough, some quick editing might straighten out the least of the two damaged files. The more familiar you become with PostScript, the easier it will be to fix such problems.
Now chance can be replaced with certainty. Use the Antigrav method. There's no longer any reason to feel you've done something inelegant. Please excuse me now while I catch up on some laser printing!
I enjoy your mail. If you have any questions or comments, please write.
Randy Winchester
P.O. Box
426074
Cambridge, MA 02142