Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #181706 > unrolled thread

HP CP1215 - CUPS not printing from Stretch to Jessie server.

Back to article view | Back to linux.debian.user

Contents

  HP CP1215 - CUPS not printing from Stretch to Jessie server. Gary Dale <garydale@torfree.net> - 2017-06-02 23:30 +0200
    Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Gary Dale <garydale@torfree.net> - 2017-06-03 05:30 +0200
      Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Curt <curty@free.fr> - 2017-06-03 10:00 +0200
        Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Brian <ad44@cityscape.co.uk> - 2017-06-03 11:10 +0200
    Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Brian <ad44@cityscape.co.uk> - 2017-06-03 11:20 +0200
      Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Gary Dale <garydale@torfree.net> - 2017-06-03 20:10 +0200
        Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Brian <ad44@cityscape.co.uk> - 2017-06-03 20:30 +0200
          Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Gary Dale <garydale@torfree.net> - 2017-06-03 20:50 +0200
            Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Gary Dale <garydale@torfree.net> - 2017-06-04 00:50 +0200
              Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Brian <ad44@cityscape.co.uk> - 2017-06-04 19:40 +0200
                Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Gary Dale <garydale@torfree.net> - 2017-06-05 02:40 +0200
                  Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Brian <ad44@cityscape.co.uk> - 2017-06-05 16:10 +0200
                    Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Gary Dale <garydale@torfree.net> - 2017-06-07 00:50 +0200
                      Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Brian <ad44@cityscape.co.uk> - 2017-06-07 15:20 +0200
      Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Gary Dale <garydale@torfree.net> - 2017-06-04 01:00 +0200
        Re: HP CP1215 - CUPS not printing from Stretch to Jessie server. Curt <curty@free.fr> - 2017-06-04 11:50 +0200

#181706 — HP CP1215 - CUPS not printing from Stretch to Jessie server.

I have an HP Color Laserjet CP1215 printer attached to a Jessie server 
via USB. I'm trying to print to it from Stretch workstation. This has 
been failing for a long time now. It's not a new problem. I've tried 
removing the printer and re-finding it many times without success.

I'm using the HP Color LaserJet CP1215 Foomatic/foo2hp (recommended) 
driver on both the server and my workstation. However when I try 
printing anything from the workstation, it fails with a "Filter failed" 
message. The message appears on the CUPS Jobs page on both the 
workstation and server.

I can print directly from the server (e.g. test page using the CUPS 
Printers page or lp from the command line) but not from my workstation.

I can print to another printer (Samsung C410) attached to the server, 
also by USB, using the same protocol (dnssd:) and it works. The major 
difference is that the it's using the Samsung C410 Series (color) driver.

The cups error log on the server isn't helpful. The first message that 
it shows for a failing job is:

E [02/Jun/2017:14:17:27 -0400] [Job 2241] Job stopped due to filter 
errors; please consult the error_log file for details.

Further down it shows these interesting messages:

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Printing system options:
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'job-originating-host-name=192.168.1.24'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
job-originating-host-name=192.168.1.24.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'time-at-creation=1496427439'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
time-at-creation=1496427439.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'time-at-processing=1496427439'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
time-at-processing=1496427439.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] CM Color Calibration Mode in 
CUPS: Off
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Options from the PPD file:
D [02/Jun/2017:14:17:27 -0400] [Job 2241] 
================================================
D [02/Jun/2017:14:17:27 -0400] [Job 2241] File: /var/spool/cups/d02241-001
D [02/Jun/2017:14:17:27 -0400] [Job 2241] 
================================================
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Cannot process 
"/var/spool/cups/d02241-001": Unknown filetype.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Process is dying with "Could 
not print file /var/spool/cups/d02241-001
D [02/Jun/2017:14:17:27 -0400] [Job 2241] ", exit stat 2


Any ideas?

[toc] | [next] | [standalone]

#181709

On 02/06/17 04:38 PM, Gary Dale wrote:
> I have an HP Color Laserjet CP1215 printer attached to a Jessie server 
> via USB. I'm trying to print to it from Stretch workstation. This has 
> been failing for a long time now. It's not a new problem. I've tried 
> removing the printer and re-finding it many times without success.
>
> I'm using the HP Color LaserJet CP1215 Foomatic/foo2hp (recommended) 
> driver on both the server and my workstation. However when I try 
> printing anything from the workstation, it fails with a "Filter 
> failed" message. The message appears on the CUPS Jobs page on both the 
> workstation and server.
>
> I can print directly from the server (e.g. test page using the CUPS 
> Printers page or lp from the command line) but not from my workstation.
>
> I can print to another printer (Samsung C410) attached to the server, 
> also by USB, using the same protocol (dnssd:) and it works. The major 
> difference is that the it's using the Samsung C410 Series (color) driver.
>
> The cups error log on the server isn't helpful. The first message that 
> it shows for a failing job is:
>
> E [02/Jun/2017:14:17:27 -0400] [Job 2241] Job stopped due to filter 
> errors; please consult the error_log file for details.
>
> Further down it shows these interesting messages:
>
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Printing system options:
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
> 'job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
> job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
> 'job-originating-host-name=192.168.1.24'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
> job-originating-host-name=192.168.1.24.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
> 'time-at-creation=1496427439'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
> time-at-creation=1496427439.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
> 'time-at-processing=1496427439'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
> time-at-processing=1496427439.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] CM Color Calibration Mode in 
> CUPS: Off
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Options from the PPD file:
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] 
> ================================================
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] File: 
> /var/spool/cups/d02241-001
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] 
> ================================================
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Cannot process 
> "/var/spool/cups/d02241-001": Unknown filetype.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Process is dying with "Could 
> not print file /var/spool/cups/d02241-001
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] ", exit stat 2
>
>
> Any ideas?
>
BTW: the same thing happens when I use the hpcups driver.

