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.
