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 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups-filters in Ubuntu. https://bugs.launchpad.net/bugs/1335211 Title: Config details of networked printer aren't saved Status in “cups-filters” package in Ubuntu: Triaged Status in “system-config-printer” package in Ubuntu: Confirmed Bug description: Mint 17 64 bit. When I run the printer configuration application (system-config-printer) it detects my network printer. If I then access Priner properties I can set the manufacturer and model number in the usual way and the printer works. However the settings don't survive a reboot. The workround is to make a change to the Description field: the Apply button is then enabled and I can save the changes. Evidently the application doesn't register the changes to the printer's properties as a change requiring saving, and so leaves the Apply button greyed out. This behaviour is consistent and repeatable under Mate and Xfce. While the workround is simple the behaviour is confusing particularly to a new user. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1335211/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
