Re: can't print from acroread
On Fri, Mar 23, 2001 at 01:20:10PM -0800, peanut butter wrote:
>
> (...)
>
> 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).
good idea...
> 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.
thanks for the clear report. From this debugging information and a
quick look at the lprng source, I would say that the problem occurs
while trying to fork/exec the so-called "input filter", though I do not
yet have a clear idea why it fails...
The waitpid(2) call returns a "-1", which indicates that the waitpid
failed. Actually, there are three error/return codes involved here: the
exit code of the waited-for child process (the filter), the return code
of the waitpid function itself, and in case the latter returns -1, the
"errno" being set by waitpid, which _might_ provide further details on
what went wrong (not sure whether it really would in this case, though).
Unfortunately, this error number doesn't seem to make it to the
debugging logs (or else we should see another diff) -- the "-1" appears
to be propagated to the logs instead. Although it would generally be
easy to add another printf() to the lprng code, outputting the errno, I
assume that you would rather avoid having to recompile the code and
having to make sure that the modified version gets installed in the
appropriate place. I guess we should do things like these as a last
resort only.
Instead we might try to apply the same "wrap a script"-technique here
as well, by substituting a script for the filter program run by lprng.
The script could output a few interesting things like command line
args, environment, the errno in question, etc. before/after running the
filter... There is a faint hope that something will differ here... :)
First, however, I'd like to take a look at the full logs available
already, so feel free to send them to me privately. In particular, I'm
not sure yet as to how the other diff (the fd-0..5 vs. fd-0..8 thing)
is related to the waitpid error ocurring later on. Maybe that is the
real place where things start to go wrong. The complete logs will make
it easier to dig through the appropriate portions of the source.
Also, I'd like to take a look at your printcap file (especially the
"if"-specification which is in effect for the printer in question), so
be sure to attach that as well. BTW, which printer are you using -- is
it a native postscript printer, or are you using ghostscript as a
filter?
If you haven't done so already, you might also want to try to run your
test script from the command line but in the background. This might
help to rule out issues with a controlling terminal being required by
the filter. Don't know why it would need one, but who knows ... just
an idea.
Erdmut
PS: I cannot promise to be able to take a closer look at this immediately,
but I _will_ as soon as time permits. After all, getting a deeper
understanding of the lprng mechanics might help me to eventually solve
a somewhat similar problem I'm experiencing myself sporadically ;)
--
Erdmut Pfeifer
science+computing ag
-- Bugs come in through open windows. Keep Windows shut! --
Reply to: