CUPS upstream dropped the CUPS broadcasting/browsing mechanism to automatically discover shared remote printers beginning from 1.6.x. Replacement is Bonjour-based broadcasting of the shared printers by CUPS and on the client side the application's print dialogs are responsible for browsing these broadcasts and listing the remote printers appropriately. CUPS even provides a library function for that now.
I wrote there:
The CUPS Browsing/Broadcasting mechanism which made print queues shared on remote CUPS servers automatically visible for the local CUPS daemon and so for local applications got dropped upstream from CUPS 1.6.x on. Ubpstream has replaced this functionality by Bonjour-based broadcasting (under Linux implemented via Avahi), an OS-indpendent PWG (Printing Working Group) standard, but this lacks the implementation of browsing on the client side making the printers on remote CUPS servers not automatically appearing any more.
Ubuntu Quantal's CUPS has a mega patch to forward-port this functionality from the old CUPS for one cycle, to avoid regressions. We cannot carry such a patch eternally, and we should follow upstream and the PWG standards.
So in Ubuntu Raring we need the real solution which means that the print dialogs (upstream-recommended solution) or the CUPS daemon (how I like to have it) takes the new Bonjour (Avahi) broadcasts to display the shared remote CUPS queues automatically. The browsing functionality is implemented in the CUPS library (libcups) from CUPS 1.6.x on, but there is currently no production code using these functions.
Upstream expects the print dialogs to use the new library functions for displaying the new queues. This would require modifications and upstream submissions for GTK, Qt, and LibreOffice at least and this does not safely cover all existing applications which have CUPS-aware print dialogs and therefore listed the remote queues before. Especially printing from the command line would not be covered.
The better approach would be modifying the CUPS daemon so that it uses the new library function to find the remote queues and advertize them like its own local queues. Where the CUPS daemon needs to be patched for that we could probably derive from Quantal's CUPS Broadcasting/Browsing forward port patch. The new Bonjour browsing patch being based on the new standard way of Bonjour broadcasting has probably good chances to be accepted upstream.
This feature does not only prevent a regression, but it also helps to more easily access printers connected to Mac OS X machines (they broadcasted Bonjour-only all the time) and also for mobile Ubuntu devices. Usually you do not have connected printers to tablets or phones and you carry them around between different local networks, so here it is especially important that they automatically pick up the print queues in the local network.
Such a patch to the CUPS daemon or an extra daemon to do the browsing and add/remove queues appropriately in the local CUPS environment is also not the best solution but a way to avoid regressions with legacy apps.
The real intention from upstream is that all print dialogs browse the print queues available on the local network via Bonjour (under Linux implemented by Avahi), where print queues on the local network are CUPS queues from Linux and Mac OS X but also IPP printers which broadcast themselves via Bonjour (IPP Everywhere printers). Printing on iOS devices (iPhone, iPad, iPod Touch) already works this way. These devices do not allow the setup of local queues at all and they discovcer available print queues via Bonjour.
For this the CUPS library has even special functions, see as sample code the program
to be called as follows:
cups/testcups enum 1
"enum" makes it enumerating printers and the number is the number of seconds to Bonjour-browse for network printers.
The library function is the function cupsEnumDests() in cups/dest.c. For Bonjour browsing it must be called with a non-zero value for the msec parameter.
This feature in the print dialogs is VERY urgent because:
- This is how CUPS upstream and also the PWG (Printing Working Group,
http://www.pwg.org/) expects how network printing with automatic
queue discovery works.
- This is less resource-consuming on mobile devices which do not have
local print queues. avahi-daemon is running anyway and the CUPS
daemon does not need to be running when there are no local queues.
- CUPS upstream would not most probably not accept patches on the CUPS
daemon to browse for Bonjour-advertized queues and let them appear
like local queues.
Therefore I want to ask you to add this feature with priority.
This is urgently needed so that Linux distributions accept CUPS 1.6.x. See also
Could you manage to implement this before the Feature Freeze of Ubuntu 13.04 (Raring) on March 7, 2013? I (and probably also the CUPS maintainers of all the other distros) would appreciate this very much.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice (18.104.22.168 or later): https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
Thank you for your help!
-- The LibreOffice QA Team
This NEW Message was generated on: 2015-02-19
This works on Ubuntu 17.10, it looks as if it is fixed in the distros themselves.