greid@adobe.com (Glenn Reid) (04/30/89)
In article <100@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > . A copy command (or cat, or type, or ...) should not >append anything to a file. It is not their job. These commands have >no way, and should not have any way of telling that you are redirecting >their output to your serial device. Only the user knows this. This is true. A "copy" command should never add anything to the end of the file. However, it is simplistic to treat a printer like a file, especially a PostScript printer. A PostScript printer is a computer, not a file. Here are three reasons why a simple utility program should be used (if you only had one, sigh), rather than "copy": 1. Flow control. Unless you configure your printer for DTR/DSR flow control, or unless you handle XON/XOFF yourself, there will be a practical limit to the size of files you can print without overflowing the communications buffer. 2. Control-D. Somebody needs to signal the end of the file/job. 3. Error conditions. Errors are reported back along the serial connection. If nothing is listening to the serial line, the errors will be lost. It certainly is handy to be able to copy files directly to the serial port. I don't think that any doctrine should tell you not to do that. But is is a quick-and-dirty solution, and not really the best one. You could "cat" files directly to the serial port on a UNIX machine, too, but it is better to use the printer spooling software that comes with UNIX, and it is also easier. It is indeed a problem that smaller personal systems do not come with spooling software or other operating system abstractions that give you a place to put utility programs to do things like this. Glenn Reid Adobe Systems
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (04/30/89)
Not to argue, but: > However, it is simplistic to treat a printer like a file, especially > a PostScript printer. Ah, but the file paradigm is a very nice one for things like printers. (How often I've wished to fopen("|lpr","w") . . .) > Here are three reasons why a simple utility program should be used (if > you only had one, sigh), rather than "copy": > 1. Flow control. Let's not get our levels mixed up. The communication channel is responsible for flow control, not the host application. (Unless you're talking to hardware on an ancient eight-bit PC.) > 2. Control-D. Somebody needs to signal the end of the file/job. This is definitely a valid point. Fclose() works admirably, if it can be arranged. Applications that write the ^D themselves if they are talking directly to a `device' as opposed to a `file' is a reasonble compromise. > 3. Error conditions. Errors are reported back along the serial > connection. If nothing is listening to the serial line, the > errors will be lost. Except, the only reasonably quick way to send files for many of us is via the parallel port (9600 baud? no thank you.) Most PostScript printers that support the parallel port simply don't report errors---even though a parallel port is usually bidirectional. This is a bitch I've got with the vendors, though . . . > but it is better to use the printer spooling software that comes with > UNIX, and it is also easier. Indubitably. On reasonably modern personal computers, such as the Amiga and the IBM PC under OS/2, it is not difficult to write a `PostScript:' device that serves all the functions of the Unix spooling software . . . > Glenn Reid > Adobe Systems -tom
paolucci@snll-arpagw.UUCP (Sam Paolucci) (05/01/89)
In article <798@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: ->In article <100@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: ->> . A copy command (or cat, or type, or ...) should not ->>append anything to a file. It is not their job. These commands have ->>no way, and should not have any way of telling that you are redirecting ->>their output to your serial device. Only the user knows this. -> ->This is true. A "copy" command should never add anything to the end of the ->file. However, it is simplistic to treat a printer like a file, especially ->a PostScript printer. It is not the printer that is treated like a file, but the serial device on the Amiga. This makes it easy and convenient to send a file to anything that is attached to the serial port. ->A PostScript printer is a computer, not a file. Here ->are three reasons why a simple utility program should be used (if you only ->had one, sigh), rather than "copy": -> -> 1. Flow control. Unless you configure your printer for DTR/DSR -> flow control, or unless you handle XON/XOFF yourself, there will -> be a practical limit to the size of files you can print without -> overflowing the communications buffer. This is handled automatically by the serial device. -> 2. Control-D. Somebody needs to signal the end of the file/job. That's the reason why the ^D is appended to the end of the file. -> 3. Error conditions. Errors are reported back along the serial -> connection. If nothing is listening to the serial line, the -> errors will be lost. I usually download at bootup ehandler.ps to the printer to catch those. ->It certainly is handy to be able to copy files directly to the serial ->port. I don't think that any doctrine should tell you not to do that. But ->is is a quick-and-dirty solution, and not really the best one. You could ->"cat" files directly to the serial port on a UNIX machine, too, but it is ->better to use the printer spooling software that comes with UNIX, and it is ->also easier. It is indeed a problem that smaller personal systems do not ->come with spooling software or other operating system abstractions that give ->you a place to put utility programs to do things like this. That is exactly the problem. If OS's for the smaller systems included spooling software we would not be having this discussion. But due to the lack of it, something needs to be done. So we are only arguing on how this is best done. It is easy enough for me to write a script on the Amiga, call it psprint, that does the following: .k file/a copy <file> ser: copy pseof ser: where the file pseof included the single byte ^D. I could then execute the psprint command with "psprint myfile". Now the problem comes when I want to redirect the output of an application program directly to the printer without saving it as a file. Then, in order not to get an EOF timeout from the printer, I still need to "copy pseof ser:". You see that if a ^D is always appended at the end of the application output, the user does not need to distinguish between the cases, and does not need to know anything about PostScript for that matter. Now I know that this will reduce portability, so the user should be made aware that a ^D is appended to the end of the file so that if he wants to move the file to some other system, he should strip it off. Note that this happens a lot less frequently than printing files on a dedicated printer. Furthermore, I do not condone putting a ^D at the end of an EPS file, since such files are usually intended to be part of a larger file. ->Glenn Reid ->Adobe Systems -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
richard@gryphon.COM (Richard Sexton) (05/03/89)
In article <107@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >In article <798@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: >->In article <100@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > >->A PostScript printer is a computer, not a file. Here >->are three reasons why a simple utility program should be used (if you only >->had one, sigh), rather than "copy": >-> >-> 1. Flow control. Unless you configure your printer for DTR/DSR >-> flow control, or unless you handle XON/XOFF yourself, there will >-> be a practical limit to the size of files you can print without >-> overflowing the communications buffer. > >This is handled automatically by the serial device. AHA! The way I hack postscript is to use vi, write what I want, and copy it to the printer. If it doesnt work, and I can't tell why by just looking at the cose, I'd fire up a terminal emulator and see what the printer sent back (no, I didn't know about ehandler.ps) Well this works fine with small files, but when the file got above a certain size, about 150K, a working PS program would not work if I sent it to the printer with a terminal emulator. I *suspect* now, that the comm program was bypassing the serial.device, and not doing any handshaking. The comm program was, I believe, handshake (ho ho ho), and this is *just a guess*. -- ``The way to heaven is through weasel lore!'' - Ted Kaldis richard@gryphon.COM decwrl!gryphon!richard gryphon!richard@elroy.jpl.NASA.GOV