jpc@avdms8.msfc.nasa.gov (J. Porter Clark) (05/14/91)
I've got a Sun 3/470 connected (somewhat circuitously) to an HP LaserJet II printer. I can print just fine from the Sun to the LJ II using lpr. The lpr which comes with CUTCP v2.2-D apparently doesn't pass 8-bit binary data to the Sun, though. I know this because I can install a temporary print filter which copies the data to a disk file, and data sent from CUTCP's lpr has been mangled whereas data sent from another Sun has not. Is there some way to make CUTCP's lpr send print data to the Sun unscathed without trying to convert end-of-lines, intercept control-Z's, etc.? There are apparently some undocumented options to CUTCP's lpr, such as -l, and I think I've tried every combination, but so far nothing has worked. Is source code for the CUTCP lpr available. (Silly question, probably.) FLAME ON I've had similar problems with various network printing utilities in the past. I wish people who create these things would allow for those of us who have to use binary data in print jobs and don't need to count cents per page or convert end-of-lines from one host's convention to another. IMHO, it's a poor application that doesn't put the data in the right format to begin with. To me, print data is data and doesn't have to be re-interpreted by every network node in the system. BTW, this is hardly a UNIX-specific problem--VMS has all sorts of pitfalls for the unwary in this area. FLAME OFF -- J. Porter Clark jpc@avdms8.msfc.nasa.gov
larsm@europen.cs.uit.no (Magnussen Lars) (05/23/91)
In article <jpc.674232381@avdms8.msfc.nasa.gov> jpc@avdms8.msfc.nasa.gov (J. Porter Clark) writes: >I've got a Sun 3/470 connected (somewhat circuitously) to an HP >LaserJet II printer. I can print just fine from the Sun to the LJ II >using lpr. The lpr which comes with CUTCP v2.2-D apparently doesn't >pass 8-bit binary data to the Sun, though. I know this because I can >install a temporary print filter which copies the data to a disk file, >and data sent from CUTCP's lpr has been mangled whereas data sent from >another Sun has not. ........ For many european this is a continous problem. This problem does not limits to lpr but also to the telnet included in the package. A swedish guy at Chalmers Univ. of Technology have patched the bracets and so on to show the umlaut ae, aa, and oe. So You who develop for PC (CUTCP or not), try to use 8-bit libraries and dont filter all above 127 but allow for all 256 chars to pass. Also look at IBM/others info about national code pages. You don't have to hardcode for european keyboards, simply allow for the codes to pass through, and let our keybord-drivers woork as they should. 8-bit lib's are standard at least for MS, Borland & Zortech. > >Is source code for the CUTCP lpr available. (Silly question, >probably.) > Probably not, since there has been complaint about this before, maybe in the nfs conference ............ >J. Porter Clark jpc@avdms8.msfc.nasa.ye.gov By the way, in an early release of one of the TCP-packages, there was an rsh, with a rather poor performans (ex. no redirection from either side and no flag for "automated" work like lpr). Have there come out any newer,better versions , that fx. could work with a trusted hosts- file. AT&T had a uexec that allowed doing many nice things from MessDos. Fx. reading mail and news in PC-enviroment. Would like to do something like it with the Clarkson stuff. Does anyone news if the code to these early programs is around. Please answer by mail to lmag@z.amu.se Lars M -------- tmp EurOpen footer ------- Lars Magnusson AMU Jamtland, Dept. of Computing lmag@z.amu.se ----------------------------------