Ok, here's some preliminary information to this problem I'm still
experiencing with a pdf not printing from the acroread
application.
Erdmut Pfeifer gave an excellent suggestion below to which I dedicated
a few hours. In short: make a script that gets executed as the
the "print command" from within acroread. The script ls's the temp
file that acroread creates and sends to the "print command", copies it
to a non-automatically-deleted file, tries printing the temp file
itself and catches the return code from lpr.
Here's some inital results:
The script works beautifully although the print fails just as well when
executed by the script as when by a typical print command both from
within acroread. Indeed the status of the failed print command is
captured though only offering, in my knowledge, a very vague return
status of 255. To un-vague-ify this as best I could, I made one
significant addition to the script of adding the -D5 option of lpr to
offer verbose debugging information. This finally starts to get me
somewhere but not so far as to completely understand and solve the
whatever's really going on.
To really simplify things while exposing the basic problem, I saved the
pdf from acroread as a postscript file. I then wrote one script that
prints this postscript file with the lpr -D5 option saving the output
to one file while recording the returned status from lpr to another. I
then ran this exact same command once from the command line and once
from within acroread. Now, mind you, the script accepts no input
arguments . . . so the execution of the script is exactly the same,
printing the exact same postscript file, while printing correctly from
one execution (command line) yet not from the other (acroread).
I can offer the full debug report from either or both runs to anyone
who should care to view it/them but in attempt to keep things as concise
as possible, just below is the segment from both reports where they begin to
deviate.
Notice in about the middle of the segments (sixth line), there is a
line that reads ". . . lpr lp: plp_waitpid: report . . . ". In the
bad report, "report" is followed by "-1". In the good one, "report" is
followed by the PID (what I suppose is a child process of lpr)
mentioned on the line just before it. In the failed print case, things
go bad from here onward and shortly end while things continue on
another 80,000 lines or so in the successful print case. The
unfortunate thing is that this doesn't tell me much. I'm hoping it may
say something more to one of you likely more knowledgeable people on the
list.
---------------------------------------------------
lpr debug report from script when run from acroread
---------------------------------------------------
.
.
.
2001-03-23-12:32:19.397 isengard [6420] lpr lp: Write_outbuf_to_OF: read
status 0, read 0, ''
2001-03-23-12:32:19.397 isengard [6420] lpr lp: Write_outbuf_to_OF: no more
reading
2001-03-23-12:32:19.397 isengard [6420] lpr lp: Write_outbuf_to_OF: waiting 0
secs for pid 6422, suspend 0
2001-03-23-12:32:19.398 isengard [6420] lpr lp: Wait_for_pid: name 'IF', pid
6422, suspend 0, timeout 0
2001-03-23-12:32:19.398 isengard [6420] lpr lp: plp_waitpid: pid 6422, options
2
2001-03-23-12:32:19.398 isengard [6420] lpr lp: plp_waitpid: report -1, status
exit status 0 (JSUCC)
2001-03-23-12:32:19.398 isengard [6420] lpr lp: Wait_for_pid: pid -1 exit
status 'exit status 0 (JSUCC)'
2001-03-23-12:32:19.398 isengard [6420] lpr lp: Wait_for_pid: returning
'UNKNOWN STATUS '-1'', exit status 'exit status 0 (JSUCC)'
2001-03-23-12:32:19.398 isengard [6420] lpr lp: setstatus: IF filter problems,
error 'UNKNOWN STATUS '-1''
2001-03-23-12:32:19.398 isengard [6420] lpr lp: Add_line_list: 'IF filter
problems, error 'UNKN...', sep '<NULL>', sort 0, uniq 0
2001-03-23-12:32:19.398 isengard [6420] lpr lp: cleanup: signal No signal,
Errorcode -1, exits 1
.
.
.
------------------------------------------------------
lpr debug report from script when run from commandline
------------------------------------------------------
.
.
.
2001-03-23-12:31:23.605 isengard [6409] lpr lp: Write_outbuf_to_OF: read
status 0, read 0, ''
2001-03-23-12:31:23.605 isengard [6409] lpr lp: Write_outbuf_to_OF: no more
reading
2001-03-23-12:31:23.605 isengard [6409] lpr lp: Write_outbuf_to_OF: waiting 0
secs for pid 6411, suspend 0
2001-03-23-12:31:23.605 isengard [6409] lpr lp: Wait_for_pid: name 'IF', pid
6411, suspend 0, timeout 0
2001-03-23-12:31:23.605 isengard [6409] lpr lp: plp_waitpid: pid 6411, options
2
2001-03-23-12:31:23.606 isengard [6409] lpr lp: plp_waitpid: report 6411,
status exit status 0 (JSUCC)
2001-03-23-12:31:23.606 isengard [6409] lpr lp: Wait_for_pid: pid 6411 exit
status 'exit status 0 (JSUCC)'
2001-03-23-12:31:23.606 isengard [6409] lpr lp: Wait_for_pid: IF filter exited
with status 0
2001-03-23-12:31:23.606 isengard [6409] lpr lp: Wait_for_pid: returning
'JSUCC', exit status 'exit status 0 (JSUCC)'
2001-03-23-12:31:23.606 isengard [6409] lpr lp: setstatus: IF filter finished
2001-03-23-12:31:23.606 isengard [6409] lpr lp: Add_line_list: 'IF filter
finished', sep '<NULL>', sort 0, uniq 0
2001-03-23-12:31:23.606 isengard [6409] lpr lp: Init_buf: buf 0x8085788, max
10240, len 0
.
.
.
The only other difference to note between the two debug reports is the
repeated difference in the following, repeated occurence:
---------------------------------------------------
lpr debug report from script when run from acroread
---------------------------------------------------
.
.
.
2001-03-23-12:32:17.696 isengard [6420] lpr lpr: after init open fd's
2001-03-23-12:32:17.696 isengard [6420] lpr fd 0 (020000)
2001-03-23-12:32:17.696 isengard [6420] lpr fd 1 (0100000)
2001-03-23-12:32:17.696 isengard [6420] lpr fd 2 (0100000)
2001-03-23-12:32:17.696 isengard [6420] lpr fd 3 (020000)
2001-03-23-12:32:17.696 isengard [6420] lpr fd 4 (0100000)
2001-03-23-12:32:17.696 isengard [6420] lpr fd 5 (0100000)
2001-03-23-12:32:17.696 isengard [6420] lpr fd 6 (0100000)
2001-03-23-12:32:17.696 isengard [6420] lpr fd 8 (010000)
2001-03-23-12:32:17.696 isengard [6420] lpr Get_printer: original printer
'<NULL>'
.
.
.
------------------------------------------------------
lpr debug report from script when run from commandline
------------------------------------------------------
.
.
.
2001-03-23-12:31:21.919 isengard [6409] lpr lpr: after init open fd's
2001-03-23-12:31:21.919 isengard [6409] lpr fd 0 (020000)
2001-03-23-12:31:21.919 isengard [6409] lpr fd 1 (0100000)
2001-03-23-12:31:21.919 isengard [6409] lpr fd 2 (0100000)
2001-03-23-12:31:21.919 isengard [6409] lpr fd 3 (020000)
2001-03-23-12:31:21.919 isengard [6409] lpr fd 4 (020000)
2001-03-23-12:31:21.977 isengard [6409] lpr fd 5 (0100000)
2001-03-23-12:31:21.919 isengard [6409] lpr Get_printer: original printer
'<NULL>'
.
.
.
Actually, in the commandline case, the first occurrence only goes fd
0-4, all following ones are fd 0-5. It is always fd 0-8 in the
acroread case.
Thanks to anyone who made it this far!! Very apologetic about the size.
Paul
->>In response to your message<<-
--received from Erdmut Pfeifer--
.
.
.
>
> Perhaps you might want to try the following to get some more information:
>
> Write a shell script something like
>
> #!/bin/sh
> ls -l $1 >/tmp/acroprint-debug.$$
> cp $1 /tmp/acroprint-out.$$
> /usr/bin/lpr -P<printer> $1 # substitute your printer here
> echo $? >>/tmp/acroprint-debug.$$
>
> (the .$$ are not required, they just create a seperate pair of files
> for each try, with the PID appended)
>
> and run this instead of the /usr/bin/lpr from acroread's print dialogbox
> (e.g. Printer Command: "/home/name/test-print" -- no further options)
>
> This should
>
> (a) give you some info about the temp-file that acroread creates (-> ls)
> (b) copy the temp-file to a safe place, before it gets deleted (-> cp)
> (c) try to run the actual print command -- maybe it works from here
> (d) capture the return code of the print command -- should be 0 if OK
>
> Then you can also compare the /tmp/acroprint-out with the file you
> created when printing directly to a file from within the dialogbox.
> I guess both files should be identical.
>
> Also, feel free to add other debugging commands you could think of
> to the script...
>
>
> Don't know whether it helps ;)
> Erdmut
>
>
> --
> Erdmut Pfeifer
> science+computing ag
>
> -- Bugs come in through open windows. Keep Windows shut! --
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
Paul Yeatman (858) 534-9896 [EMAIL PROTECTED]
==================================
==Proudly brought to you by Mutt==
==================================
