Meeting called to order by Ira McDonald at 1pm US Eastern. Minutes taken by Ira McDonald.
Attendees
Agenda
- Progress report
- The Linux Foundation got accepted as mentoring organization by Google again!
- So now we are about to find the contributors we ant to work with. Many of those who have
already worked on OpenPrinting GitHub issues during our selection process have came up to
us, right on the day after Google has announced the Linux Foundation's participation,
suggesting which project idea they want to work on and some are already starting to work
on it.
- We are open for GSoC contributors, also non-students, like for example retired people
looking into getting involved, and especially people who join our OpenPrinting community,
stay with us, maintain, and improve their code, bring in new ideas, mentor contributors
in the following years, write on our web site, etc.
- We have posted everything you need to know for participating and our project ideas:
- GUI for discovering non-driverless printers and finding suitable Printer Applications
for them
- Scanning support in PAPPL
- Coverting Braille embosser support into a Printer Application
- cups-filters: In filter functions call Ghostscript via libgs and not as external
executable
- cups-filters: Add Avahi calls for discovering and resolving driverless IPP printers to
API and optimize the processes
- cups-filters: Create OCR filter to deliver scans as searchable PDFs
- Turn the scp-dbus-service methods - GetBestDrivers and MissingExecutables - of
system-config-printer into C
- We also appreciate any new project ideas brought up to us and narurally also contributors
suggesting their own ideas.
- And we already have one extra project idea since last month:
- Make a native Printer Application from Gutenprint
- GSoC 2022 Timeline
- DONE - 7 February 2022 - Mentoring organizations begin submitting applications to Google
- DONE - 21 February 2022 - Mentoring organization application deadline
- DONE - 21 February to 6 March 2022 - Google administrators review organization applications
- DONE - 7 March 2022 - List of accepted mentoring organizations published - LF accepted
- 7 March to 3 April 2022 - Potential GSoC contributors discuss with mentoring organizations
- 4 April - GSoC contributor application period begins
- 19 April 2022 - GSoC contributor application deadline
- 12 May 2022 - GSoC contributor slot requests due from Org Admins
- 20 May 2022 - Accepted GSoC contributor projects announced
- 20 May to 12 June 2022 - GSoC contributors meet mentors, read docs, get up to speed
- 13 June 2022 - Coding officially begins!
- 25 July 2022 - Mentors and contributors begin submitting Phase 1 evaluations
- 29 July 2022 - Phase 1 Evaluation deadline (standard coding period)
- 25 July to 4 September 2022 - GSoC contributors work with guidance from Mentors
- 5-12 September 2022 - Contributors final code/mentor evaluations (standard period)
- 12-19 September 2022 - Mentors submit final evaluations (standard period)
- 20 September 2022 - Initial results of Google Summer of Code 2022 announced
- 12 September to 13 November 2022 - Continue coding (extended period)
- 21 November 2022 - Contributors submit final code (extended period)
- 28 November 2022 - Mentors submit final evaluations (extended period)
- Progress report
- Till is getting closer to the release, the list of items to fix or ideas to still add
gets shorter. So we will see cups-filters 2.0 soon.
- This time Till worked on the imageto...() filter functions again and corrected the
centering of the image with print-scaling=none and the switching between fit-to-page
and no scaling with print-scaling=auto.
- Till also added support for grayscale (sGray 8-bit) PCLm printing support and added PCLm
output support to the gstoraster CUPS filter executable.
- By the way, Till got motivated to do this by discovering a driverless printer which
only supports PCLm, the HP LaserJet M15. Usually, driverless IPP printers also support
Apple Raster to allow printing from iOS devices via AirPrint.
- And finally, Till made the the universal CUPS filter work correctly with all PPD files.
If a PPD file specified a driver filter in a *cupsFilter2: "..." line, the
FINAL_CONTENT_TYPE environment variable was set to the output format of that filter (2nd
word of the string defined in the *cupsFilter2: "..." line) and not to its input format,
which would be what universal has to deliver. So before, the universal filter received a
wrong format as its destination format. Now the filter checks for *cupsFilter2: "..."
lines and corrects from the given format to the input format of the corresponding line as
destination format. Also when installing cups-filters using the universal filter we
install also the individual filters (the executables are little stubs anyway) as
sometimes they are called by the PPD file.
- Some smaller bugs and glitches got also fixed.
- The fixes on the imageto... filters are already backported to cups-filters 1.28.12 and
so included in Ubuntu 22.04 LTS (Jammy Jellyfish), the other fixes do not apply to the
1.x series.
- Mainly missing now is a bunch of log leaks to stderr in image processing functions, some
little known bugs, general code clean-up, license info in the source files, and then we
are ready for a Release Candidate.
- Progress report
- Till has also contributed to Ghostscript towards driverless printing this month. The
changes will be available from Ghostscript 9.56.0 on, which will get released in a few
days.
- First Till has added new appleraster and urf output devices to let Ghostscript generate
the Apple Raster (URF) format for driverless IPP printing. The change was trivial, as
Ghostscript already uses libcups to generate PWG Raster (with the cups or pwgraster output
devices) and one can switch these libcups functions to output Apple Raster instead by
changing a simple flag.
- Second, Till has posted a feature request for an output device to generate grayscale
(sGray 8-bit) PCLm output. The feature got implemented a few days later under the output
device name pclm8.
- Ghostscript now supports all standard data formats for driverless IPP printing as output
formats: PDF (pdfwrite, pdfimage8, pdfimage24, pdfimage32), PWG Raster (pwgraster), Apple
Raster (appleraster, urf), and PCLm (pclm, pclm8).
- Progress report - 625 printers certified for IPP Everywhere v1.0 - 216 printers certified for IPP Everywhere v1.1
- Progress report
- First, we are working on a prominent note that most modern printers are driverless on
our front page and an (automated?) list of available driverless IPP printers. See the
discussion in the issue report.
- Update: Michael Sweet has updated the front page now, adding a prominent hint that most
modern printers are driverless and also linked a list of driverless printers right from
the front page. Thanks a lot, Michael!
- The part of the web site for looking up (legacy, non-driverless) printers and drivers
(the OpenPrinting database web app has moved to a new server at Oregon State University
Open Source Lab (OSUOSL). As the old server did not receive a system upgrade for many
years there were a lot of problems with the compatibility of the code (SQL and PHP) with
the new, modern server.
- Fortunately, the people there, especially Violet Kurtz and Lance Albertson, both from the
OSUOSL, helped a lot on doing this migration by doing the needed code changes. Thanks a
lot to them!
- The UI of the web app did not change, but there are changes in the internal functionality.
Instead of feeding the complete Foomatic XML data into the MySQL database and from this
generate the PPD files which are identical with the ones we find in Linux distributions
(they usually create them with the foomatic-compiledb script directly from the XML data
which comes with the foomatic-db-engine package) we do the same as the distributions do
also on the server. We pre-build the PPD files with foomatic-compiledb and serve only the
content of the web pages from a (reduced) MySQL database. This saves us from too many SQL
fixes to do and server responses, especially when downloading PPD files should be faster.
- Also the query.php script for machine queries got fixed and is fully working again.
- This is especially important as we soon want to add a query service for printer setup
tools to find the correct Printer Application(s) for a printer based on its device ID.
- Note that the UI still needs some updating, especially removing obsolete links.
- If you find any bug, please report it on the bug tracker of the web app.
- Progress report - ipp-usb is available as a Snap in the Snap Store now (1729 downloads)
- Progress report - No update
- Progress report
- Current PAPPL release is v1.1.0 on 15 December 2021.
- All the CUPS-driver-retro-fitting Printer Applications in the Snap Store use the current
GIT master of PAPPL, so they contain all the latest fixes and improvements.
- See also the currently open and closed issues of PAPPL.
- Progress report - No update
- Progress report (February 2022)
- HPLIP v3.21.12 in all Printer Applications
- The HPLIP Printer Application (Snap Store) got its first update of the underlying HPLIP
version. It is now HPLIP v3.21.12. We continue using the Debian package sources to include
more than 80 bug fixes not adopted upstream. Sorry for the delayed updates due to this.
- The update adds explicit support for the new HP printer models that were released near the
end of 2021. Note that most of those printers should also work as driverless IPP printers
and therefore also work without the HPLIP Printer Application.
- The update worked out smoothly. If you have installed an HPLIP Printer Application version
which still uses HPLIP v3.21.8 and have the proprietary plugin installed, the plugin gets
updated right after the installation of the new version of the Printer Application. Note
that this can take several minutes and that during this time your printer will perhaps not
work.
- Not caused by the update, Till got a bug report that the automatic loading of the firmware
into printers which need it everytime when they are turned on did not work.
- As Till does not have such a printer, he had to do some tricky workaround for testing when
he developed this mechanism. Unfortunately, in the real situation this did not work out
(or at least not for the user who reported that problem).
- Fortunately, the reporter of the problem, M. Parker, was very enthusiastic and
cooperative, investigating the problem with the help of Till. Till told him how to debug
a Snap, as rebuilding it with some debug echo commands added to the script which controls
the firmware upload, and putting the script into debug mode. Before this, he also did some
Snap debugging already, and finally solved the problem!
- Thanks a lot for your great cooperation, M. Parker! You have made the automatic firmware
upload work!
- After that, Till updated also the HPLIP used in the PostScript Printer Application
(PostScript PPD files for HP printers, Snap Store) and in the Ghostscript Printer
Application (HPIJS for non-HP PCL-5c/e lasers, Snap Store) to the Debian package source of
HPLIP v3.21.12.
- All the OpenPrinting Snaps are updated to use QPDF v10.5.0 now.
- Progress report - Gutenprint is available as a Snap in the Snap Store now (3169 downloads)
- Progress report - HPLIP is available as a Snap in the Snap Store now (3847 downloads)
- Progress report - Ghostscript is available as a Snap in the Snap Store now (1143 downloads)
- Progress report - PostScript is available as a Snap in the Snap Store now (2257 downloads)
- Progress report (March 2022)
- The "cups" interface for Snaps of applications which print is completely implemented now!
What is missing are simply only the next stable releases of the components of the Snap
environment: snapd 2.55 and new stable releases of the core Snaps (core, core-base,
core18, core20). Once they are out, the new "cups" interface is ready to use.
- See the progress of our work and the updated TODO list.
- As we will see the needed releases probably already before next month's news post,
perhaps in around 2 weeks or so, Till will describe here how the final concept works and
how to snap an application with print functionality.
- How It Works
- Snaps are file systems in isolated sandboxes. A Snap is not able to access the file system
of another Snap (like the CUPS Snap for example) nor it is able to access the file system
of the host system (like for example the Unix socket of a classically installed CUPS).
- For exceptions from this isolation there are interfaces. They have well-defined
permissions what a Snap can access in the outside world. Snaps of user applications, like
LibreOffice, Darktable, etc. have so-called "plugs": network, avahi-observer, and cups.
These plugs are connected ("plugged") to so-called "slots", most of the host system but
some also of other Snaps (usually servers in a Snap, like the CUPS Snap).
- The packager of a Snap can decide which interfaces the packaged application plugs and so
they can have maximum security without losing functionality of the application. They
upload the Snap to the Snap Store and when a user installs it on their system, the
interfaces usually get auto-connected and the user can use the application without hassle.
- Now there are some interfaces through which you can do operations which are dangerous for
the system. One of them for example is the cups-control interface, which snapd provided
already from the beginning on and plugging it (to the system) allows your Snap not only to
list the available printers and to print on them, but also to do any administrative tasks
(creating and modifying queues, changing cupsd configuration, seeing and deleting other
user's jobs, etc.) on the system's classically installed (RPM, DEB, etc.) CUPS. In classic
systems you control this via the "lpadmin" group, but in the Snap world you do not have
any system groups.
- To avoid that arbitrary developers can upload Snaps to the Snap Store which plug such
"dangerous" interfaces and abuse them, compromising the system’s security, only selected
(not "dangerous") interfaces get auto-connected when installing from the Snap Store, other
interfaces need to get connected manually by the user (requires "root" access to the
system), or the developer of the Snap has to request a special permission for
auto-connection by the Snap Store team (they manage the list of which interfaces are
"dangerous" or not). The Snap Store team reviews the application and at least 2 members
have to be in favor of the auto-connection for it to be approved.
- Now when Till started to get printing into the Snap world several years ago, snapping CUPS
but also looking into how snapped applications can print, Till found out that the only way
to print out of a Snap was through the "dangerous" cups-control interface. The snapper of
an application had to plug this interface and request special permission from the Snap
Store for the interface's auto-connection on the user's machines, or the user had to
connect it manually, not really having printing "just work". In addition, this could lead
up to very many special permissions from the Snap Store team and raise the probability
that a developer abuses his permission by modifying his application.
- So Till started developing, together with the snapd developer team, the new cups
interface. All the development was accompanied by the snapcraft.io forum thread of the
initial feature request which Till started exactly one year ago, on 18 March 2021. There
were two pull requests on the snapd code, the first got dropped and the second got merged
around half a year after getting initially posted. After the merge, on 7 February 2022,
Till marked this thread as solved and started a second thread for the finalization.
- Now let us see how this interface works:
- An application with print functionality (like LibreOffice, Darktable, gedit, etc.) plugs
the cups interface. In contrary to cups-control the slot is not in the host system, but in
the CUPS Snap, always the CUPS Snap, even if the user uses a classically installed (RPM,
DEB, source, etc.) CUPS on his system. This means that the CUPS Snap gets auto-installed
(like a package dependency) during the installation of the application Snap when it is not
already on the system.
- The application Snap then mounts the CUPS Snap's /var/snap/cups/common/run directory into
its own file system's /var/cups directory and has this way access to the Unix socket of
the CUPS Snap's CUPS daemon, as /var/cups/cups.sock. This interaction between the two
Snaps is part of the cups interface. In addition, the cups interface sets the CUPS_SERVER
environment variable in the application Snap's sandbox to /var/cups/cups.sock so that the
application uses the CUPS Snap's CUPS.
- If there is no classically installed CUPS on the system, the CUPS Snap is running in its
standalone mode and is the system’s print environment, also for non-snapped, classically
installed applications (for which it then creates a second socket as the usual
/run/cups/cups.sock). So both the snapped and the unsnapped applications print happily via
the snapped CUPS.
- But what if there is a classic installation of CUPS on the user's system, with lots of
thoroughly manually created queues and even proprietary printer drivers which we cannot
migrate into a CUPS-Snap-based system? In this case the CUPS Snap sees that there is a
claasic CUPS configured and automatically starts in its proxy mode. This means the CUPS
Snap' CUPS daemon is a proxy for the system’s CUPS daemon. The CUPS Snap runs a helper
daemon (named cups-proxyd) along with its CUPS daemon and cups-proxyd observes the
system's CUPS and clones all its queues, as filterless pass-through queues but with the
same PPD files as the original queues, to have the same options and printer properties.
Every change on the system's classically installed CUPS is immediately synced into the
Snap's CUPS.
- But why that complicated for the most common situation of having a classically installed
CUPS on the system? Why running two CUPS daemons on one simple desktop machine? The Snap's
CUPS daemon in this configuration is a firewall for the system's CUPS daemon, it protects
it against administrative requests of the snapped application.
- In the beginning we said that the cups interface blocks administrative requests, but we
did not tell how. snapd does not understand IPP (Internet Printing Protocol) and so it
cannot filter out the unwished requests from the communication between the application and
the CUPS daemon. So who is best for understanding IPP? CUPS! So Till has implemented the
filtering in the CUPS daemon, the so-called Snap mediation. The CUPS daemon, if it is new
enough, 2.4.x in general, also some 2.3.x in case of Debian or Ubuntu packages, checks on
each administrative inquiry it receives whether it is from a confined Snap (only these you
can upload into the Snap Store without special permission). If so, it checks whether the
client Snap plugs cups-control and only then it accepts the request. Requests from
unsnapped clients or classic Snaps are not blocked. As we are explaining the mechanisms of
the cups interface, our client plugs cups and not cups-control and so its administrative
requests get rejected and our CUPS is safe.
- The CUPS Snap only exists with a Snap-mediating CUPS, at least at the time of launch of
the cups interface with snapd 2.55, but actually already for many months, since Till
implemented the Snap mediation. This way with the cups interface forcing the application's
CUPS communication through the Snap's CUPS we are for sure blocking the unwished requests.
If we let the snapped application communicate directly with the system's CUPS, we cannot
be sure that the administrative requests are blocked, as classically installed CUPS
daemons can be too old or the package maintainer could have opted for building CUPS
without Snap mediation. We need to keep in mind that Snaps are distribution-independent
packages, and each distribution's classic CUPS package can be different. Therefore we
need the CUPS Snap as proxy.
- This way we can safely install application Snaps. They plug cups and therefore can print
but not mess up CUPS, whatever CUPS the user prefers to use. Developers can easily snap
their applications with print functionality and upload them to the Snap Store, without
questions asked and easily installable by the user, so that his printing "just works".
- How To Snap An Application
- Snapping an application with print functionality is easy, do not get turned away by the
rather complicated inner workings.
- First, you start your snapping the same way as you are used to for applications without
print functionality. Read about this part elsewhere.
- Second, in snapcraft.yaml let each app with print functionality plug the cups interface.
- Third, add the placeholder content interface to trigger the auto-installation of the CUPS
Snap.
- Do not put this into any section, put it right after the header part for example. Simply
copy and paste the whole blob of lines. Nothing needs to get adapted to your particular
Snap, nor you have to create any directories in your Snap for that to work.
- Note: Having to add these lines is only a temporary workaround. The default-provider
functionality is planned to be added to the cups interface in snapd in the coming months.
When this has taken place, all that is needed to use the cups interface is plugging cups
as described in the second step here.
- Fourth, build your Snap as you are used to, test it, and upload it into the Snap Store
using your habitual method. If a user installs it, the CUPS Snap gets auto-installed and
the cups interface auto-connected and printing out of the Snap "just works".
- DO NOT plug both cups and cups-control in the same Snap. This can mess up things,
especially as CUPS' Snap mediation works "per-Snap" not "per-application-in-the-Snap",
meaning that if one of the apps in the Snap plugs cups-control CUPS assumes the whole
Snap plugging cups-control and allows all apps in the Snap to do administrative
operations.
- Thanks
- Thanks a lot to Till's colleagues in the Desktop and snapd teams of Canonical for the
great collaboration and team work to get the cups interface designed and implemented:
Ian Johnson, James Henstridge, Samuele Pedroni, Alex Murray, Alberto Mardegan.
- And also thanks to Michael Sweet for the helping with the smooth integration of the Snap
mediation into the CUPS code.
- Flatpak and Printing
- Till has talked a lot about Snap and integration of printing in the Snap ecosystem here
in the news posts and also on many conferences, but Snap (from Canonical, the company
behind Ubuntu) is not the only system for sandboxed packaging. Flatpak (coming from
freedesktop.org, popular in the RedHat world) is also common.
- Till asked Zdenek Dohnal from Red Hat and Zdenek and Felipe Borges, a colleague of his at
Red Hat told Till about how it works with printing and Flatpak.
- As Snap, Flatpak packages are distribution independent. The developer uploads a single
Flatpak of his application and everyone can use it, independent of the Linux distribution
in use.
- First, Flatpak is only for packaging user applications, and not for system components,
system or server applications, daemons, etc., or even a base system. So there will be no
CUPS Flatpak, nor Flatpaks of Printer Applications.
- Especially this way, Flatpak is not suitable as a platform to distribute printer and
scanner drivers as distribution-independent packages. So currently we have no alternative
to Snap to provide the complete "printing just works" experience. This is somewhat sad as
there are Linux distributions which are not systemd-based and so are not compatible with
Snap, and there are Snap denyers, too.
- Also users who trust more the "original from upstream" than a distro package of CUPS
cannot follow their preference by a simple Flatpak install as we cannot provide a Flatpak
of CUPS.
- Second, Flatpaked user applications communicate with the host system/the outside world
through so-called Portals, so for printing they use the Printing Portal.
- But in contrast to Snap's interfaces the Portal is not an AppArmor permission to access a
certain part of the host system (or another Snap) or a mount of certain parts of the
host's (or another Snap's) file system, but instead, it is a D-Bus API which provides
common GUI dialogs for common tasks (choose file, save file, print, etc.), where the
dialog comes from the desktop environment (GNOME or KDE) and so is the one of the desktop
environment, a common dialog and is de-coupled from the user application via the D-Bus
interface. So when using the GNOME desktop and printing from a Flatpaked KDE app we should
see GNOME's print dialog.
- Those of you who have followed the activity of the OpenPrinting project already for a long
time, perhaps remember our effort on the "Common Print Dialog" (not the "Common Print
Dialog Backends" we are currently trying to establish). That was the same idea, but only
for printing that time. To not confuse users with different print dialogs for different
applications, we wanted to provide the print dialog from the desktop environment (GNOME or
KDE) and the applications using the D-Bus in order to print, also with a well-defined
D-Bus API. Unfortunately, we had to give up on this project as we had neither volunteers
nor someone financing a developer for us.
- There is the portal frontend, xdg-desktop-portal which provides the D-Bus interface inside
the sandbox and there are portal backends, one for each desktop environment, to provide
the actual functionality, as the dialogs and also the communication with the host system.
In order to print, the application has to call appropriate D-Bus methods, first for
opening the dialog and getting the user's selection of the printer and the option settings
back, and another method call to send the job data formatted according to the user's
choices.
- Modern GNOME and KDE applications are supposed to use appropriate high-level APIs which
auto-discover whether the app is inside a Flatpak sandbox and print (and use other common
dialogs) via D-Bus instead of popping up the GUI library's dialog.
- Problem here is that we have older apps, non-GNOME/GTK/KDE/Qt apps, and especially
closed-source apps, and generally apps not using the appropriate APIs. If they are free
software we can at least patch them for the Flatpak, but this is rather invasive for
packaging a user application. In addition, only interactive desktop applications which
print through dialogs are covered. Non-GUI applications usually talk directly to CUPS (via
libcups) or call command line utilities to print and so they need to get invasively
modified for printing.
- In Snaps the user applications do not need to be changed, nor need to have Snap-specific
functionality already included. snapd connects the original CUPS interface into the
application's sandbox and so the application can do the same thing as it was doing without
sandbox.
- So it seems that Flatpak is highly specialized for sandbox-packaging desktop applications
with GUI, whereas Snap is more general, allowing to sandbox-package practically
everything, especially allowing also the use for headless servers.
- Thanks to Zdenek and Felipe for their explanations about Flatpak.
- Progress report
- LPrint v1.1.0 was released on 23 December 2021 by Mike Sweet.
- LPrint is available as a Snap in the Snap Store now.
- LPrint the Printer Application for label printers, created by Michael Sweet, has now been
switched over to be PAPPL-based and with this it is the first PAPPL-based, native
(non-PPD-retro-fitting) production Printer Application.
- So not only does it give you support for many label printer models (if your label printer
is not supported, some more are supported by the Ghostscript Printer Application), but it
also is an example for developers who want to create their own native Printer Application.
- Project report
- PDFio v1.0.0 was released on 14 December 2021 by Mike Sweet.
- PDFio is a simple library for reading and writing PDF files, but it is not a PDF
renderer/rasterizer. So it does similar things to the QPDF library, but using only simple
C, rather than C++. PDFio does not replace renderers like Ghostscript or Poppler.
- Till is thinking about switching cups-filters from QPDF to PDFio, to make libcupsfilters
free of C++, but PDFio still does not support converting filled interactive PDF forms into
static PDF files. A feature request is posted. This could also be a project for GSoC 2022.
- CUPS (Mike and Zdenek)
- Current release is OP CUPS v2.4.1 on 22 January 2022.
- There will be further bug fix releases in the 2.4.x series. An important bug fixed
recently is that with v2.4.1 (or earlier) you cannot create a print queue with lpadmin
using a DNS-SD-service-name-based URI (output of driverless command) and the -m everywhere
option to auto-generate a PPD for driverless printing (Issue #340, Issue #343). This is
fixed now.
- Till also discovered a bug that prevents printing to temporary queues for driverless
printers on localhost (IPP-over-USB with ipp-usb, Printer Applications) from the GTK print
dialog. Till found a fix for this, posted it as Pull request #353, and applied it as
distro patch to Ubuntu's CUPS package. Problem here is that the GTK dialog does all the
client's work on its own instead of using the convenience APIs of libcups. GTK's
implementation does not replace the network host name in the URI of the local service
(coming from Avahi) by "localhost" when the service comes via the loopback (lo) device.
In the pull request, Till let the CUPS daemon correct this when creating the temporary
queue.
- Ubuntu Jammy Jellyfish (22.04 LTS) will come with 2.4.1, perhaps with 2.4.2 if it gets
released in time for Final Freeze on April 14, 2022.
- The CUPS Snap and our CUPS-driver-retro-fitting Printer Application Snaps use the current
GIT master of CUPS.
- CUPS 2.4.2 planned changes (Mike, Zdenek)
- Fixed CSS related issues in CUPS Web UI (Issue #344)
- Fixed copyright in CUPS Web UI trailer template (Issue #346)
- mDNS hostname in device uri is not resolved when installaling a permanent IPP Everywhere
queue (Issues #340, #343)
- CUPS Filters Summary (Till)
- Current release is v1.28.13 on 27 March 2022.
- We are continuing to polish and to fix bugs for the v2.0.0 release. Till has especially
done image centering corrections in the imageto...() filter functions, added grayscale
PCLm output support, fixed the universal CUPS filter to work with all PPD files.
- Till has also backported the fixes on the imageto... filters to cups-filters 1.x,
included in the v1.28.12 release.
- Ubuntu Jammy Jellyfish (22.04 LTS) will come with cups-filters v1.28.12. The CUPS Snap
currently uses cups-filter’s GIT master (2.x). The Printer Application Snaps also use the
current GIT master of cups-filters.
- CUPS Filters release v1.28.13 on 27 March 2022 (Till)
- Bug fix release, for correct printing on printers which take in the paper long-edge-first
and for Apple LaserWriter printers.
- pdftopdf: Fix N-up printing when paper is taken long-edge-first by the printer.
- pdftopdf: Fix cropping ("print-scaling=none" and "print-scaling=fill") when paper is taken
long-edge-first by the printer (Issue #454).
- pdftops: Use Poppler for all Apple LaserWriter models (Issue #452).
- CUPS Filters release v1.28.12 on 17 February 2022 (Till)
- imagetoraster, imagetopdf: Fixed comparison of the image size with the page size for
print-scaling=auto. The image size in pixels was compared with the page size in PostScript
points (1/72 inch).
- imagetoraster, imagetopdf: Fixed the "print-scaling=none" (crop-to-fit) mode, also use
crop-to-fit always when requested, do not fall back to fit-to-page when the image size
differs significantly from the page size (Issue #362).
- libcupsfilters: Changed the default PPI resolution for images as input files from 128 to
200 (Pull request #446).
- implicitclass: Do not check availability of "gs" and "pdftops" executables, instead, check
by the presence of "gstoraster" and "pdftoraster" filters whether we have configured
cups-filters for Ghostscript and/or Poppler use.
- libcupsfilters: In the PPD generator for the driverless utility and cups-browsed add
"*cupsFilter2: ..." lines for all supported driverless data formats (PDF, Apple/PWG
Raster, PCLm), and add lines for legacy data formats (PCL, PostScript) only if no
driverless formats available.
- libcupsfilters: Always use encryption for ipps. RFC7472 requires that 'ipps' must be used
over HTTPS, but the driverless utility does not enforce encryption (Pull request #433).
- serial: Add a 10-msec sleep and at the end add a tcdrain(). For some unknown reason, every
printing file needs to sleep a little time to make sure the serial printer receive data is
right (Pull request #431).
- libcupsfilters: Fix resolver functions for DNS-SD-based URIs, to make resolve_uri() also
work when DEVICE_URI env variable is set and to make ippfind_based_uri_converter() not
re-direct stdin.
- pdftopdf: Set default for print-scaling to avoid "should never happen" log messages and
undefined behavior.
- pdftopdf: Fix orientation-requested = 0. Consider this as "automatic selection" and not
as error.
- pdftopdf: Fixed all combinations of print-scaling and number-up for printers with
asymmetric margins (top != bottom or left != right) and for input files containing pages
with different sizes and/or orientations. Fixes backported from 2.x branch.
- pdftopdf: Add 2% tolerance for input size larger than output page when
"print-scaling=auto" or "print-scaling=auto-fit" is used and too large input pages should
be scaled, fitting documents not. This prevents a random-looking behavior if input and
output page size seem to be equal, but in reality there are slight dependencies between
size dimensions.
- Joint PWG/OP Summit Virtual F2F - 17-19 May 2022 - Ira/Till to attend
- https://www.pwg.org/chair/meeting-info/meetings.html
- Status of AMSC and ISO liaisons w/ PWG (Paul Tykodi)
- http://ftp.pwg.org/pub/pwg/general/sc/pwg-sc-call-minutes-20220110.htm
- http://ftp.pwg.org/pub/pwg/general/sc/pwg-sc-call-minutes-20220124.htm
- http://ftp.pwg.org/pub/pwg/general/sc/pwg-sc-call-minutes-20220307.htm
- see PWG Steering Committee minutes from 01/10/22, 01/24/22, 03/07/22
- PWG Hardcopy Device Security Guidelines v1.0 - Interim draft
- https://ftp.pwg.org/pub/pwg/ids/wd/wd-idshcdsec10-20220208-rev.pdf
- for a Best Practice
- PWG F2F review on 9 February 2022
- Schedule - Prototype draft in Q3/Q4 2022
- IPP Everywhere v1.1 Printer Self-Certification Tools Update 4 (Mike)
- https://www.pwg.org/archives/ipp/2022/021097.html
- v1.1 Tools Update 4 last call on 26 February 2022
- IPP Everywhere v1.1 certifications required after 1 July 2021
- IPP Workgroup Charter (Ira) - PWG Approved
- http://ftp.pwg.org/pub/pwg/ipp/charter/ch-ipp-charter-20210409.pdf
- update for new IPP WG projects
- PWG Approved on 9 April 2021
- IPP INFRA Cloud Proxy Registration (Cihan, Mike) - proposed
- https://www.pwg.org/archives/ipp/2020/020688.html
- https://ftp.pwg.org/pub/pwg/ipp/slides/ipp-wg-agenda-november-20.pdf
- for a Registration (near-term)
- minor update of IPP System Service and IPP Infrastructure Printing
- offline discussions with Microsoft about Universal Printing coherence
- PWG Virtual F2F discussion on 6 May 2021
- Schedule - TBD
- Deprecating IPP Print-by-Reference (Mike)
- https://www.pwg.org/archives/ipp/2021/021045.html
- RFC: Deprecate the Print-URI and Send-URI operations and related attributes and values
- IPP WG Last Call started 2 November 2021 ended 15 December 2021
- Schedule - IPP WG approved on 13 January 2022
- IPP Finishings v3.0 (Smith) - Prototype draft
- https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfinishings30-20220207-rev.pdf
- for a Candidate Standard
- major update of PWG 5100.1-2017
- PWG Last Call started 22 February 2022 extended to 4 April 2022
- Schedule - Candidate Standard in Q2 2022
- IPP Enterprise Printing Ext v2.0 (Smith) - Prototype draft
- https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippepx20-20211101-rev.pdf
- for a Candidate Standard
- PWG status at PWG Virtual F2F on 8 February 2022
- Schedule - Stable draft in Q2/Q3 2022
- IPP Production Printing Ext v2.0 (Mike) - Prototype draft
- https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippppx20-20211020-rev.pdf
- for a Candidate Standard
- major update of PWG 5100.3-2001
- PWG status at PWG Virtual F2F on 8 February 2022
- Waiting on prototyping in ippsample
- Schedule - Stable draft in Q2/Q3 2022
- IPP Driverless Printing Extensions v2.0 (Smith) - Prototype draft
- https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippnodriver20-20220222-rev.pdf
- for a Candidate Standard
- major update of PWG 5100.13-2012
- PWG status at PWG Virtual F2F on 8 February 2022
- IPP WG review on 24 February 2022
- Schedule - Stable draft in Q2/Q3 2022
- IPP Encrypted Jobs and Documents (Mike/Smith) - Prototype draft
- https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrustnoone10-20210519-rev.pdf
- for a Candidate Standard
- PWG status at PWG Virtual F2F on 8 February 2022
- Waiting for prototyping
- Schedule - Stable draft in Q1 2022
- IPP 2.x (Mike/Ira) - Interim draft
- https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippbase23-20220124.pdf
- major update of PWG 5100.12-2015
- PWG review at PWG Virtual F2F on 9 February 2022
- Schedule - Prototype draft in Q2/Q3 2022
- IPP Everywhere v2.0 (Mike/Ira) - Interim draft
- https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve20-20220124-rev.pdf
- major update - for a Candidate Standard
- PWG review at PWG Virtual F2F on 9 February 2022
- Schedule - Prototype draft in Q3/Q4 2022
- IQPC Automotive Cybersecurity Summit 29-31 March 2022 - Ira to speak - https://www.automotive-iq.com/events-automotive-cybersecurity - IEEE 1609 WG Virtual F2F - 5 April 2022 - Ira to attend - https://standards.ieee.org/develop/wg/1609.html - IACR Real World Crypto Hybrid F2F (Amsterdam) - 13-15 April 2022 - Ira to attend - https://rwc.iacr.org/2022/ - ISO TC22/SC32/WG12 AdHoc Virtual F2F - 19 April 2022 - Ira to attend - https://www.iso.org/standard/77796.html (ISO DIS 24089, Automotive Software Update) - US NIST Lightweight Crypto Workshop Virtual F2F - 9-11 May 2022 - Ira to attend - https://csrc.nist.gov/events/2022/lightweight-cryptography-workshop-2022 - Joint PWG/OP Summit Virtual F2F - 17-19 May 2022 - Ira/Till to attend - https://www.pwg.org/chair/meeting-info/meetings.html - IEEE 1609 WG Virtual F2F - 24 May 2022 - Ira to attend - https://standards.ieee.org/develop/wg/1609.html - ISO TC22/SC32/WG12 Virtual F2F - 30 May to 3 June 2022 - Ira to attend - https://www.iso.org/standard/77796.html (ISO DIS 24089, Automotive Software Update) - ESCAR USA F2F (Detroit) - 15-16 June 2022 - Ira to attend (in-person) - https://www.escar.info/escar-usa.html - UPTANE Workshop F2F (Detroit) - 17 June 2022 - Ira to attend (in-person) - https://uptane.github.io/ - IEEE 1609 WG Virtual F2F - 21 June 2022 - Ira to attend - https://standards.ieee.org/develop/wg/1609.html - TCG Members Meeting Hybrid F2F (Chevy Chase, MD) - 18-22 July 2022 - Ira to attend - https://trustedcomputinggroup.org/ - IETF 114 Hybrid F2F (Philadephia, PA) - 25-29 July 2022 - Ira to attend - https://www.ietf.org/how/meetings/114/ - IEEE 1609 WG Virtual F2F - 16 August 2022 - Ira to attend - https://standards.ieee.org/develop/wg/1609.html
Open Action Items
Next OP US/Europe/Brazil/India Conference Calls
- Tuesday 12 April 2022, Daytime
- Web conference to be announced
- Note - US Daylight Savings Time starts 13 March 2022
- Note - EU Summer Time starts 27 March 2022
- US
10am in San Francisco - US PDT (Pacific Daylight Time)
11am in Colorado - US MDT (Mountain Daylight Time)
12am in Chicago - US CDT (Central Daylight Time)
1pm in New York - US EDT (Eastern Daylight Time)
- Europe
7pm in Berlin - CEST (Central Europe Summer Time)
- Brazil
2pm in Belo Horizonte - BRT (Brasilia Time)
- India
10:30pm in New Delhi - IST (India Standard Time)
- Tuesday to Thursday 17-19 May 2022 - Ira/Aveek/Till to attend
- Tuesday 7 June 2022, Daytime
- Web conference to be announced
- US
10am in San Francisco - US PDT (Pacific Daylight Time)
11am in Colorado - US MDT (Mountain Daylight Time)
12am in Chicago - US CDT (Central Daylight Time)
1pm in New York - US EDT (Eastern Daylight Time)
- Europe
7pm in Berlin - CEST (Central Europe Summer Time)
- Brazil
2pm in Belo Horizonte - BRT (Brasilia Time)
- India
10:30pm in New Delhi - IST (India Standard Time)