[Printing-architecture] OpenPrinting News
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.
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
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
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.
CHANGES IN V1.22.1
- 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
CHANGES IN V1.22.0
- 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