Re: can't print from acroread

[peanut butter <pyeatman@cass20.ucsd.edu>]

Hi, everyone.  The problem I was having mid March is finally solved.  I
started this thread on Mar 16 having the problem of, though being able
to print fine from the command line, not being able to print internally
from applications such as acroread.  Though this problem (which appears
to be related to the printer filter I was using with lprng) was never
solved itself, I, for another reason, switched over to using the
printer filter provided by a program called 'ifhp' which uses the lprng
spooler.  Other than simply being better than the filter I was using
previously, it also "magically" fixed the problem I was having of not
being able to print from within various applications.  Possibly this
may also help someone else experiencing similar problems.

Paul


->>In response to your message<<-
  --received from Erdmut Pfeifer--

> 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 ;)