On 05/06/17 10:03 AM, Brian wrote:
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>.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.
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.
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.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.
The error logs on the client simply say "filter failed" while I've posted the error log from the server.
The link is to open issues. Was there one in particular you are referring to?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
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-bc344963dae6I'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.
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.