[toc] | [prev] | [next] | [standalone]

#181712

On 2017-06-03, Gary Dale <garydale@torfree.net> wrote:
>>
>>
>> Any ideas?
>>
> BTW: the same thing happens when I use the hpcups driver.
>

I may be all wet but have you attempted setting the client queue to raw?

Perhaps this could be tested beforehand with 'lpr -l <filename>' (on the
client machine, of course).

Sorry if I wasted your time.


-- 
"It might be a vision--of a shell, of a wheelbarrow, of a fairy kingdom on the
far side of the hedge; or it might be the glory of speed; no one knew." --Mrs.
Ramsay, speculating on why her little daughter might be dashing about, in "To
the Lighthouse," by Virginia Woolf.

[toc] | [prev] | [next] | [standalone]

#181713

On Sat 03 Jun 2017 at 07:53:06 +0000, Curt wrote:

> On 2017-06-03, Gary Dale <garydale@torfree.net> wrote:
> >>
> >>
> >> Any ideas?
> >>
> > BTW: the same thing happens when I use the hpcups driver.
> >
> 
> I may be all wet but have you attempted setting the client queue to raw?
> 
> Perhaps this could be tested beforehand with 'lpr -l <filename>' (on the
> client machine, of course).

A good idea. With some slight adjustment to the command printing should
take place:

 lpr -P <print_queue> -l <filename>

<print_queue> can only be omitted if it is the default destination.

Alternatively (if lpr is not on the machine):

 lp -d <print_queue> -o raw <filename>

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#181714

On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:

> I have an HP Color Laserjet CP1215 printer attached to a Jessie server via
> USB. I'm trying to print to it from Stretch workstation. This has been
> failing for a long time now. It's not a new problem. I've tried removing the
> printer and re-finding it many times without success.

We presume the re-finding is done via the CUPS web interface or something
similar. Is cups-browsed running on the client?

 systemctl status cups-browsed

> I'm using the HP Color LaserJet CP1215 Foomatic/foo2hp (recommended) driver
> on both the server and my workstation. However when I try printing anything
> from the workstation, it fails with a "Filter failed" message. The message
> appears on the CUPS Jobs page on both the workstation and server.
> 
> I can print directly from the server (e.g. test page using the CUPS Printers
> page or lp from the command line) but not from my workstation.
> 
> I can print to another printer (Samsung C410) attached to the server, also
> by USB, using the same protocol (dnssd:) and it works. The major difference
> is that the it's using the Samsung C410 Series (color) driver.
> 
> The cups error log on the server isn't helpful. The first message that it
> shows for a failing job is:
> 
> E [02/Jun/2017:14:17:27 -0400] [Job 2241] Job stopped due to filter errors;
> please consult the error_log file for details.

Unfortunately, the code that reports the terminating state of the job
does not have the name of the process that failed, which gets logged
separately.

> Further down it shows these interesting messages:
> 
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Printing system options:
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
> 'job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
> job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
> 'job-originating-host-name=192.168.1.24'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
> job-originating-host-name=192.168.1.24.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
> 'time-at-creation=1496427439'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
> time-at-creation=1496427439.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
> 'time-at-processing=1496427439'
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
> time-at-processing=1496427439.
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] CM Color Calibration Mode in CUPS:
> Off
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Options from the PPD file:
> D [02/Jun/2017:14:17:27 -0400] [Job 2241]
> ================================================
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] File: /var/spool/cups/d02241-001
> D [02/Jun/2017:14:17:27 -0400] [Job 2241]
> ================================================
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Cannot process
> "/var/spool/cups/d02241-001": Unknown filetype.

The server has been sent a file by the client which cannot be MIME typed.

> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Process is dying with "Could not
> print file /var/spool/cups/d02241-001
> D [02/Jun/2017:14:17:27 -0400] [Job 2241] ", exit stat 2
> 
> Any ideas?

The Printing section on the wiki deals with "Double Filtering". It might
help.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#181721

On 03/06/17 05:10 AM, Brian wrote:
> On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:
>
>> I have an HP Color Laserjet CP1215 printer attached to a Jessie server via
>> USB. I'm trying to print to it from Stretch workstation. This has been
>> failing for a long time now. It's not a new problem. I've tried removing the
>> printer and re-finding it many times without success.
> We presume the re-finding is done via the CUPS web interface or something
> similar. Is cups-browsed running on the client?
>
>   systemctl status cups-browsed

Yes, I used the web interface to find the printer. And yes cups-browsed 
is running on the workstation.


