Welcome to iraf.net Friday, May 17 2024 @ 11:26 AM GMT
Anonymous: Guest |
03/07/1991 03:51PM (Read 143 times)
|
|
|
|
Hi Mike, I agree, the problem is with the printer setup. Was anything useful
written to the log file /usr/adm/lpr-errs? It may be a problem with the
size of the postscript and that fact that this is a remote printer. Here
at NOAO, we had to specify mx#0 in the /etc/printcap file for remote printers
or the spooled file would get truncated at 1MB. I doubt that this is your
problem since your postscript file is less than 1MB. Also, we'd get an
error indicating an incorrect postscript command, which would be expected
if the file was just truncated at the mx limit. Here is a working
/etc/printcap entry for a remote NOAO printer:lp|lp0|lw|lw1|ps|postscript|PostScript:\
:lp=:sd=/usr/spool/lw:mx#0:rm=orion:rp=lw:
To help debug this, trap the PostScript file and then try to print
it in various ways from UNIX. There are several ways to save the PS file,
it might be easiest just to remove the -r argument from your R_DISPOSE
string. You can also watch the /tmp area for the temporary PostScript file
and put in a hard link to the file before the lpr command has a chance to
remove it. In the CL, you can use the device name "psdump" which leaves a
PostScript file in the /tmp area and does not dispose it to a physical
device. You can use the psdump device name with the interactive cursor
command (".snap psdump") or with any task that has a parameter to specify
the output device name ("cl> contour dev$pix dev=psdump"). Of course, you
can examine the PostScript created by either of these methods to look for
anything suspicious. (Note that IRAF PostScript files are encoded as
described in the source file iraf/unix/gdev/sgidev/sgi2uapl.c). I hope these ideas help you find the problem.Suzanne
|
|
|
|
| |
|