iraf.net

Hi Henry,
Try using the 'psdump' device to produce a /tmp/irafdmpXXXX
(where XXXX is some pid) file. This uses the same sgi2uapl translator
to produce the postscript. If that works try prompt% cat /tmp/irafdmpXXXXX | lpto see if you get a print (i.e. simulate the DD string by hand). If
that fails, the PS generation works but the printer doesn't like the
resulting file. This is possible since that translator uses a simple
"%!PS" prefix and some printers want "%!PS-Adobe-something". You might
instead try the sgi2ueps translator in place of sgi2uapl to send EPS.Cheers,
-Mike
On Tue, 29 Nov 2005, Henry Leparskas wrote:> Hi Mike,
> I'm at home now, but should add that the attempt I made that is
> refered to below caused a core dump each time it was tried.
> That's probably significant.
>
> I always do a gflush, but because I am superstitious I exit 'cl' and
> reenter every time I try a new graphcap 'stdplot' setting.
>
> Yes, both of our printers work just fine for the 'lp' command at the unix
> level. I have the 'tek' priter set as default for both unix lpr (via
> the PRINTER variable) and for unix 'lp' via the LPDEST variable (both in
> the '.cshrc' file, and not '.login'. So by
> leaving out the destination printer in the pipe command, I was hoping it
> would go to 'tek'. Hmm, I recall that I did make one try at setting it
> explicitly to 'lp -d tek' with no success.
>
> Could it have something to do with the sgi device I am trying to use. Is
> it possible to try another one other than 'sgi2uapl'? Is there a way I
> would know that the executable for these drivers is okay?
>
> Thanks,
>
> Henry