>> I'm using the HP Color LaserJet CP1215 Foomatic/foo2hp (recommended) driver
>> on both the server and my workstation. However when I try printing anything
>> from the workstation, it fails with a "Filter failed" message. The message
>> appears on the CUPS Jobs page on both the workstation and server.
>>
>> I can print directly from the server (e.g. test page using the CUPS Printers
>> page or lp from the command line) but not from my workstation.
>>
>> I can print to another printer (Samsung C410) attached to the server, also
>> by USB, using the same protocol (dnssd:) and it works. The major difference
>> is that the it's using the Samsung C410 Series (color) driver.
>>
>> The cups error log on the server isn't helpful. The first message that it
>> shows for a failing job is:
>>
>> E [02/Jun/2017:14:17:27 -0400] [Job 2241] Job stopped due to filter errors;
>> please consult the error_log file for details.
> Unfortunately, the code that reports the terminating state of the job
> does not have the name of the process that failed, which gets logged
> separately.
>
>> Further down it shows these interesting messages:
>>
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Printing system options:
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
>> 'job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc'
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
>> job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc.
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
>> 'job-originating-host-name=192.168.1.24'
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
>> job-originating-host-name=192.168.1.24.
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
>> 'time-at-creation=1496427439'
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
>> time-at-creation=1496427439.
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option
>> 'time-at-processing=1496427439'
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option
>> time-at-processing=1496427439.
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] CM Color Calibration Mode in CUPS:
>> Off
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Options from the PPD file:
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241]
>> ================================================
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] File: /var/spool/cups/d02241-001
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241]
>> ================================================
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Cannot process
>> "/var/spool/cups/d02241-001": Unknown filetype.
> The server has been sent a file by the client which cannot be MIME typed.
>
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] Process is dying with "Could not
>> print file /var/spool/cups/d02241-001
>> D [02/Jun/2017:14:17:27 -0400] [Job 2241] ", exit stat 2
>>
>> Any ideas?
> The Printing section on the wiki deals with "Double Filtering". It might
> help.
>

[toc] | [prev] | [next] | [standalone]

#181722

On Sat 03 Jun 2017 at 14:00:59 -0400, Gary Dale wrote:

> On 03/06/17 05:10 AM, Brian wrote:
> >On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:
> >
> >>I have an HP Color Laserjet CP1215 printer attached to a Jessie server via
> >>USB. I'm trying to print to it from Stretch workstation. This has been
> >>failing for a long time now. It's not a new problem. I've tried removing the
> >>printer and re-finding it many times without success.
> >We presume the re-finding is done via the CUPS web interface or something
> >similar. Is cups-browsed running on the client?
> >
> >  systemctl status cups-browsed
> 
> Yes, I used the web interface to find the printer.

On the following pages you would be best advised to choose "raw" as the
PPD and have all the filtering on the server.

>                                                    And yes cups-browsed is
> running on the workstation.

cups-browsed is not a cause of your problem but if you let it do its
job it would set up a raw queue for you.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#181723

On 03/06/17 02:21 PM, Brian wrote:
> On Sat 03 Jun 2017 at 14:00:59 -0400, Gary Dale wrote:
>
>> On 03/06/17 05:10 AM, Brian wrote:
>>> On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:
>>>
>>>> I have an HP Color Laserjet CP1215 printer attached to a Jessie server via
>>>> USB. I'm trying to print to it from Stretch workstation. This has been
>>>> failing for a long time now. It's not a new problem. I've tried removing the
>>>> printer and re-finding it many times without success.
>>> We presume the re-finding is done via the CUPS web interface or something
>>> similar. Is cups-browsed running on the client?
>>>
>>>   systemctl status cups-browsed
>> Yes, I used the web interface to find the printer.
> On the following pages you would be best advised to choose "raw" as the
> PPD and have all the filtering on the server.
>
>>                                                     And yes cups-browsed is
>> running on the workstation.
> cups-browsed is not a cause of your problem but if you let it do its
> job it would set up a raw queue for you.
>
You're right, but I've had this setup for a long time and it was never a 
problem before. It seems to have started with Stretch.

Anyway, thanks!

[toc] | [prev] | [next] | [standalone]

#181727

On 03/06/17 02:39 PM, Gary Dale wrote:
> On 03/06/17 02:21 PM, Brian wrote:
>> On Sat 03 Jun 2017 at 14:00:59 -0400, Gary Dale wrote:
>>
>>> On 03/06/17 05:10 AM, Brian wrote:
>>>> On Fri 02 Jun 2017 at 16:38:42 -0400, Gary Dale wrote:
>>>>
>>>>> I have an HP Color Laserjet CP1215 printer attached to a Jessie 
>>>>> server via
>>>>> USB. I'm trying to print to it from Stretch workstation. This has 
>>>>> been
>>>>> failing for a long time now. It's not a new problem. I've tried 
>>>>> removing the
>>>>> printer and re-finding it many times without success.
>>>> We presume the re-finding is done via the CUPS web interface or 
>>>> something
>>>> similar. Is cups-browsed running on the client?
>>>>
>>>>   systemctl status cups-browsed
>>> Yes, I used the web interface to find the printer.
>> On the following pages you would be best advised to choose "raw" as the
>> PPD and have all the filtering on the server.
>>
>>> And yes cups-browsed is
>>> running on the workstation.
>> cups-browsed is not a cause of your problem but if you let it do its
>> job it would set up a raw queue for you.
>>
> You're right, but I've had this setup for a long time and it was never 
> a problem before. It seems to have started with Stretch.
>
> Anyway, thanks!
>

