10:43 a.m.
Hi,
Although the latest version of CUPS is 1.5.0, development is continuing
apace on 1.6. There are some important changes coming in 1.6 which
deserve to be pointed out.
Some time ago CUPS became an Apple project, and now some of the features
that are not relevant to Mac OS are being orphaned. Where they are of
use for the Linux environment, those orphaned features will continue to
be maintained at OpenPrinting (http://www.openprinting.org/) as a
separate project.
CUPS Browsing
-------------
One of the notable things that will be disappearing is CUPS Browsing.
This is currently the primary mechanism for CUPS-to-CUPS printer queue
discovery on Linux. It works by having each CUPS server periodically
broadcast UDP packets on port 631 announcing its available queues.
This method of discovery is being dropped in favour of DNS-SD. Support
for this has been upstream in CUPS for some time -- it's what CUPS uses
on Mac OS X -- but is not functional with Avahi. (For Fedora, I have
added patches to support Avahi.)
This means that once CUPS drops support for CUPS Browsing, automatic
CUPS queue discovery *will require Avahi* to be running on both the
server (i.e. the system hosting the CUPS queue) and the clients (i.e.
the systems wanting to print to it).
Some Filters Moving To New Home
-------------------------------
Apple is removing some filters from CUPS as they are not needed for Mac
OS X. These filters will be maintained in a new "cups-filters" project
at OpenPrinting.
As part of this move, Till Kamppeter will be merging the existing PDF
Workflow filters¹ into that effort.
The main purpose of this email was to raise awareness of the CUPS
Browsing/Avahi issue.
Till Kamppeter's email about the CUPS 1.6 changes on the
printing-architecture list:
http://lists.linuxfoundation.org/pipermail/printing-architecture/2012/002...
Tim.
*/
¹
http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as...
11:11 a.m.
On Wed, Jan 18, 2012 at 16:43:33 GMT, Tim Waugh wrote:
This means that once CUPS drops support for CUPS Browsing, automatic
CUPS queue discovery *will require Avahi* to be running on both the
server (i.e. the system hosting the CUPS queue) and the clients (i.e.
the systems wanting to print to it).
For those of us that just have static printer setups, would it be
possible to make a cups-browse (or similar) subpackage which brings in
Avahi?
-- Ben
4:12 a.m.
On Wed, 2012-01-18 at 17:11 +0000, Ben Boeckel wrote:
For those of us that just have static printer setups, would it be
possible to make a cups-browse (or similar) subpackage which brings in
Avahi?
The dependency will be on libavahi-client and libavahi-common, which are
part of avahi-libs. These are hard dependencies as the scheduler will
link to those libraries.
Now that avahi-libs is a separate sub-package from the main avahi
package, it does not require the Avahi server.
So currently there is no dependency on the Avahi server, and I don't
expect that to change with CUPS 1.6.
Additionally, I expect the "BrowsePoll" directive in cupsd.conf will
still work in CUPS 1.6 as it does not use CUPS Browsing. It works by
periodically issuing IPP requests to the listed CUPS servers to fetch
information about their queues.
Tim.
*/
12:18 p.m.
On Thu, Jan 19, 2012 at 10:12:55 +0000, Tim Waugh wrote:
On Wed, 2012-01-18 at 17:11 +0000, Ben Boeckel wrote:
> For those of us that just have static printer setups, would it be
> possible to make a cups-browse (or similar) subpackage which brings in
> Avahi?
The dependency will be on libavahi-client and libavahi-common, which are
part of avahi-libs. These are hard dependencies as the scheduler will
link to those libraries.
Now that avahi-libs is a separate sub-package from the main avahi
package, it does not require the Avahi server.
Sounds good to me. Thanks.
--Ben
11:14 a.m.
Tim Waugh wrote:
Till Kamppeter's email about the CUPS 1.6 changes on the
printing-architecture list:
http://lists.linuxfoundation.org/pipermail/printing-architecture/2012/002...
What's the story about the PPD stuff Till is talking about there? That
scares me the most when I read that mail. Will this be supported by a patch
from openprinting.org? Seeing how Apple upstream is dropping features we
need, I wonder whether the best solution wouldn't be a full-blown fork of
CUPS, where your Avahi patches could also be merged to.
Kevin Kofler
4:21 a.m.
On Wed, 2012-01-18 at 18:14 +0100, Kevin Kofler wrote:
What's the story about the PPD stuff Till is talking about there?
That
scares me the most when I read that mail. Will this be supported by a patch
from openprinting.org? Seeing how Apple upstream is dropping features we
need, I wonder whether the best solution wouldn't be a full-blown fork of
CUPS, where your Avahi patches could also be merged to.
I'm not sure of the details. Here is the background:
The Printer Working Group is engaged in an effort called IPP
Everywhere¹. The goal is to have "driverless" printing by having a
small common set of imaging standards in printers, and for the printer
capabilities to be inspected using IPP.
There is no need for PPDs in this vision of how things will work in the
glorious future, "when" all printers support IPP Everywhere.
The way I expect it to work in CUPS 1.6 is that the concept of PPDs
disappears as far as clients to CUPS are concerned, but that it will
still use PPDs internally for existing printers that do not support IPP
Everywhere (that is to say, all of them right now).
In other words, I think the direction it is going is to make PPDs an
implementation detail of CUPS.
How that will work in practice I don't know yet.
Tim.
*/
¹ http://pwg-wiki.wikispaces.com/IPP+Everywhere
5:38 a.m.
On Thu, Jan 19, 2012 at 10:21:07AM +0000, Tim Waugh wrote:
On Wed, 2012-01-18 at 18:14 +0100, Kevin Kofler wrote:
> What's the story about the PPD stuff Till is talking about there? That
> scares me the most when I read that mail. Will this be supported by a patch
> from openprinting.org? Seeing how Apple upstream is dropping features we
> need, I wonder whether the best solution wouldn't be a full-blown fork of
> CUPS, where your Avahi patches could also be merged to.
I'm not sure of the details. Here is the background:
The Printer Working Group is engaged in an effort called IPP
Everywhere¹. The goal is to have "driverless" printing by having a
small common set of imaging standards in printers, and for the printer
capabilities to be inspected using IPP.
[...]
I'm still using a very servicable HP LaserJet 5M from ca.1996.
I wonder how the glorious future will be for me?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
5:50 p.m.
On Thu, 2012-01-19 at 10:21 +0000, Tim Waugh wrote:
The Printer Working Group is engaged in an effort called IPP
Everywhere¹. The goal is to have "driverless" printing by having a
small common set of imaging standards in printers, and for the printer
capabilities to be inspected using IPP.
What a great idea! We could call one of them 'Postscript'...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:12 p.m.
On Fri, 2012-01-20 at 09:25 +0000, Tim Waugh wrote:
On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote:
> What a great idea! We could call one of them 'Postscript'...
Not likely. :-)
I think the current candidate for the optional vector format is PDF
1.4/1.5.
Everything old is new again...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:23 a.m.
On Fri, Jan 20, 2012 at 01:12:26PM -0800, Adam Williamson wrote:
On Fri, 2012-01-20 at 09:25 +0000, Tim Waugh wrote:
> On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote:
> > What a great idea! We could call one of them 'Postscript'...
>
> Not likely. :-)
>
> I think the current candidate for the optional vector format is PDF
> 1.4/1.5.
Everything old is new again...
Particularly in the case of my HP JL 5M which does official
Postscript(TM) very nicely ... provided it's only Level 1 and can be
rendered in 2MB of RAM.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
11:28 a.m.
On 01/18/2012 04:43 PM, Tim Waugh wrote:
<snip>
....
</snip>
Has it been considered to ditch cups altogether ( or keep what's worth
keeping from it ) and coming up with a native printer client/server for
GNU/Linux?
JBG
4:24 a.m.
On Wed, 2012-01-18 at 17:28 +0000, "Jóhann B. Guðmundsson" wrote:
Has it been considered to ditch cups altogether ( or keep what's
worth
keeping from it ) and coming up with a native printer client/server for
GNU/Linux?
It's been considered, yes. For the time being it isn't beneficial to do
that. It isn't ruled out.
Tim.
*/
12:44 p.m.
New subject: Changes coming for CUPS 1.6 - PHP extension
Le 18/01/2012 17:43, Tim Waugh a écrit :
Although the latest version of CUPS is 1.5.0, development is
continuing apace on 1.6. There are some important changes coming
in 1.6 which deserve to be pointed out.
Another minor change, cups 1.6.0 will also, according to upstream,
drop support of the php extension (cups-php).
I will add the patch for cups 1.5.0 + php 5.4 and build it tomorrow...
Remi.
P.S. : http://www.cups.org/str.php?L3999
4488
days inactive
4491
days old
14 comments
7 participants
participants (7)
-
Adam Williamson -
Ben Boeckel -
Jóhann B. Guðmundsson -
Kevin Kofler -
Remi Collet -
Richard W.M. Jones -
Tim Waugh