(Bill Johnston [csam]) johnston@lbl-csam (02/07/85)
> >Bill Johnston asked about 8-bit serial lines with flow control, and >said that the Apple LaserWriter needs such a protocol. This is not >true. The Apple LaserWriter uses a 7-bit serial protocol, and in fact >the 7-bit characters that are significant to the software are only the >printing Ascii characters and space. It does not use any binary/8-bit >characters or control characters. The data sent to it can contain >format-effector characters like newline and tab, but they are >effectively ignored. > >From: Brian Reid <reid@Glacier> > >[[Editor's note: Fair enough. The general problem still exists, >however, so if anyone knows... --Rick]] I stand corrected. While I have not seen the technical manuals on the LaserWriter, the information that it used 8-bit codes on the serial line came from an Apple technical person who thought he knew what he was talking about. Now that I have read a little about PostScript, I see that the answer is obvious; after all Postscript is a fairly ordinary programming language, the source code of which is passed to the interpreter in the printer controller. (This makes one wonder about debugging. Does the PostScript interpreter pass syntactic and semantic error messages back to the host?) As the editor noted, the 8 bit issue still stands; we have an APS micro-5 which does fit the model in question, as does the HP LaserJet. Several people suggested using litout and -raw, which I agree, from the stty writeup looks like it should work. However, on our 4.2 system, and on it's predecessors, this did not work. Given Chris Torek's piece of code showing the nature of the bug, and the work around as a starting point, I was able to get stty to work as desired. The trick seems to be to do 'stty litout' before you do the stty that you think will work according to the man page. By way of example, the following will permit the HP Laser Jet to accept 8 bit codes (along with 7 bit text) and to flow control the host: (The Laser Jet needs to map lf to cr-lf. The code <esc>&k2G should probably be prepended to each file printed.) stty litout stty litout -raw cat file >/dev/..... #(cat probably won't work on 8 bit files, you will have to use a simpler filter) The following sets one back to 7 bit mode: stty litout stty -litout -raw Thanks for the responses, Bill [johnston@lbl-csam] P.S. After writing this, and before sending it, I got several more responses, at least one of which (Steven Holmes at Purdue) suggested essentially this solution. Van Jacobson at lbl-rtsg pointed out that this is a bug in the distributed 4.2, but many people have fixed the problem on their own. Part of my confusion was due to working on several systems, some of which have the litout problem fixed and some of which do not.
Robert Morris <ram%vax2.uucp%umass-boston.csnet@csnet-relay.arpa (02/08/85)
Yes, the Apple implentation of PostScript, and perhaps other implementations, pass back error messages from the host at least on the serial line. They are only slightly more informative than those from most C compilers (ratifying Reid's recent linguistic analogies) but certainly are helpful if you know what you are trying to accomplish but don't know why it isn't working.
robert@gitpyr.UUCP (Robert Viduya) (02/11/85)
>< Posted from (Bill Johnston [csam]) johnston@lbl-csam > > > cat file >/dev/..... #(cat probably won't work on 8 bit files, you > will have to use a simpler filter) > Huh? Since when does cat not work with 8-bit files? I don't believe cat is documented to be an "only text" file processor. I don't know about other systems, but cat on a Pyramid 90x running 4.2BSD and cat on a 3B2 running System V release 2 both handle binary files. Or is there something I'm missing? robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert