Comment 4 for bug 1335211

On 30/06/14 15:07, Till Kamppeter wrote:
> What is happening is the following:
>
> Your NAS is a machine running Linux (or some *BSD) and uses CUPS to
> implement the print server functionality. As a NAS does not carry a
> printer driver/PPD library it simply creates raw print queues (print
> queue without filters/drivers, passes incoming data simply through to
> the printer) and it is expected that one creates a print queue with
> driver on the client side, as one had a printer which is directly
> connected to the network.
>
> On a Ubuntu machine there is a program named cups-browsed running which
> automatically finds remote CUPS servers and printers shared by them and
> it automatically creates local print queues pointing to these printers
> so that one can use them easily from the local machine. Usually remote
> CUPS printers are printers connected to a remote computer using CUPS
> (usually the case for Linux, Mac OS X, and *BSD operating systems) and
> sharing its printers. Normally these printers are set up with a suitable
> driver on the server so that the local queue created by cups-browsed
> does not need to use a driver by itself and therefore cups-browsed
> creates raw queues. In addition, these queues are removed again when the
> remote server or printer disappears or when cups-browsed is shut down.
>
> Now with a NAS using CUPS and sharing raw queues and cups-browsed
> creating raw queues for all shared CUPS queues which it finds in the
> network there is no filter or driver from the client through the NAS to
> the printer and the PDF sent by the application arrives unchanged in the
> printer and the printer does not understand it. As the queues which
> cups-browsed generates are removed again when cups-browsed is shut down
> (for example on reboot) any attempt to "correct" these queues manually
> only survives until the next reboot.
>
> The bug is in cups-browsed, it should not create local queues pointing
> to remote raw queues but only to remote queues which have already a
> driver so that such non-working queues do not appear. This I have fixed
> in cups-browsed now and this fix will be included in cups-filters
> 1.0.55.
>
Thank you for your clear and detailed explanation - the NAS does run
Linux. There is one issue about which I'm still unclear. How does my
workround overcome this problem?

I now have a laptop and a Mint/Mate VM both of which now remember the
printer details after reboots, whether or not the printer is up at the
time. It would seem I've persuaded the local software to create a print
queue with local drivers and prevented cups-browsed (which I've
confirmed is running) from "correcting" it on a reboot. I'm puzzled as
to how I've achieved the latter. If the question is irrelevant now
you've identified the cause do feel free to ignore it ;-)

Regards, Pete