After much gnashing of teeth (actually disassembling my Samsung C410 to 
remove two sheets of paper wrapped around the fuser), I'm still confused 
about something. When I set up my Samsung C410 through the CUPS web 
interface, on the server I use the Samsung C410 driver and the usb 
connection. On the client I use the discovered printer but again need to 
use the Samsung C410 driver which now shows up as Remote printer: 
Samsung C410 Series (color).

When I set up the HP Color LaserJet CP1215, on the server I use the HP 
Color LaserJet CP1215 Foomatic driver and the usb connection. However on 
the client when I use the discovered printer and the CP1215 driver, it 
doesn't work. I need to use raw printing.

I'm sorry but this doesn't make any sense to me. If I understand things 
correctly, CUPS knows that the printer is remote and is being handled by 
a CUPS server but can't figure out which machine should do the 
rendering. Instead it leaves it up to the driver to add the smarts to 
figure out who should do it.

I've got several printers attached to my server, including 2 Samsungs, 1 
Epson and the CP1215. Only the CP1215 seems to believe that it is a 
local raw printer on my client. And again, this only seems to be a 
problem since I moved to Stretch. I think this qualifies as a bug.

[toc] | [prev] | [next] | [standalone]

#181748

On Sat 03 Jun 2017 at 18:45:13 -0400, Gary Dale wrote:

> After much gnashing of teeth (actually disassembling my Samsung C410 to
> remove two sheets of paper wrapped around the fuser), I'm still confused
> about something. When I set up my Samsung C410 through the CUPS web
> interface, on the server I use the Samsung C410 driver and the usb
> connection. On the client I use the discovered printer but again need to use
> the Samsung C410 driver which now shows up as Remote printer: Samsung C410
> Series (color).

You do not *need* to use the Samsung C410 PPD or the rastertospl filter
on the client. In fact, you are better off just letting cups-browsed
take care of things and not bothering with using the CUPS web interface.

> When I set up the HP Color LaserJet CP1215, on the server I use the HP Color
> LaserJet CP1215 Foomatic driver and the usb connection. However on the
> client when I use the discovered printer and the CP1215 driver, it doesn't
> work. I need to use raw printing.

If cups-browsed is sidelined a raw queue would be the only other sensible
method.

> I'm sorry but this doesn't make any sense to me. If I understand things
> correctly, CUPS knows that the printer is remote and is being handled by a
> CUPS server but can't figure out which machine should do the rendering.
> Instead it leaves it up to the driver to add the smarts to figure out who
> should do it.

CUPS on the client knows the URI to send the job to. Prior to that it
will perform filter operations on the job because it has been told to
do so.  There is no negotiation between client and server as to which
machine handles filtering, so the server will probably attempt to filter
the job again. The main job of the driver (PPD?) is to get the print job
in a form suitable to go to the printer. It functions only within the
queue it is set up for.

There is no reliable way to detect whether data which are sent to the
server are printer-specific data (to be sent directly to the printer) or
data which must be filtered to get printer-specific data. I suppose if
the server identifies a file as application/octet-stream it could be
printed. You would have to look at Jessie and Stretch error_logs to
determine that and sort out what you see as puzzling.

> I've got several printers attached to my server, including 2 Samsungs, 1
> Epson and the CP1215. Only the CP1215 seems to believe that it is a local
> raw printer on my client. And again, this only seems to be a problem since I
> moved to Stretch. I think this qualifies as a bug.

A Jessie or Stretch client would produce Zenographics Zjstream printer
data to send to the server; no change there. CUPS on the server (which
hasn't changed) is the one doing the MIME media typing and saying it
cannot detect the file type.

A sound principle to apply to duplicate filtering is - don't do it.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#181753

On 04/06/17 01:34 PM, Brian wrote:
> On Sat 03 Jun 2017 at 18:45:13 -0400, Gary Dale wrote:
>
>> After much gnashing of teeth (actually disassembling my Samsung C410 to
>> remove two sheets of paper wrapped around the fuser), I'm still confused
>> about something. When I set up my Samsung C410 through the CUPS web
>> interface, on the server I use the Samsung C410 driver and the usb
>> connection. On the client I use the discovered printer but again need to use
>> the Samsung C410 driver which now shows up as Remote printer: Samsung C410
>> Series (color).
> You do not *need* to use the Samsung C410 PPD or the rastertospl filter
> on the client. In fact, you are better off just letting cups-browsed
> take care of things and not bothering with using the CUPS web interface.
Not really true. You seem to be trying to say that the CUPS printer 
discovery on the web interface shouldn't be used, which doesn't seem to 
be the way the web interface is designed. There is no indication that 
the find option is in any way deprecated.

>
>> When I set up the HP Color LaserJet CP1215, on the server I use the HP Color
>> LaserJet CP1215 Foomatic driver and the usb connection. However on the
>> client when I use the discovered printer and the CP1215 driver, it doesn't
>> work. I need to use raw printing.
> If cups-browsed is sidelined a raw queue would be the only other sensible
> method.
Except that it doesn't seem to work that way. It's just the CP1215 that 
needs to be set explicitly to raw. The other printers don't work when I 
set their driver to raw. I need to use the driver.

>
>> I'm sorry but this doesn't make any sense to me. If I understand things
>> correctly, CUPS knows that the printer is remote and is being handled by a
>> CUPS server but can't figure out which machine should do the rendering.
>> Instead it leaves it up to the driver to add the smarts to figure out who
>> should do it.
> CUPS on the client knows the URI to send the job to. Prior to that it
> will perform filter operations on the job because it has been told to
> do so.  There is no negotiation between client and server as to which
> machine handles filtering, so the server will probably attempt to filter
> the job again. The main job of the driver (PPD?) is to get the print job
> in a form suitable to go to the printer. It functions only within the
> queue it is set up for.
>
> There is no reliable way to detect whether data which are sent to the
> server are printer-specific data (to be sent directly to the printer) or
> data which must be filtered to get printer-specific data. I suppose if
> the server identifies a file as application/octet-stream it could be
> printed. You would have to look at Jessie and Stretch error_logs to
> determine that and sort out what you see as puzzling.
That makes no sense. CUPS knows it's sending something to a remote queue 
( DNSSD: ) so it should be able figure out that it shouldn't do double 
filtering. I don't care where the filtering gets done but it should be 
done properly.
>> I've got several printers attached to my server, including 2 Samsungs, 1
>> Epson and the CP1215. Only the CP1215 seems to believe that it is a local
>> raw printer on my client. And again, this only seems to be a problem since I
>> moved to Stretch. I think this qualifies as a bug.
> A Jessie or Stretch client would produce Zenographics Zjstream printer
> data to send to the server; no change there. CUPS on the server (which
> hasn't changed) is the one doing the MIME media typing and saying it
> cannot detect the file type.
>
> A sound principle to apply to duplicate filtering is - don't do it.
>
Except that if I follow your advice and change my Samsung and Epson 
queues to raw on the client, they stop working.

Which leads me to ask again why this inconsistent handling of remote 
queues shouldn't be classified as a bug?

[toc] | [prev] | [next] | [standalone]

#181776

On Sun 04 Jun 2017 at 20:37:38 -0400, Gary Dale wrote:

> On 04/06/17 01:34 PM, Brian wrote:
> >On Sat 03 Jun 2017 at 18:45:13 -0400, Gary Dale wrote:
> >
> >>After much gnashing of teeth (actually disassembling my Samsung C410 to
> >>remove two sheets of paper wrapped around the fuser), I'm still confused
> >>about something. When I set up my Samsung C410 through the CUPS web
> >>interface, on the server I use the Samsung C410 driver and the usb
> >>connection. On the client I use the discovered printer but again need to use
> >>the Samsung C410 driver which now shows up as Remote printer: Samsung C410
> >>Series (color).
> >
> >You do not *need* to use the Samsung C410 PPD or the rastertospl filter
> >on the client. In fact, you are better off just letting cups-browsed
> >take care of things and not bothering with using the CUPS web interface.
>
> Not really true. You seem to be trying to say that the CUPS printer
> discovery on the web interface shouldn't be used, which doesn't seem to be
> the way the web interface is designed. There is no indication that the find
> option is in any way deprecated.

"...better off..." does not equate equate with advice never to use the
web interface, The automatic printer and print queue discovery brought
about by cups-browsed is a very useful tool which benefits many users.

> >>When I set up the HP Color LaserJet CP1215, on the server I use the HP Color
> >>LaserJet CP1215 Foomatic driver and the usb connection. However on the
> >>client when I use the discovered printer and the CP1215 driver, it doesn't
> >>work. I need to use raw printing.
> >
> >If cups-browsed is sidelined a raw queue would be the only other sensible
> >method.
>
> Except that it doesn't seem to work that way. It's just the CP1215 that
> needs to be set explicitly to raw. The other printers don't work when I set
> their driver to raw. I need to use the driver.

You apparently can print a simple text file directly from the server wih
lp so the scheduler should handle the same file in the same way when it
is printed from a raw queue on a client. The origin of the file
effectively plays no part in whether it gets printed. You will have to
look at the error_logs on client and server to determine why this
doesn't work for you.

> >>I'm sorry but this doesn't make any sense to me. If I understand things
> >>correctly, CUPS knows that the printer is remote and is being handled by a
> >>CUPS server but can't figure out which machine should do the rendering.
> >>Instead it leaves it up to the driver to add the smarts to figure out who
> >>should do it.
> >
> >CUPS on the client knows the URI to send the job to. Prior to that it
> >will perform filter operations on the job because it has been told to
> >do so.  There is no negotiation between client and server as to which
> >machine handles filtering, so the server will probably attempt to filter
> >the job again. The main job of the driver (PPD?) is to get the print job
> >in a form suitable to go to the printer. It functions only within the
> >queue it is set up for.
> >
> >There is no reliable way to detect whether data which are sent to the
> >server are printer-specific data (to be sent directly to the printer) or
> >data which must be filtered to get printer-specific data. I suppose if
> >the server identifies a file as application/octet-stream it could be
> >printed. You would have to look at Jessie and Stretch error_logs to
> >determine that and sort out what you see as puzzling.
>
> That makes no sense. CUPS knows it's sending something to a remote queue (
> DNSSD: ) so it should be able figure out that it shouldn't do double
> filtering. I don't care where the filtering gets done but it should be done
> properly.

You will have read what upstream CUPS has to say in the link you were
given, Any disagreement you have would be better taken up upstream.

 https://github.com/apple/cups/issues

> >>I've got several printers attached to my server, including 2 Samsungs, 1
> >>Epson and the CP1215. Only the CP1215 seems to believe that it is a local
> >>raw printer on my client. And again, this only seems to be a problem since I
> >>moved to Stretch. I think this qualifies as a bug.
> >
> >A Jessie or Stretch client would produce Zenographics Zjstream printer
> >data to send to the server; no change there. CUPS on the server (which
> >hasn't changed) is the one doing the MIME media typing and saying it
> >cannot detect the file type.
> >
> >A sound principle to apply to duplicate filtering is - don't do it.
> >
> Except that if I follow your advice and change my Samsung and Epson queues
> to raw on the client, they stop working.
> 
> Which leads me to ask again why this inconsistent handling of remote queues
> shouldn't be classified as a bug?

I set up a C410 queue on a Jessie machine:

 lpadmin -p sam410 -v file:/root/410 -E -P Samsung_C410_Series.ppd

Printing from the server is successful.

On a Stretch client I had raw and non-raw queues;

 lpadmin -p sam410remote1 -v ipp://192.168.7.20/printers/sam410 -E -m raw
 lpadmin -p sam410remote2 -v ipp://192.168.7.20/printers/sam410 -E -P Samsung_C410_Series.ppd

Printing to sam410remote1 works. Here are some highlights from the log
on the server:

 I [05/Jun/2017:14:40:43 +0100] [Job 1434] File of type text/plain queued by "remroot".

 D [05/Jun/2017:14:40:43 +0100] [Job 1434] 4 filters for job:
 D [05/Jun/2017:14:40:43 +0100] [Job 1434] envp[9]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin"
 I [05/Jun/2017:14:40:43 +0100] [Job 1434] Started filter /usr/lib/cups/filter/texttopdf (PID 5449)
 I [05/Jun/2017:14:40:43 +0100] [Job 1434] Started filter /usr/lib/cups/filter/pdftopdf (PID 5450)
 I [05/Jun/2017:14:40:43 +0100] [Job 1434] Started filter /usr/lib/cups/filter/gstoraster (PID 5451)
 I [05/Jun/2017:14:40:43 +0100] [Job 1434] Started filter /usr/lib/cups/filter/rastertospl (PID 5452)
 D [05/Jun/2017:14:40:43 +0100] [Job 1434] PID 5449 (/usr/lib/cups/filter/texttopdf) exited with no errors.
 D [05/Jun/2017:14:40:43 +0100] [Job 1434] envp[9]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin"
 D [05/Jun/2017:14:40:43 +0100] [Job 1434] PID 5450 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
 D [05/Jun/2017:14:41:02 +0100] [Job 1434] PID 5451 (/usr/lib/cups/filter/gstoraster) exited with no errors.
 D [05/Jun/2017:14:41:02 +0100] [Job 1434] PID 5452 (/usr/lib/cups/filter/rastertospl) exited with no errors.

Printing to sam410remote2 doesn't work. I get the same expected outcomes
when the queues are set up via the web interface and for CP1215 queues.
No lack of consistency here.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#181859

On 05/06/17 10:03 AM, Brian wrote:
> On Sun 04 Jun 2017 at 20:37:38 -0400, Gary Dale wrote:
>
>> On 04/06/17 01:34 PM, Brian wrote:
>>> On Sat 03 Jun 2017 at 18:45:13 -0400, Gary Dale wrote:
>>>
>>>> After much gnashing of teeth (actually disassembling my Samsung C410 to
>>>> remove two sheets of paper wrapped around the fuser), I'm still confused
>>>> about something. When I set up my Samsung C410 through the CUPS web
>>>> interface, on the server I use the Samsung C410 driver and the usb
>>>> connection. On the client I use the discovered printer but again need to use
>>>> the Samsung C410 driver which now shows up as Remote printer: Samsung C410
>>>> Series (color).
>>> You do not *need* to use the Samsung C410 PPD or the rastertospl filter
>>> on the client. In fact, you are better off just letting cups-browsed
>>> take care of things and not bothering with using the CUPS web interface.
>> Not really true. You seem to be trying to say that the CUPS printer
>> discovery on the web interface shouldn't be used, which doesn't seem to be
>> the way the web interface is designed. There is no indication that the find
>> option is in any way deprecated.
> "...better off..." does not equate equate with advice never to use the
> web interface, The automatic printer and print queue discovery brought
> about by cups-browsed is a very useful tool which benefits many users.
You keep bringing up cups-browsed as if it is some kind of end-user 
tool. However it is a daemon that handles finding remote printers. On my 
Jessie laptop, it seems to find the queues shared by my Jessie server 
and creates local queues for them as <queue name> @ <server name>.

However it doesn't do that on my Stretch client. Instead I have to use 
the Find New Printers tab in the web interface. This allows me to add a 
local queue using the DNSSD: protocol to talk to the remote printer (or 
something like that). Moreover, it seems to find network printers that 
aren't going through the CUPS server, although it doesn't do this on my 
Jessie client.

Basically for Stretch all it seems to do is save me from having to type 
in the connection details.

>
>>>> When I set up the HP Color LaserJet CP1215, on the server I use the HP Color
>>>> LaserJet CP1215 Foomatic driver and the usb connection. However on the
>>>> client when I use the discovered printer and the CP1215 driver, it doesn't
>>>> work. I need to use raw printing.
>>> If cups-browsed is sidelined a raw queue would be the only other sensible
>>> method.
>> Except that it doesn't seem to work that way. It's just the CP1215 that
>> needs to be set explicitly to raw. The other printers don't work when I set
>> their driver to raw. I need to use the driver.
> You apparently can print a simple text file directly from the server wih
> lp so the scheduler should handle the same file in the same way when it
> is printed from a raw queue on a client. The origin of the file
> effectively plays no part in whether it gets printed. You will have to
> look at the error_logs on client and server to determine why this
> doesn't work for you.
No. I can print any file that lp can handle. I usually ended up creating 
a PDF, ssh to the server and use lp to print it.

The error logs on the client simply say "filter failed" while I've 
posted the error log from the server.

>
>>>> I'm sorry but this doesn't make any sense to me. If I understand things
>>>> correctly, CUPS knows that the printer is remote and is being handled by a
>>>> CUPS server but can't figure out which machine should do the rendering.
>>>> Instead it leaves it up to the driver to add the smarts to figure out who
>>>> should do it.
>>> CUPS on the client knows the URI to send the job to. Prior to that it
>>> will perform filter operations on the job because it has been told to
>>> do so.  There is no negotiation between client and server as to which
>>> machine handles filtering, so the server will probably attempt to filter
>>> the job again. The main job of the driver (PPD?) is to get the print job
>>> in a form suitable to go to the printer. It functions only within the
>>> queue it is set up for.
>>>
>>> There is no reliable way to detect whether data which are sent to the
>>> server are printer-specific data (to be sent directly to the printer) or
>>> data which must be filtered to get printer-specific data. I suppose if
>>> the server identifies a file as application/octet-stream it could be
>>> printed. You would have to look at Jessie and Stretch error_logs to
>>> determine that and sort out what you see as puzzling.
>> That makes no sense. CUPS knows it's sending something to a remote queue (
>> DNSSD: ) so it should be able figure out that it shouldn't do double
>> filtering. I don't care where the filtering gets done but it should be done
>> properly.
> You will have read what upstream CUPS has to say in the link you were
> given, Any disagreement you have would be better taken up upstream.
>
>   https://github.com/apple/cups/issues
The link is to open issues. Was there one in particular you are 
referring to?

>
>>>> I've got several printers attached to my server, including 2 Samsungs, 1
>>>> Epson and the CP1215. Only the CP1215 seems to believe that it is a local
>>>> raw printer on my client. And again, this only seems to be a problem since I
>>>> moved to Stretch. I think this qualifies as a bug.
>>> A Jessie or Stretch client would produce Zenographics Zjstream printer
>>> data to send to the server; no change there. CUPS on the server (which
>>> hasn't changed) is the one doing the MIME media typing and saying it
>>> cannot detect the file type.
>>>
>>> A sound principle to apply to duplicate filtering is - don't do it.
>>>
>> Except that if I follow your advice and change my Samsung and Epson queues
>> to raw on the client, they stop working.
>>
>> Which leads me to ask again why this inconsistent handling of remote queues
>> shouldn't be classified as a bug?
> I set up a C410 queue on a Jessie machine:
>
>   lpadmin -p sam410 -v file:/root/410 -E -P Samsung_C410_Series.ppd
>
> Printing from the server is successful.
>
> On a Stretch client I had raw and non-raw queues;
>
>   lpadmin -p sam410remote1 -v ipp://192.168.7.20/printers/sam410 -E -m raw
>   lpadmin -p sam410remote2 -v ipp://192.168.7.20/printers/sam410 -E -P Samsung_C410_Series.ppd
>
> Printing to sam410remote1 works. Here are some highlights from the log
> on the server:
>
>   I [05/Jun/2017:14:40:43 +0100] [Job 1434] File of type text/plain queued by "remroot".
>
>   D [05/Jun/2017:14:40:43 +0100] [Job 1434] 4 filters for job:
>   D [05/Jun/2017:14:40:43 +0100] [Job 1434] envp[9]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin"
>   I [05/Jun/2017:14:40:43 +0100] [Job 1434] Started filter /usr/lib/cups/filter/texttopdf (PID 5449)
>   I [05/Jun/2017:14:40:43 +0100] [Job 1434] Started filter /usr/lib/cups/filter/pdftopdf (PID 5450)
>   I [05/Jun/2017:14:40:43 +0100] [Job 1434] Started filter /usr/lib/cups/filter/gstoraster (PID 5451)
>   I [05/Jun/2017:14:40:43 +0100] [Job 1434] Started filter /usr/lib/cups/filter/rastertospl (PID 5452)
>   D [05/Jun/2017:14:40:43 +0100] [Job 1434] PID 5449 (/usr/lib/cups/filter/texttopdf) exited with no errors.
>   D [05/Jun/2017:14:40:43 +0100] [Job 1434] envp[9]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin"
>   D [05/Jun/2017:14:40:43 +0100] [Job 1434] PID 5450 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
>   D [05/Jun/2017:14:41:02 +0100] [Job 1434] PID 5451 (/usr/lib/cups/filter/gstoraster) exited with no errors.
>   D [05/Jun/2017:14:41:02 +0100] [Job 1434] PID 5452 (/usr/lib/cups/filter/rastertospl) exited with no errors.
>
> Printing to sam410remote2 doesn't work. I get the same expected outcomes
> when the queues are set up via the web interface and for CP1215 queues.
> No lack of consistency here.
>
As they say, your mileage may vary. That's not what's happening from my 
client. However you seem to be specifying ipp: when on the Stretch 
client clicking on the Add Printer button sets the queues up using 
dnssd:. e.g. 
dnssd://HP%20Color%20LaserJet%20CP1215%20%40%20TheLibrarian._ipp._tcp.local/cups?uuid=5952871b-80d3-3c14-5ce9-bc344963dae6

However I note that after a while the connection changes to be reported 
as implicitclass:. e.g. implicitclass:Samsung_C410_Series. I'm not sure 
what triggers that.

[toc] | [prev] | [next] | [standalone]

#181879

On Tue 06 Jun 2017 at 18:44:55 -0400, Gary Dale wrote:

> On 05/06/17 10:03 AM, Brian wrote:
> >On Sun 04 Jun 2017 at 20:37:38 -0400, Gary Dale wrote:

[cups-browsed experiences snipped].

> >>Except that it doesn't seem to work that way. It's just the CP1215 that
> >>needs to be set explicitly to raw. The other printers don't work when I set
> >>their driver to raw. I need to use the driver.
> >
> >You apparently can print a simple text file directly from the server wih
> >lp so the scheduler should handle the same file in the same way when it
> >is printed from a raw queue on a client. The origin of the file
> >effectively plays no part in whether it gets printed. You will have to
> >look at the error_logs on client and server to determine why this
> >doesn't work for you.
>
> No. I can print any file that lp can handle. I usually ended up creating a
> PDF, ssh to the server and use lp to print it.
> 
> The error logs on the client simply say "filter failed" while I've posted
> the error log from the server.

Recapitulating. You have CP1215 queues on client and server both set up
with a PPD.

 lp -d <CP1215_queue> -o raw <file>

gets printed but

 lp-d <CP1215_queue> <file>

doesn't. This is expected behaviour; anyone would be happy with that and
it is what happens here. The principal issue submitted in the first post
is solved. :)

Given correctly set up queues for the C410 on server and client the two
systems would handle a submitted file in the same way. The nature of the
printer is immaterial, it is the correctness of the queues which matters.

'lp -d <C410_queue> -o raw <file>' does not print for you. It prints for
me with ipp://... and dnssd://... URIs.

Moving on:

1. Produce error_logs on client and server when printing with
   'lp -d <C410_queue> -o raw /etc/nsswitch'. The wiki will
   guide you on getting the smallest possible error files.

2. The logs compress to a tenth of their sizes with gzip or xz.

3. Attach the compressed logs to your next post to the list.

4. Install avahi-utils. Run 'avahi-browse -art > avahi.log' and
   also attach the compressed avahi.log.
 
> >>That makes no sense. CUPS knows it's sending something to a remote queue (
> >>DNSSD: ) so it should be able figure out that it shouldn't do double
> >>filtering. I don't care where the filtering gets done but it should be done
> >>properly.
> >
> >You will have read what upstream CUPS has to say in the link you were
> >given, Any disagreement you have would be better taken up upstream.
> >
> >  https://github.com/apple/cups/issues
>
> The link is to open issues. Was there one in particular you are referring
> to?

