Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.
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.
Reply to: