[Printing-architecture] OpenPrinting News

Till Kamppeter till.kamppeter at gmail.com
Wed Feb 13 18:14:20 UTC 2019


here is the newest development of the last month.



Google Summer of Code 2019

The org application of the Linux Foundation is submitted and on Feb 26 
we will know whether we got accepted by Google.


Also Red Hat is bumping into the fact that Avahi is unmaintained 
upstream, see discussion as answer to our minutes from last month:


Michael Sweet writes:

A bug was filed against CUPS last month requesting that we start 
supporting systemd's new mDNS resolver (which apparently is replacing 
the use of Avahi in systemd?!?):


I pushed back since there does not appear to be a way to browse DNS-SD 
SRV records and there is no interface for registering services outside 
of systemd configuration files.  But that might be a future alternative 
to Avahi should they extend the current interfaces to support it...

Zdenek Dohnal from Red Hat writes:

I talked about both issues with Michal Sekletar, which is systemd and
avahi maintainer for RHEL and the situation is following:

1) systemd-resolved as successor of nss-mdns module:

     As far as Michal knows, systemd-resolved is not currently meant as
successor of nss-mdns module + avahi since it does not support service
browsing as Mike found out. If it will in the future, he does not know
right now (probably how avahi situation will turn up...).

2) Avahi upstream maintenance

    Michal and several other people tried to convince Trent to pass
ownership to someone else (Michal knew about two people, who would like
to take Avahi project at that time) about two years ago, because Trent
seemed to do not have time for the project. But Trent did not want to
give away the upstream project. Currently Michal fixes Avahi issues
downstream in Fedora/RHEL.

My suggestion:

As Debian does not accept carrying patches distro only with upstream not
taking them and also as it is very awkward if all distros have to carry
the same patch due to upstream not caring, and naturally also an
integral part of the OS needs solid upstream maintainership, this is an
unbearable situation.

It would be great if someone could convince Trent to accept a
co-maintainer who also can directly commit to and also issue releases of
Avahi. If Trent refuses this, I see as the only solution the forking of
the project. This is the usual way how one handles these situations.

The current official Avahi repo is


so it is under the personal domain of Trent and not a project domain as
for example


where cups-filters, ippusbxd and others are.

So I checked


and there is something which has nothing to do with Avahi. We should ask
the owner whether he could move his GitHub activity to another name to
free avahi for us and then we put our fork of Avahi there.

If this does not work out I suggest to host the Avahi fork on GitLab.

Or should we fork Avahi under a new name then?

According to Zdenek, Michal tried this with the co-maintainership already.

Seems that Trent is refusing any cooperation or completely ignoring the 

My suggestion is to fork the project and use one of the locations 
suggested by me, but who should be the upstream maintainer then.


No new releases.

When working on this cups-filters bug report


I discovered that CUPS uses 4 different variants of the 
get-printer-attributes IPP request at 4 places, so for one and the same 
printer 4 different PPD files can get generated, depending on the method 
how one creates a print queue for the driverless IPP printer. I have 
reported this to CUPS as a bug and Mike has fixed it on both 2.2.x and 




Currently released is 1.22.0.

 From this release on the pdftopdf filter flattens interactive PDF forms 
and annotations internally, using QPDF, instead of calling external 
utilities. This especially eliminates slowing factors as additional 
piping of the data and unneeded use of PDF interpreters. Using external 
utilities for flattening is still possible in case of problems. In 
addition, a crash bug in cups-browsed got fixed and compatibility of the 
filters with Poppler 0.72 assured.

The form-flattening with QPDF was already planned 2 years ago as GSoC 
project, but the student did not complete his work. Jay Berkenbilt, 
upstream maintainer of QPDF, completed the work (the code is practically 
completely in QPDF), released a new version of QPDF with this included, 
and told me what to call from pdftopdf during the new-year break. Note 
that Jay is doing all that voluntarily. Also Tobias Hoffmann, former 
GSoC student and mentor, helped on this.

The next release will (1.22.1) will still happen before Ubuntu's Feature 
Freeze (Feb 21) and mainly switch the get-printer-attributes IPP calls 
to the way how CUPS does it now.


	- cups-browsed, driverless: When polling the printer's
           capabilities via get-printer-attributes IPP request for
           driverless printing, use the attributes "all" and
           "media-col-database". Without "all" some printers do not
           report "urf-supported" and without "media-col-database" not
           all paper size and marging info gets reported (Issue #22,
           Pull request #86, CUPS issue #5484).
	- braille: Document how to rework output before
	  embossing. Thanks to Samuel Thibault for this patch (Pull
	  request #90).


	- pdftopdf: Use QPDF for flattening interactive PDF forms
	  (Issues #2, #23, #36, Pull request #88).
	- pdftopdf: Fixed bug of closing temporary file prematurely
	  when external PDF form flattening utilities fail (Thanks to
	  Tobias Hoffmann for finding this, see pull request #88).
	- pdftoopvp: More fixes for building with Poppler 0.72
	  (Pull request #83, Issue #75).
	- pdftoraster, pdftoijs, pdftoopvp: Removed support for
	  Poppler 0.18 (Pull request #83).
	- cups-browsed: Fixed crash in applying the BrowseFilter
	  cups-browsed.conf directives (Debian bug #916765).


No further news.

More information about the Printing-architecture mailing list