The suggestion was to submit an issue based on "That makes no sense...".

> >I set up a C410 queue on a Jessie machine:

[Procedure and log snipped].

> >Printing to sam410remote2 doesn't work. I get the same expected outcomes
> >when the queues are set up via the web interface and for CP1215 queues.
> >No lack of consistency here.
> >
> As they say, your mileage may vary. That's not what's happening from my
> client. However you seem to be specifying ipp: when on the Stretch client
> clicking on the Add Printer button sets the queues up using dnssd:. e.g. dnssd://HP%20Color%20LaserJet%20CP1215%20%40%20TheLibrarian._ipp._tcp.local/cups?uuid=5952871b-80d3-3c14-5ce9-bc344963dae6

I gave details of my procedure so that treading in my footsteps was
possible and could be reported on with evidence. Either URI should work.
There is nothing magical about dnssd://... and it actually invokes the
ipp backend. I did use dnssd://... from the CUPS web server to set up a
queue.

> However I note that after a while the connection changes to be reported as
> implicitclass:. e.g. implicitclass:Samsung_C410_Series. I'm not sure what
> triggers that.

The reported URI seen depends on the utility which is used to view it.
implicitclass: is a cups-browsed thing. It is not germane to the problem
at hand. Considering you are not using cups-browsed you could purge it
from the client. (The server makes no use of it, so it could be removed
from there too).

-- 
Brian.
 

[toc] | [prev] | [next] | [standalone]

#181728

> The Printing section on the wiki deals with "Double Filtering". It might
> help.
>

Where is the wiki?

[toc] | [prev] | [next] | [standalone]

#181739

On 2017-06-03, Gary Dale <garydale@torfree.net> wrote:
>
>> The Printing section on the wiki deals with "Double Filtering". It might
>> help.
>>
>
> Where is the wiki?
>
>
I think this must be it:

https://wiki.debian.org/PrintQueuesCUPS#Double_Filtering

-- 
"It might be a vision--of a shell, of a wheelbarrow, of a fairy kingdom on the
far side of the hedge; or it might be the glory of speed; no one knew." --Mrs.
Ramsay, speculating on why her little daughter might be dashing about, in "To
the Lighthouse," by Virginia Woolf.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web