Michael Loßin on Thu, 17 Jan 2002 13:04:23 +0100 (CET)(envelope-from owner-apsfilter-help@apsfilter.org)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: 4.4R: if: doesn't get started when getting remote print job


On 16-Jan-02 Christian Ullrich wrote:
> * Christian Ullrich wrote on Wednesday, 2002-01-16:
> 
[...]
> 6. I added the above line "filter_stderr_to_status_file" to
> /etc/lpd.conf.
>    This file had not existed before. I restarted lpd.

Argh... By mentioning "/etc/lpd.conf" I meant "whatever the
correct config file for LPRng is"... I just hope it *really*
is /etc/lpd.conf (you should at least see /etc/lpd.conf.sample
if the path is correct).

> 9. More stairs. Does someone know any skyscrapers in lack of stairs?
> 
> 10. status still empty, status.ascii 4947 bytes. See below.

I'm afraid /etc/lpd.conf was not the correct path... Otherwise
"status" would consists of the pure apsfilter error log
messages (just "+ WIDTH_POINTS=595" etc. instead of all the
date/time stuff).
Maybe it's "/usr/local/etc/lpd.conf" on your machine.

> -- 8< -- /var/spool/lpd/ascii/status.ascii -- >8 --
> 
[...]
> IF filter 'apsfilter' filter msg - '+ print_raw' at
> 2002-01-16-19:54:30.360 ## A=chris@christian+454 number=454
> process=82735

There it is... "print_raw" is called, so there will be no
automatic file conversion.

Now all we have to do is find out why apsfilter does that:

1) There's a "METHOD=raw" setting in one of the configuration
   files -- not likely, given that you created the "ascii"
   queue the way you described.

2) You give the "-b" or "-l" options to lpr -- please tell me
   that you don't... :^)

3) The spooler includes "-c" as one option for the input
   filter, thus overriding the METHOD=... default (this is what
   I guess). Unfortunately, the log does not include the argument
   parsing section, but let's just suppose this to be true.

However, there's no logical reason for the spooler to do that
by default, since a printer server is supposed to call the
filter in any case...

I checked with LPRng 3.8.4 and could not recreate this error
situation. I just hope it's not a problem with SuSE<->FreeBSD
interconnection... :)


Michael