Page not found :(
-The requested page could not be found.
-The printer advertises itself by DNS-SD, with a summary of its most important capability information (especially also its PDLs and a one-line-string super summary in case of AirPrint printers) in its DNS-SD record.
The client polls the full capabilities info from the printer sending a get-printer-attributes IPP request. The printer returns a long list of info, especially paper sizes and types, unprintable margins, resolutions, input trays, finishers, quality settings, all user-settable options etc..
CUPS or cups-browsed on the client generate PPD files from this info and create print queues for each printer.
The print dialogs of the applications show the printers and allow access to all the user-settable options.
The user prints a job. The PDF from the application is turned into one of the PDLs which the printer supports by cups-filters. The settings selected by the user are passed along with the job as IPP attributes.
The printer prints the job and thanks to IPP the status can be observed, toner levels and any errors can get reported to the client.
If the printer is shut down, its queue will get automatically removed. So no clutter of print queues as souvenir of all the networks you have visited.
-The Internet Printing Protocol (IPP) does not only support printing, but also scanning, as there are many printers which also have a scanner (multi-function (MF) devices). Both CUPS and the developer tool ippserver emulate IPP network printers but not IPP scanners and so they cannot serve as a server to share a local scanner. -
- -### Student Tasks - --This task is about adding the scan server functionality. If you have a scanner connected locally (and it scans via SANE), share it as an IPP scanner, advertising itself and accepting jobs using the IPP driverless scanning standard. In contrary to SANE-based network scanning clients with any operating system, also phones or IoT devices can scan on your shared scanner. -
- --Also old hardware can be recycled to a modern MF device, and we have a sample implementation to motivate manufacturers to adopt IPP scanning. -
- --This server software will be a so-called Scanner Application, a sample implementation of the future form of scanner drivers, easily packageable in sandboxed, distribution-independent package formats like Snap. -
- -### Mentors - --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), SANE upstream developers TBD -
- -### Desired Knowledge --C programming, DNS-SD, IPP -
- -### Code License --Apache 2.0 -
- diff --git a/_gsoc2019/03-sane-module.md b/_gsoc2019/03-sane-module.md deleted file mode 100644 index 88693bad..00000000 --- a/_gsoc2019/03-sane-module.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: SANE module for IPP driverless scanning ---- - -### Introduction - --Version 2.0 and newer of the Internet Printing Protocol (IPP) support polling the full set of capabilities of a printer and if the printer supports a known Page Description Language (PDL), like PWG Raster, Apple Raster, PCLm, or PDF, it is possible to print without printer-model-specific software (driver) or data (PPD file), so-called “driverless” printing. This concept was introduced for printing from smartphones and IoT devices which do not hold a large collection of printer drivers. Driverless printing is already fully supported under Linux. Standards following this scheme are IPP Everwhere, Apple AirPrint, Mopria, and Wi-Fi Direct Print. -
- --As there are many multi-function devices (printer/scanner/copier all-in-one) which use the IPP, the Printing Working Group (PWG) has also worked out a standard for IPP-based scanning, “driverless” scanning, to also allow scanning from a wide range of client devices, independent of which operating systems they are running. -
- --Conventional scanners are supported under Linux via the SANE (Scanner Access Now Easy) system and require drivers specific to the different scanner models. Most of them are written based on reverse-engineering due to lack of support by the scanner manufacturers. To get driverless scanning working with the software the users are used to the best solution is to write a SANE module for driverless IPP scanning. This module will then automatically support all IPP scanners, thousands of scanners where many of them do not yet exist. -
- --Even if there are no driverless IPP scanners on the market yet, this module can be used for accessing scanners with their driver provided as Scanner Application (see previous project in this list). -
- -### Student Tasks - --The student's task is to write this SANE module for IPP driverless scanning and so make Linux ready for the future of driverless devices. -
- -### Mentors --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), SANE upstream developers TBD -
- -### Desired Knowledge --C programming, DNS-SD, IPP -
- -### Code License --GPL 2+ -
diff --git a/_gsoc2019/06-linux-gui-application.md b/_gsoc2019/06-linux-gui-application.md deleted file mode 100644 index 5218c196..00000000 --- a/_gsoc2019/06-linux-gui-application.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Linux GUI application (can be part of GNOME printer tool) to admin MF devices using IPP System Service. ---- - -### Introduction - --Most network printers have a web interface which allows to configure the printer from any computer in the network using a web browser. Advantage is that no printer-model-specific software needs to be installed on the computer in order to configure a printer, and one has no dependency on certain supported operating systems. One can even configure printers using a smartphone. -
- --Disadvantage is that every manufacturer does its web interface differently which makes administration of many printers of different brands awkward. In addition, automated printer administration with scripts requires different interfaces for each printer. And for setting local print queues you open your printer setup tool but for printer administration you have to open your browser. -
- --To make this easier the Printing Working Group (PWG) has introduced the IPP System Service standard. This is an interface made up of standardized IPP requests to poll printer capabilities and configure the printer as needed. Every printer from every manufacturer uses the same requests and so a common printer configuration interface can be added to printer setup tools or automated administration with scripts is possible. -
- -### Student Tasks --The student's task will be to create an appropriate printer configuration interface for system-config-printer or for the GNOME Control Center. -
- -### Mentors --Upstream developers of GNOME/GTK or system-config-printer TBD. -
- -### Desired Knowledge --C and/or Python programming, GTK -
- -### Code License --GPL 2+ or LGPL 2+ -
diff --git a/_gsoc2019/08-foomatic-generating-cups-ppd-generator.md b/_gsoc2019/08-foomatic-generating-cups-ppd-generator.md deleted file mode 100644 index af235b1c..00000000 --- a/_gsoc2019/08-foomatic-generating-cups-ppd-generator.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Foomatic Generating CUPS PPD generator (/usr/share/cups/drv/\*.drv files) from Foomatic data ---- - -### Introduction - --CUPS has two mechanisms for on-the-fly-PPD generation to avoid the wasting of disk space by thousands of uncompressed (or slightly compressed) PPD files. One is to put an executable file into the /usr/lib/cups/driver/ directory which lists and generates PPD files on request, the other is using *.drv files in /usr/share/cups/drv, which contain the data for the PPDs in a simpler and more compact format. -
- --The former method is deprecated upstream and can be removed in a future release of CUPS, especially also because the executables can get slow in some cases. -
- --The latter is not yet supported by Foomatic and letting Foomatic support it is subject of this project idea. -
- -### Student Tasks --The student's task is to create a utility which generates *.drv files from the whole database and/or from selected, printers, manufacturers, drivers, groups, …, depending on what the user requests. -
- -### Mentor --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com) -
- -### Desired Knowledge --Perl programming, perhaps also MySQL -
- -### Code License --GPL -
diff --git a/_gsoc2019/09-add-printer-output-backends-to-mupdf.md b/_gsoc2019/09-add-printer-output-backends-to-mupdf.md deleted file mode 100644 index 31e54447..00000000 --- a/_gsoc2019/09-add-printer-output-backends-to-mupdf.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: Add printer output backends to MuPDF ---- - -### Introduction --MuPDF is a lightweight PDF renderer made by Artifex, the company behind Ghostscript. In contrary to Ghostscript, MuPDF is a pure PDF renderer. It does not contain a PostScript interpreter nor parts of it are written in PostScript. This makes it smaller, faster, and less resource-consuming, the ideal solution for mobile devices like tablets or smartphones. -
- --On mobile devices printing will not be done with having tons of printer-model-specific drivers on the system. Once, they consume the limited mass storage space, and second, one uses the mobile device in several different local networks with different printers: At home, in the office, in a copy shop, … and one wants to use the printers which are available there, without installing drivers and setting up queues. -
- --Therefore we want to have a system which automatically detects network printers and makes them available for local apps. To do so we restrict ourselves to printers with known, common languages: IPP Everywhere/AirPrint/Mopria/W-Fi Direct (driverless printing standards, using PWG Raster, Apple Raster, PCLm, and PDF) and PostScript, PDF, PCL 5c/e/6/XL (legacy standards). So MuPDF has to generate raster output for these languages, meaning raster embedded in the specifics of the language, and to avoid exhausting printer resources raster in small bands and no high-level output, even if the printer language is high-level. -
- --Artifex will also work on this, but to get additional man power we are also opening this project for students. -
- --Note that you have to assign copyright on your code to Artifex, as otherwise the code cannot be integrated in MuPDF. -
- --This project can be split to be worked on by more than one student. -
- -### Mentors --MuPDF developers TBD, Till Kamppeter, Project Leader OpenPrinting (till at linux dot com) -
- -### Desired Knowledge --C and/or C++ programming -
- -### Code License --GPL -
diff --git a/_gsoc2019/10-common-print-dialog.md b/_gsoc2019/10-common-print-dialog.md deleted file mode 100644 index 91c75f9c..00000000 --- a/_gsoc2019/10-common-print-dialog.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Common Print Dialog Qt implementation ---- - -### Introduction - --The Qt Print Support framework should be updated with the CPD support. The goal is to provide the CPD GUI features and d-bus communications with the CPD backend support for printing from Qt5 applications on support platforms. -
- -### Student Tasks --Based on the GSoC work of the previous year, one example of Qt CPD implementation outside of Qt Print Support can be found at: https://github.com/rithvikp1998/CPDv2. For this task, the implementation is expected to start with QPrintDialog instead. -
- -### Mentors --Dongxu Li (dongxuli2011 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD -
- -### Desired Knowledge --C++ programming, Qt, CUPS -
- -### License --Qt Contribution Agreement -
\ No newline at end of file diff --git a/_gsoc2019/11-scp-dbus-service-into-c.md b/_gsoc2019/11-scp-dbus-service-into-c.md deleted file mode 100644 index b170d7a5..00000000 --- a/_gsoc2019/11-scp-dbus-service-into-c.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Turn the scp-dbus-service of system-config-printer into C ---- - -### Introduction - --system-config-printer was the default printer setup tool in Red Hat/Fedora Linux for a lot of time and also got adopted by Ubuntu around ten years ago. During this time it received a lot of development work, especially on the algorithms for finding the best driver for a printer and for identifying whether printer discovery results from the CUPS backends actually come from the same physical printer. -
- --To make these algorithms available for other printer setup tools (both interactive GUI tools and programs which fully automatically create print queues without user interaction) they got moved into a D-Bus service, scp-dbus-service. Now every other program can simply call the needed function via a D-Bus API. The printer setup tool in the GNOME Control Center for example works this way. -
- --system-config-printer was written in Python and therefore scp-dbus-service is also written in Python. This makes it depending on Python and also makes it loading the needed Python libraries into memory when started. This can cause delays during boot when a utility to auto-setup print queues is used.Also most printer setup tools are written in C, Therefore it makes sense to convert the D-Bus service into the C language. -
- -### Student Tasks --The student's task is to turn the scp-dbus-service of system-config-printer into C, either as D-Bus service (would work out-of-the-box with many GUIs) or as a C library with API (simpler), ideally both. This will make it easier to write printer setup tools in practically any programming language. -
- -### Mentors --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), system-config-printer upstream developers TBD -
- -### Desired Knowledge --Desired knowledge: C/C++ programming, Python programming -
- -### Code License --GPL 2+ or MIT -
diff --git a/_gsoc2019/12-gcp-desktop-solution-for-local-cups-printers.md b/_gsoc2019/12-gcp-desktop-solution-for-local-cups-printers.md deleted file mode 100644 index b969d733..00000000 --- a/_gsoc2019/12-gcp-desktop-solution-for-local-cups-printers.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Google Cloud Print - Desktop-integrated solution for registering local CUPS printers ---- - -### Introduction --Google Cloud Print is a service from Google which allows to print from anywhere with internet access to anywhere else with internet access, for example from a mobile phone to printer at home or in the office. -
- --To do so, one needs a Google account and there one registers one's printers so that they can accept jobs sent into the print facility of this Google account. -
- --On Linux there is already a way to share the local CUPS printers into Cloud Print: The Chrome/Chromium Browser. In its settings you can activate Google Cloud Print and the local queues get registered. The Browser even leaves a user daemon running when one closes it to continue keeping the printers available for Cloud Print. -
- --The disadvantage of this is that the functionality is bound to a web browser, so it is awkward for people who use Firefox for example. -
- --Do not suggest now to make the CUPS daemon (daemon which handles the print jobs) or cups-browsed (daemon which browses the network for printers and automatically creates local queues for them) registering the printers, as they are system-wide services and Google Cloud Print is based on the user's Google account, and so something which belongs to a single user. -
- -### Student Tasks --What is needed is a user daemon which starts when logging in and stops when logging out, running with the rights of the user, connecting to the user's Google account registering the local CUPS printers the user is allowed to print on. It will need integration with the desktop for starting and stopping the daemon and for configuration in the desktop's settings utility. -
- --Ideally it should work with the GNOME desktop using GNOME Online Accounts and the GNOME settings manager. -
- --Google documentation for printer registration. -
- -### Mentors --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Ubuntu/GNOME GUI developers TBD -
- -### Desired Knowledge --C/C++ programming, GUI programming, GTK -
diff --git a/_gsoc2019/13-print-files-from-file-manager.md b/_gsoc2019/13-print-files-from-file-manager.md deleted file mode 100644 index a7720bbc..00000000 --- a/_gsoc2019/13-print-files-from-file-manager.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Printing of files directly from the file manager ---- - -### Introduction - --Sometimes you browse through your files and see some files which you want to print, files in completely different formats: PDFs, photos, LibreOffice files, … It is awkward to double-click each file, one-by-one, to get it opened in its application, and then click “Print” in each application. It would be much easier to mark all these files, right-click and then click “Print” in the context menu. -
- -### Student Tasks --Here the student's task is to add this functionality to a popular file manager, for example the one of GNOME. -
- -### Mentors --Aveek Basu (basu dot aveek at gmail dot com), upstream developers of GNOME/GTK TBD. -
- -### Desired Knowledge --C programming, GTK -
- -### Code License --LGPL 2+ -
diff --git a/_gsoc2019/14-cairo-color-management-code.md b/_gsoc2019/14-cairo-color-management-code.md deleted file mode 100644 index 4582dcbd..00000000 --- a/_gsoc2019/14-cairo-color-management-code.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Get the cairo color management code upstream ---- - -### Introduction - --Adrian Johnson did a lot of the work needed to make cairo color managed. Finishing this work and getting the code upstream would allow us to simplify a lot of applications that use cairo. See http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space for the branch. Adrian has also patched Inkscape to use the new features, and that needs cleaning up and pushing upstream http://cgit.freedesktop.org/~ajohnson/inkscape/log/?h=color-space Also see http://lists.cairographics.org/archives/cairo/2012-July/023353.html and https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for more details. -
- -### Expectations --Expectations: The cairo and inskcape code is pushed upstream with any required modifications. Ideally someone familiar with the cairo community would take this on, as Adrian found it hard to get the code approved upstream. -
- -### Skills --Understanding of basic color management, basic use of bzr and git, proficient in C. -
- -### Mentors --Richard Hughes (hughsient at gmail dot com) -
diff --git a/_gsoc2020/02-common-print-dialog.md b/_gsoc2020/02-common-print-dialog.md deleted file mode 100644 index a3364611..00000000 --- a/_gsoc2020/02-common-print-dialog.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Common Print Dialog Backends (CPDB) Qt implementation" ---- - -### Introduction --The Qt Print Support framework should be updated with the CPD support. The goal is to provide the CPD GUI features and d-bus communications with the CPD backend support for printing from Qt5 applications on support platforms. -
- --Based on the GSoC work of the previous year, one example of Qt CPD implementation outside of Qt Print Support can be found at: https://github.com/rithvikp1998/CPDv2. For this task, the implementation is expected to start with QPrintDialog instead. -
- -### Mentors --Dongxu Li (dongxuli2011 at gmail dot com), Nilanjana Lodh, first implementor of the CPDB (nilanjanalodh at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD -
- -### Desired Knowledge --C++ programming, Qt, CUPS -
- -### License --Qt Contribution Agreement -
diff --git a/_gsoc2020/03-ipp-scan-application.md b/_gsoc2020/03-ipp-scan-application.md deleted file mode 100644 index 232e3234..00000000 --- a/_gsoc2020/03-ipp-scan-application.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "IPP scan (or virtual MF device) server (Scanner Application)" ---- -### Introduction --The Internet Printing Protocol (IPP) does not only support printing, but also scanning, as there are many printers which also have a scanner (multi-function (MF) devices). Both CUPS and the developer tool ippserver emulate IPP network printers but not IPP scanners and so they cannot serve as a server to share a local scanner. -
- --This task is about adding the scan server functionality. If you have a scanner connected locally (and it scans via SANE), share it as an IPP scanner, advertising itself and accepting jobs using the IPP driverless scanning standard. In contrary to SANE-based network scanning clients with any operating system, also phones or IoT devices can scan on your shared scanner. -
- --Also old hardware can be recycled to a modern MF device, and we have a sample implementation to motivate manufacturers to adopt IPP scanning. -
- --This server software will be a so-called Scanner Application, a sample implementation of the future form of scanner drivers, easily packageable in sandboxed, distribution-independent package formats like Snap. -
- -### Mentors --Alexander Pevzner, “airscan” SANE backend author (pzz at apevzner dot com), Thierry Hucahrd, “escl” SANE backend author (thierry at ordissimo dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com, Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), SANE upstream developers TBD -
- -### Desired Knowledge --C programming, DNS-SD, IPP -
- -### Code License --Apache 2.0 -
diff --git a/_gsoc2020/04-sane-module.md b/_gsoc2020/04-sane-module.md deleted file mode 100644 index bfd6eb1a..00000000 --- a/_gsoc2020/04-sane-module.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "SANE module for IPP driverless scanning" ---- - -### Introduction --Version 2.0 and newer of the Internet Printing Protocol (IPP) support polling the full set of capabilities of a printer and if the printer supports a known Page Description Language (PDL), like PWG Raster, Apple Raster, PCLm, or PDF, it is possible to print without printer-model-specific software (driver) or data (PPD file), so-called “driverless” printing. This concept was introduced for printing from smartphones and IoT devices which do not hold a large collection of printer drivers. Driverless printing is already fully supported under Linux. Standards following this scheme are IPP Everwhere, Apple AirPrint, Mopria, and Wi-Fi Direct Print. -
- --As there are many multi-function devices (printer/scanner/copier all-in-one) which use the IPP, the Printing Working Group (PWG) has also worked out a standard for IPP-based scanning, “driverless” scanning, to also allow scanning from a wide range of client devices, independent of which operating systems they are running. -
- --Conventional scanners are supported under Linux via the SANE (Scanner Access Now Easy) system and require drivers specific to the different scanner models. Most of them are written based on reverse-engineering due to lack of support by the scanner manufacturers. To get driverless scanning working with the software the users are used to the best solution is to write a SANE module for driverless IPP scanning. This module will then automatically support all IPP scanners, thousands of scanners where many of them do not yet exist. -
- --Even if there are no driverless IPP scanners on the market yet, this module can be used for accessing scanners with their driver provided as Scanner Application (see previous project in this list). -
- --The student's task is to write this SANE module for IPP driverless scanning and so make Linux ready for the future of driverless devices. -
- -### Mentors --Alexander Pevzner, “airscan” SANE backend author (pzz at apevzner dot com), Thierry Hucahrd, “escl” SANE backend author (thierry at ordissimo dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com, Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), SANE upstream developers TBD -
- -### Desired Knowledge --C programming, DNS-SD, IPP -
- -### Code License --GPL 2+ -
\ No newline at end of file diff --git a/_gsoc2020/07-cups-browsed-printer-app.md b/_gsoc2020/07-cups-browsed-printer-app.md deleted file mode 100644 index 3e46853e..00000000 --- a/_gsoc2020/07-cups-browsed-printer-app.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Turn cups-browsed into printer application" ---- - -### Introduction --cups-browsed is a daemon which discovers remote printers, mainly IPP but also legacy CUPS browsing, and makes them locally available. It gives a lot of possibilities for configuration, like clustering printers so that the most suitable for a job is automatically selected, allowing access to printers from legacy servers, showing only the relevant printers from thousands of printers available on the network, … -
- --Currently it makes printers locally available by creating a queue on the locally running CUPS, and generating a PPD file for this queue. As PPD files in CUPS are deprecated and the support for them will soon go away, cups-browsed will have to follow, and the best way to do so, is to make a Printer Application from it. Instead of creating CUPS queues it will emulate IPP printers then, which get picked up automatically by CUPS. -
- --The student's task here is to add IPP server functionality (icluding DNS-SD advertising) to cups-browsed. cups-browsed is already a Glib-based multi-function daemon, so adding a service should not be that much difficult. Nothing of the existing functionality should be removed, the user should be able to select between local queue creation or IPP server by the configuration file. -
- --A plus, when there is time left, would be a configuration interface, ideally using IPP System Service. -
- -### Mentors --Deepak Patankar (patankardeepak04 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD -
- -### Desired Knowledge --C programming, IPP, CUPS -
- -### Code License --LGPL-2.1+ -
diff --git a/_gsoc2020/09-wrapping-proprietary-drivers.md b/_gsoc2020/09-wrapping-proprietary-drivers.md deleted file mode 100644 index 4b940b99..00000000 --- a/_gsoc2020/09-wrapping-proprietary-drivers.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Wrapping Proprietary Drivers into Printer Applications" ---- - -### Introduction --With sandboxed packaging, Linux distributions appear which do not use classic RPM or DEB packages any more, like the all-Snap Ubuntu Core. And also standard desktop and server distributions, like Ubuntu Desktop/Server, will convert more and more to Snaps. Especially CUPS will also be moved from a classic package to a snap. Then CUPS will not work with classic PPD/filter-based printer drivers any more but requires all drivers being provided as Printer Applications. -
- --Free software printer drivers can easily get converted, starting from rebuilding them to live inside a Snap, where everything is in other directories than in a usual system up to integrating its printer capability infoand filter algorithms directly into the IPP server daemon. -
- --Proprietary, closed-source printer drivers come as binary RPM or DEB files, or tarballs, or even self-extracting. They require a certain, in classic systems usually available, file system structure to put their files in during installation, and they also need some libraries which are common in classic systems. In a snap you do not have this “standard” file system structure and the binaries with hard-coded paths in them choke on that. -
- --A solution is to take the Printer Application framework and add a chroot to it. The proprietary driver will get installed in that chroot then. -
- --The student's task is to add this functionality to the Printer Application framework and create an easy way for users to install proprietary printer drivers into that chroot-equipped Printer Application. -
- -### Mentors --Dheeraj Yadav (dhirajyadav135 at gmail dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD -
- -### Desired knowledge --C programming, IPP -
- -### Code license --(L)GPL 2+, Apache 2.0, MIT -
diff --git a/_gsoc2020/10-gutenprint-printer-application.md b/_gsoc2020/10-gutenprint-printer-application.md deleted file mode 100644 index c9315b78..00000000 --- a/_gsoc2020/10-gutenprint-printer-application.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Gutenprint Printer Application" ---- - -### Introduction --Gutenprint is a printer driver for high-quality inkjet printing which is under continuous development for many years already and supports hundreds of printers. It is popular under users of both Linux and Mac OS X. -
- --Currently, it supports printing either the classic CUPS way, by a PPD generator and a filter or by a plug-in for the GIMP. It should be rather easy to add more ways of using the core driver functionality, as this functionality is in a library, all capability information of the supported printers, dithering and color correction algorithms, … -
- --The new mode of using this library should be a new Printer Application which will be the student´s task to create. The Gutenprint printer application should wrap the Gutenprint library and so support all the printers the library supports. The basic structure can be like the Printer Application framework but here we do not want to create the (deprecated) PPD files but instead, let the IPP server link directly with the library and serve out the printer capability information on client's get-printer-attributes requests. Also see Michael Sweet's work on PAPPL. -
- -### Mentors --Dheeraj Yadav (dhirajyadav135 at gmail dot com), Michael Sweet, author of CUPS/LPrint/PAPPL and original creator of Gutenprint (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gutenprint developers, TBD -
- -### Desired knowledge --C programming, IPP -
- -### Code license --(L)GPL 2+, Apache 2.0, MIT -
\ No newline at end of file diff --git a/_gsoc2020/11-ipp-fax-out.md b/_gsoc2020/11-ipp-fax-out.md deleted file mode 100644 index a4d55e54..00000000 --- a/_gsoc2020/11-ipp-fax-out.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Support for IPP Fax Out" ---- - -### Introduction --Modern network multi-function devices (printer, scanner, fax) provide driverless operation (meaning no device/model-specific software or data is needed to use them). The device advertises itself on the network via DNS-SD providing a summary of its features and capabilities. Then a client can access the device using standard HTTP and IPP protocols to poll detailed capability info to be able to use the device and do the actual operation with the same communication protocols and standardized data formats for the images scanned or to be printed. -
- --Current Linux distributions already support the printing part via IPP and there is also already upstream code for scanning via AirScan (eSCL) to appear in the distributions soon and the open IPP Scan standard is subject of another project in this GSoC. Also the standard for device configuration (IPP System Service) is subject of other projects in this GSoC list. -
- --What is missing is IPP Fax out. This is a standard, very similar to driverless IPP printing for sending faxes. Principally sending a fax can be done by printing a file to a special destination in the device, accompanied with a phone number (required) and some fax-specific options (like how to proceed on failure or cover sheets, …) as IPP attributes. -
- --One can easily determine whether a device supports this and poll all needed capabilities. The DNS-SD record of the device's printing part (“_ipp._tcp”) does not report only the URI extension for printing (“rp=ipp/print”) but also for fax (“rfo=ipp/faxout”, no extra DNS-SD record!). If there is such an entry one can poll the URI “ipp://host:port/ipp/faxout” with a get-printer-attributes IPP request as it was a printer, and one gets the capabilities for the device-internal fax destination. The “driverless” utility of cups-filters happily generates a PPD from this, but naturally without fax-specific options, and if you create a CUPS queue with this URI and PPD and print a file with “lp -d queue -o phone=0012345678 file” the device will fax the file to the given number. The feature is commonly available in modern devices and I have actually tested it as described here. -
- --The student's task here is to make this functionality easily accessible for users of common desktop Linux distributions. Like printers, faxes should automatically appear on the system and get available in print dialogs and if one prints to a fax, fax-specific options should also appear in the print dialog and the user should be able to pick phone numbers also from contacts. -
- --This can be done by expanding existing resources and creating new ones in the printing stack. Especially one should think here abour the Common Print Dialog Backends (CPDB), but also other projects, like cups-filters would perhaps need changes. -
- -### Mentors --Nilanjana Lodh, first implementor of the CPDB (nilanjanalodh at gmail dot com), Dongxu Li (dongxuli2011 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD -
- -### Desired knowledge --C/C++ programming, CUPS, IPP -
- -### Licenses --MIT, Apache, GPL 2+ -
\ No newline at end of file diff --git a/_gsoc2020/12-scp-dbus-service-into-c.md b/_gsoc2020/12-scp-dbus-service-into-c.md deleted file mode 100644 index 55d781c7..00000000 --- a/_gsoc2020/12-scp-dbus-service-into-c.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Turn the scp-dbus-service methods - GetBestDrivers and MissingExecutables - of system-config-printer into C" ---- - -### Introduction --system-config-printer was the default printer setup tool in Red Hat/Fedora Linux for a lot of time and also got adopted by Ubuntu around ten years ago. During this time it received a lot of development work, especially on the algorithms for finding the best driver for a printer and for identifying whether printer discovery results from the CUPS backends actually come from the same physical printer. -
- --To make these algorithms available for other printer setup tools (both interactive GUI tools and programs which fully automatically create print queues without user interaction) they got moved into a D-Bus service, scp-dbus-service. Now every other program can simply call the needed function via a D-Bus API. The printer setup tool in the GNOME Control Center for example works this way. -
- --GNOME Control Center uses two methods - GetBestDrivers and MissingExecutables - for its printer setup. The GetBestDrivers method is used for finding the right printer drivers from ones which are available on the system. The MissingExecutables method is checking method, which is run after finding the best driver and checks if any additional software is needed for getting the printer functional. -
- --system-config-printer was written in Python and therefore scp-dbus-service is also written in Python. This makes it depending on Python and also makes it loading the needed Python libraries into memory when started. Also most printer setup tools are written in C, Therefore it makes sense to convert the D-Bus service into the C language. -
- --The student's task is to turn the two mentioned methods of system-config-printer into C, first as a C library with API, then as a D-Bus service (would - work out-of-the-box with many GUIs) if the C library will be finished. This will make it easier to use those methods in other print tools in practically any programming language. -
- -### Mentors --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), system-config-printer upstream developer Zdenek Dohnal (zdohnal at redhat dot com) -
- -### Desired knowledge --C/C++ programming, Python programming, autoconf/automake(creating configure and Makefile), basic testing -
- -### Code license --GPL 2+ or MIT -
diff --git a/_gsoc2020/14-roll-paper-support.md b/_gsoc2020/14-roll-paper-support.md deleted file mode 100644 index a30865e8..00000000 --- a/_gsoc2020/14-roll-paper-support.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Real roll paper support in cups-filters" ---- - -### Introduction --Currently, most probably due to the fact that once most printers use paper in cut sheet and also PPD (PostScript Printer Description, now deprecated) files only support paper in cut sheet, roll paper as used in large-format and also some specialty prrinters is not actually supported. -
- --The difference of roll paper against sheet paper is that only its width is defined, the height of the printing area can be selected individually for each print job. -
- --What the user expects to happen is that the paper is cut right after the page so that nothing is wasted and the user has minimum work with manual cutting. He also would like pages to be rotated by 90 degrees if they fit better this way, for example if the page height fits into the roll's width. This saves paper and allows pages which are too wide for the roll to be printed. An option to activate this (auto), never rotate, or always rotate should be added. -
- --Also some way to manage paper consumption and preventing a page being started which does not fit into the remaining paper is desired. -
- --The student's task is to add this functionality into the current print workflow. -
- --He should at first study the IPP (Internet Printing Protocol) standard for its roll paper support. Then he should check where changes are needed: in CUPS, cups-filters, print dialogs … Also it has to be investigated whether this can be completely implemented in the current (deprecated) PPD-based printing workflow or whether the new Printer-Application-based model is required. -
- -### Mentors --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD -
- -### Desired knowledge --C programming, IPP -
- -### Code license --(L)GPL 2+, Apache 2.0, MIT -
diff --git a/_gsoc2020/15-printer-output-backendto-mupdf.md b/_gsoc2020/15-printer-output-backendto-mupdf.md deleted file mode 100644 index 1b272aee..00000000 --- a/_gsoc2020/15-printer-output-backendto-mupdf.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Add Printer output backend to MuPDF" ---- - -### Introduction --MuPDF is a lightweight PDF renderer made by Artifex, the company behind Ghostscript. In contrary to Ghostscript, MuPDF is a pure PDF renderer. It does not contain a PostScript interpreter nor parts of it are written in PostScript. This makes it smaller, faster, and less resource-consuming, the ideal solution for mobile devices like tablets or smartphones. -
- --On mobile devices printing will not be done with having tons of printer-model-specific drivers on the system. Once, they consume the limited mass storage space, and second, one uses the mobile device in several different local networks with different printers: At home, in the office, in a copy shop, … and one wants to use the printers which are available there, without installing drivers and setting up queues. -
- --Therefore we want to have a system which automatically detects network printers and makes them available for local apps. To do so we restrict ourselves to printers with known, common languages: IPP Everywhere/AirPrint/Mopria/W-Fi Direct (driverless printing standards, using PWG Raster, Apple Raster, PCLm, and PDF) and PostScript, PDF, PCL 5c/e/6/XL (legacy standards). So MuPDF has to generate raster output for these languages, meaning raster embedded in the specifics of the language, and to avoid exhausting printer resources raster in small bands and no high-level output, even if the printer language is high-level. -
- --Artifex will also work on this, but to get additional man power we are also opening this project for students. -
- --Note that you have to assign copyright on your code to Artifex, as otherwise the code cannot be integrated in MuPDF. -
- --This project can be split to be worked on by more than one student. -
- -### Mentors --MuPDF developers TBD, Till Kamppeter, Project Leader OpenPrinting (till at linux dot com) -
- -### Desired knowledge --C and/or C++ programming -
- -### Code License --GPL -
diff --git a/_gsoc2020/16-print-files-directly-from-manager.md b/_gsoc2020/16-print-files-directly-from-manager.md deleted file mode 100644 index fb59bb9b..00000000 --- a/_gsoc2020/16-print-files-directly-from-manager.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Printing of files directly from the file manager" ---- - -### Introduction --Sometimes you browse through your files and see some files which you want to print, files in completely different formats: PDFs, photos, LibreOffice files, … It is awkward to double-click each file, one-by-one, to get it opened in its application, and then click “Print” in each application. It would be much easier to mark all these files, right-click and then click “Print” in the context menu. -
- --Here the student's task is to add this functionality to a popular file manager, for example the one of GNOME. -
- -### Mentors --Aveek Basu (basu dot aveek at gmail dot com), upstream developers of GNOME/GTK TBD. -
- -### Desired knowledge --C programming, GTK -
- -### Code License --LGPL 2+ -
diff --git a/_gsoc2020/17-get-cairo-code-upstream.md b/_gsoc2020/17-get-cairo-code-upstream.md deleted file mode 100644 index 57260bfe..00000000 --- a/_gsoc2020/17-get-cairo-code-upstream.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Get the Cairo color management code upstream" ---- - -### Introduction --Adrian Johnson did a lot of the work needed to make cairo color managed. Finishing this work and getting the code upstream would allow us to simplify a lot of applications that use cairo. See http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space for the branch. Adrian has also patched Inkscape to use the new features, and that needs cleaning up and pushing upstream http://cgit.freedesktop.org/~ajohnson/inkscape/log/?h=color-space Also see http://lists.cairographics.org/archives/cairo/2012-July/023353.html and https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for more details. -
- -### Expectations --The cairo and inskcape code is pushed upstream with any required modifications. Ideally someone familiar with the cairo community would take this on, as Adrian found it hard to get the code approved upstream. -
- -### Required Skills --Understanding of basic color management, basic use of bzr and git, proficient in C. -
- -### Contact --Richard Hughes (hughsient at gmail dot com) -
diff --git a/_includes/archive-single-post.html b/_includes/archive-single-post.html deleted file mode 100644 index 51cdace0..00000000 --- a/_includes/archive-single-post.html +++ /dev/null @@ -1,44 +0,0 @@ -{% if post.header.teaser %} - {% capture teaser %}{{ post.header.teaser }}{% endcapture %} -{% else %} - {% assign teaser = site.teaser %} -{% endif %} - -{% if post.id %} - {% assign title = post.title | markdownify | remove: "" | remove: "
" %} -{% else %} - {% assign title = post.title %} -{% endif %} - -{{ post.excerpt | markdownify | strip_html | truncate: 160 }}
{% endif %} -" | remove: "
" }}{% endif %} - {% include post__meta.html %} --With sandboxed packaging, Linux distributions appear which do not use classic RPM or DEB packages any more, like the all-Snap Ubuntu Core. As a result CUPS will not work with classic PPD/filter-based printer drivers any more but requires all drivers being provided as Printer Applications. The student's task is to add this functionality to the Printer Application framework and create an easy way for users to install proprietary printer drivers into that chroot-equipped Printer Application. -
- -### Mentors --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Aveek Basu, Project Manager (basu dot aveek at gmail dot com) -
- -### Desired Knowledge --C programming, C++ programming, Python Programming -
- -### Code License --GPL 2+ or LGPL 2+ -
diff --git a/_lfmp2020/02-Support-IPP-Fax-Out.md b/_lfmp2020/02-Support-IPP-Fax-Out.md deleted file mode 100644 index 2d3418bc..00000000 --- a/_lfmp2020/02-Support-IPP-Fax-Out.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Support for IPP Fax Out" ---- - -### Introduction --IPP Fax out is a feature which is currently missing in Linux unlike Print and Scan. The student's task here is to make this functionality easily accessible for users of common desktop Linux distributions. Like printers, faxes should automatically appear on the system and get available in print dialogs and if one prints to a fax, fax-specific options should also appear in the print dialog and the user should be able to pick phone numbers also from contacts. -
- -### Mentors --Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Aveek Basu, Project Manager (basu dot aveek at gmail dot com) -
- -### Desired Knowledge --C++ programming, Qt, CUPS -
- -### License --Qt Contribution Agreement -
diff --git a/_lfmp2020/03-ipp-scan-application.md b/_lfmp2020/03-ipp-scan-application.md deleted file mode 100644 index 0908c0a2..00000000 --- a/_lfmp2020/03-ipp-scan-application.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "IPP scan (or virtual MF device) server (Scanner Application)" ---- -### Introduction --The Internet Printing Protocol (IPP) does not only support printing, but also scanning, as there are many printers which also have a scanner (multi-function (MF) devices). Both CUPS and the developer tool ippserver emulate IPP network printers but not IPP scanners and so they cannot serve as a server to share a local scanner. -
- --This task is about adding the scan server functionality. If you have a scanner connected locally (and it scans via SANE), share it as an IPP scanner, advertising itself and accepting jobs using the IPP driverless scanning standard. In contrary to SANE-based network scanning clients with any operating system, also phones or IoT devices can scan on your shared scanner. -
- --Also old hardware can be recycled to a modern MF device. -
- --This server software will be a so-called Scanner Application, a sample implementation of the future form of scanner drivers, easily packageable in sandboxed, distribution-independent package formats like Snap. -
- -### Mentors --Alexander Pevzner, “airscan” SANE backend author (pzz at apevzner dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Aveek Basu, Project Manager (basu dot aveek at gmail dot com) -
- -### Desired Knowledge --C programming, C++ programming, Printing -
- -### Code License --Apache 2.0 -
diff --git a/_pages/contact.md b/_pages/contact.md deleted file mode 100644 index 71624e96..00000000 --- a/_pages/contact.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Contact Us" -permalink: /contact/ -layout: collection -header: - overlay_color: "#000" - overlay_filter: "0.5" - overlay_image: /assets/images/contact_us.jpeg -excerpt: "Feel Free To Contact Us!" -author_profile: false ---- -## Our Mailing lists -We protect the e-mail addresses of our mailing lists against spam bots. Please replace all occurrences of “ at ” and “ dot ” by “@” and “.” resp. - -- **Development:** printing-architecture AT lists DOT linux DOT dev ([Archive](https://lore.kernel.org/printing-architecture/)) -- **Users:** printing-users AT lists DOT linux DOT dev ([Archive](https://lore.kernel.org/printing-users/)) - -Subscribing/Unsubscribing [instructions](https://subspace.kernel.org/subscribing.html) - -## Telegram -- Main chat room: [OpenPrinting](https://t.me/+RizBbjXz4uU2ZWM1) - -## Mastodon -- [#OpenPrinting](https://ubuntu.social/tags/OpenPrinting) -- [@till@ubuntu.social](https://ubuntu.social/@till) - -## LinkedIn -- [@OpenPrinting](https://www.linkedin.com/company/openprinting/posts/) diff --git a/_pages/gsoc-2020-students.html b/_pages/gsoc-2020-students.html deleted file mode 100644 index 78e823bb..00000000 --- a/_pages/gsoc-2020-students.html +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: default -title: GSOC 2020 Students -header: - overlay_color: "#616161" -layout: splash -permalink: /gsoc-2020-students/ ---- - -
- IPP scan server (Scanner Application)
-
- CPDB Qt implementation
-
- General Printer Application SDK
-
- Make Printer Applications configurable
-
- Speed/scaling optimization of cups-browsed
-
- Linux GUI Application to admin MF devices using IPP System Service
-
- Extract raster data from PDFs for direct printing
-
- Make All Filter Functions Work Well Even Without PPD Files
-
- GUI for listing and managing available IPP services
-
- Firmware and other file handling in PAPPL
-
- Create a single universal CUPS filter to replace the chain of individual filters
-
- CUPS Filters: Converting Filters to Filter Functions
--Important: We protect the e-mail addresses of our mentors and mailing lists against spam bots. Please replace all occurrences of “ at ” and “ dot ” by “@” and “.” resp. -
- --Mailing list: printing-architecture at lists dot linux-foundation dot org -
- --IRC: #openprinting on Freenode -
- - - --Code License: See project descriptions -
- --The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com). -
- --Please see the plans for our near future work to get an overview of our development direction and architecture changes. -
- --
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
-Student: Vikrant Malik
Mentors: Sahil Arora, Till Kamppeter
- Work Product
-
PASSED
- - -Student: Jai Luthra
Mentors: Mentors: Michael Sweet, Till Kamppeter
- Work Product
-
PASSED
- Jai has principally worked on PAPPL but also done an HP PCL sample Printer Application. In the end he has also worked on converting filters of cups-filters into filter functions. - - -Student: Lakshay Bandlish
Mentor: Michael Sweet
- Work Product
-
PASSED
- - -Student: Sambhav Dusad
Mentor: Michael Sweet
- Work Product
-
PASSED
- - Sambhav has also started to create a Gutenprint Printer Application. - - - - - -Student: Mohit Mohan
Mentors: Deepak Patankar, Till Kamppeter
- Work Product
-
PASSED
- - -Student: Priydarshi Singh
Mentor: Dongxu Li
- Work Product
-
FAILED(final evaluation)
- We are looking into finishing up CPDB after GSoC. - - -Student: Aakash Lahoti
Mentors: Michael Sweet, Alexander Pevzner
-
- WITHDRAWN (shortly after first evaluation)
-
- We have replaced this project by a 2-student LFMP project (see here).
-
- Tutorial and Design Guidelines for Printer/Scanner drivers in Printer Applications
-
- Support for IPP Fax Out
-
- Wrapping proprietary printer drivers into a Printer Application
-
- IPP scan (or virtual MF device) server (Scanner Application)
-
- IPP scan (or virtual MF device) server (Scanner Application)
-{post.excerpt}
+ )} + ++ Redirecting to OpenPrinting Drivers database... +
++ Showing {displayStart}-{displayEnd} of {filteredLength} printer models +
++ Find support information for legacy printers, review available drivers, and open PPD + files for closer inspection. +
++ {error || "Please try again in a moment."} +
++ Page {currentPage} of {totalPages} +
++ {searchQuery ? `Results for "${searchQuery}"` : "Browsing all printer models"} + {selectedManufacturer !== "all" ? ` in ${selectedManufacturer}` : ""} +
++ Try a different model name, broaden your filters, or clear the current search to see more results. +
++ {ws.summary.summary} +
+++ )} + + {ws.summary.workProductUrl && ( + + )} +++++ “{ws.summary.quote}” +
++ — {ws.contributor.name} +
+
+ Open Source Contributions +
++ OpenPrinting participates in GSoC under The Linux Foundation, + mentoring contributors on printing infrastructure, desktop + integration, and open-source development. +
++ Browse by Year +
++ {contributor.title} +
++ {meta.eyebrow} +
++ {post.excerpt} +
+ )} ++ The page you're looking for doesn't exist or has been moved. +
++ Browse printers that work out of the box with AirPrint™ and IPP Everywhere™. +
++ This page shows printers that will work without any additional software because they + support the{" "} + + AirPrint™ + {" "} + and/or{" "} + + IPP Everywhere™ + {" "} + standards for driverless printing. These printers also often support{" "} + + Mopria® + {" "} + as used on Android OS and Microsoft Windows®, and{" "} + + Wi-Fi Direct Print Services + {" "} + for printing directly via Wi-Fi. +
+ +| Model | +Standards | +
|---|---|
| + Loading printer list… + | +|
| + No printers found matching “{query}”. + | +|
| {printer.model} | +{standards || "—"} | +
+ Showing {((currentPage - 1) * PAGE_SIZE) + 1}–{Math.min(currentPage * PAGE_SIZE, filtered.length)} of {filtered.length.toLocaleString()} printers +
+ )} ++ Redirecting to{" "} + + {data.redirect} + + … +
+ + + ) + } + + const title = + typeof data.title === "string" + ? data.title + : project.replace(/^\d+-/, "").replace(/-/g, " ") + + return ( +{author.role}
+ )} ++ {author.role} +
+ )} + + {author.location && ( ++ {siteConfig.brand.tagline} +
++ {siteConfig.brand.tagline} +
+ ++ View the printer description file associated with this entry before downloading or using it. +
++ Selected file +
+
+ {normalizedPath ?? requestedPath ?? "No PPD file selected"}
+
+ {content}
+
+ )}
+ {printer.manufacturer}
++ {driverCount > 0 + ? `${driverCount} driver${driverCount === 1 ? "" : "s"} listed for this printer model.` + : "No drivers are currently listed for this printer model."} +
++ {error || "The requested printer entry could not be found in the OpenPrinting database."} +
+ +{printer.manufacturer}
++ Recommended driver +
++ {printer.recommended_driver.replace(/^driver\//, "")} +
++ Explore the drivers associated with this printer, including notes, upstream links, and PPD downloads where available. +
++ Filter by manufacturer, support level, printer type, and color capability to narrow the directory quickly. +
++ About Us +
++ We develop the printing infrastructure for Linux and similar + operating systems under The Linux Foundation. Every year we + participate in Google Summer of Code, mentoring contributors on + printing, scanning, CUPS, and related projects. +
++ Admins: Till + Kamppeter & Aveek Basu + · + + Technologies: + {" "} + C, C++, CUPS, IPP, Python + · + Topics:{" "} + Printing, Scanning, Desktop Integration +
++ Related Posts +
++ {post.snippet} +
+ )} ++ {hasContributors + ? `Contributors, completed projects, and mentoring details for GSoC ${year}.` + : `Project ideas and proposals for GSoC ${year}.`} +
+ {orgUrl && ( + ++ Completed Work +
++ {contribSummary?.summary || + "View project details on the GSoC archive."} +
+ ++ Project Ideas +
++ {project.excerpt} +
+ + {(projectMentors.get(project.slug) ?? []).length > 0 && ( ++ In Their Words +
++
+ “{s.quote}” +
++ From the Blog +
++ Blog posts related to GSoC {year}. +
++ {post.snippet} +
+ )} ++ {eyebrow} +
++ {subtitle} +
+ ) : null} +Who We Are
++ {item.description} +
+
+ {children}
+
+ )
+ },
+ }}
+ >
+ {markdownContent}
+ + {item.excerpt} +
+ +What's New
++ {description} +
+ ) : null} +Find Your Printer
++ {software.description} +
+ + {software.title === "Windows?!" ? "Read More" : "Browse"} +Community
++ OpenPrinting collaborates with standards groups and participates in coding and documentation programs. +
++ {project.description} +
+ + Read More ++ {project.description} +
+ + Read More ++ {scope === "site" + ? "Searching OpenPrinting..." + : "Searching Foomatic database..."} +
+-Important: We protect the e-mail addresses of our mentors and mailing lists against spam bots. Please replace all occurrences of “ at ” and “ dot ” by “@” and “.” resp. -
-Mailing list: printing-architecture at lists dot linux-foundation dot org
@@ -65,7 +46,6 @@ The participation of the Linux Foundation in the Google Summer of Code is organi+Mailing list: printing-architecture at lists dot linux-foundation dot org +
+ ++IRC: #openprinting on Freenode +
+ + + ++Code License: See project descriptions +
+ ++The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com). +
+ ++Please see the plans for our near future work to get an overview of our development direction and architecture changes. +
+ +## GSoC 2020 Students + +### Aakash Lahoti + + + +IPP scan server (Scanner Application) + +### Priydarshi Singh + + + +CPDB Qt implementation + +### Jai Luthra + + + +General Printer Application SDK + +### Sambhav Dusad + + + +Make Printer Applications configurable + +### Mohit Mohan + + + +Speed/scaling optimization of cups-browsed + +### Lakshay Bandlish + + + +Linux GUI Application to admin MF devices using IPP System Service + +### Vikrant Malik + + + +Extract raster data from PDFs for direct printing + +# Results + +### 1. Extract raster data from PDFs for direct printing + +- **Student:** Vikrant Malik +- **Mentors:** Sahil Arora, Till Kamppeter +- **Work Product:** [Link](https://vikrantmalik051.blogspot.com/2020/08/blog-post.html) +- **Status:** PASSED + +### 2. General Printer Application SDK + +- **Student:** Jai Luthra +- **Mentors:** Michael Sweet, Till Kamppeter +- **Work Product:** [Link](https://jailuthra1.github.io/google-summer-of-code-2020/) +- **Status:** PASSED + +Jai has principally worked on PAPPL but also done an HP PCL sample Printer Application. In the end he has also worked on converting filters of cups-filters into filter functions. + +### 3. Linux GUI application to admin MF devices using IPP System Service + +- **Student:** Lakshay Bandlish +- **Mentor:** Michael Sweet +- **Work Product:** [Link](https://github.com/lbandlish/Administrate-MF-Devices-GUI) +- **Status:** PASSED + +### 4. Make Printer Applications Configurable + +- **Student:** Sambhav Dusad +- **Mentor:** Michael Sweet +- **Work Product:** [Link](https://dsam82.github.io/gsoc20/l) +- **Status:** PASSED + +Sambhav has also started to create a Gutenprint Printer Application. + +### 5. Speed/Scaling Optimisation of cups-browsed + +- **Student:** Mohit Mohan +- **Mentors:** Deepak Patankar, Till Kamppeter +- **Work Product:** [Link](https://github.com/mohitmo/GSoC-2020-Documentation) +- **Status:** PASSED + +### 6. Common Print Dialog Backends (CPDB) Qt Implementation + +- **Student:** Priydarshi Singh +- **Mentor:** Dongxu Li +- **Work Product:** [Link](https://dryairship.github.io/gsoc-2020/) +- **Status:** FAILED (final evaluation) + +We are looking into finishing up CPDB after GSoC. + +### 7. IPP Scan (or virtual MF device) server (Scanner Application) + +- **Student:** Aakash Lahoti +- **Mentors:** Michael Sweet, Alexander Pevzner +- **Status:** WITHDRAWN (shortly after first evaluation) + +We replaced this project by a 2-student LFMP project ([details](https://openprinting.github.io/OpenPrinting-News-September-2020/#linux-foundation-mentorship-program)). diff --git a/contents/gsoc/gsoc2021.md b/contents/gsoc/gsoc2021.md new file mode 100644 index 00000000..ebb5d017 --- /dev/null +++ b/contents/gsoc/gsoc2021.md @@ -0,0 +1,78 @@ +--- +layout: collection +title: "GSoC 2021 Projects" +collection: gsoc2021 +permalink: /gsoc2021/ +author_profile: false +sidebar: + nav: "gsoc21" +--- + + + ++Mailing list: printing-architecture at lists dot linux-foundation dot org +
+ ++IRC: #openprinting on Freenode +
+ + + ++Code License: See project descriptions +
+ ++The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com). +
+ ++Please see the plans for our near future work to get an overview of our development direction and architecture changes. +
+ +## GSoC 2021 Students + +### Suraj Kulriya + + +Make All Filter Functions Work Well Even Without PPD Files + +### Divyasheel + + +GUI for listing and managing available IPP services + +### Bhavna Kosta + + +Firmware and other file handling in PAPPL + +### Pranshu Kharkwal + + +Create a single universal CUPS filter to replace the chain of individual filters + +### Pratyush Ranjan + + +CUPS Filters: Converting Filters to Filter Functions diff --git a/_pages/gsoc2021.md b/contents/gsoc/gsoc2022.md similarity index 78% rename from _pages/gsoc2021.md rename to contents/gsoc/gsoc2022.md index c068e51f..504f72fa 100644 --- a/_pages/gsoc2021.md +++ b/contents/gsoc/gsoc2022.md @@ -1,16 +1,17 @@ --- layout: collection -title: "GSoC 2021 Projects" -collection: gsoc2021 -permalink: /gsoc2021/ +title: "GSoC 2022 Projects" +collection: gsoc2022 +permalink: /gsoc2022/ author_profile: false sidebar: - nav: "gsoc21" + nav: "gsoc22" --- +-Main GSoC Linux Foundation page: How to apply, deadlines, other workgroups, ... +Main GSoC Linux Foundation page: How to apply, deadlines, other workgroups, ...
-Important: We protect the e-mail addresses of our mentors and mailing lists against spam bots. Please replace all occurrences of “ at ” and “ dot ” by “@” and “.” resp. -
-Mailing list: printing-architecture at lists dot linux-foundation dot org
@@ -52,6 +49,3 @@ The participation of the Linux Foundation in the Google Summer of Code is organiPlease see the plans for our near future work to get an overview of our development direction and architecture changes.
- -+Mailing list: printing-architecture at lists dot linux-foundation dot org +
+ ++IRC: #openprinting on Freenode +
+ + + ++Code License: See project descriptions +
+ ++The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com). +
+ ++Please see the plans for our near future work to get an overview of our development direction and architecture changes. +
diff --git a/contents/gsoc/gsoc2024.md b/contents/gsoc/gsoc2024.md new file mode 100644 index 00000000..68e98839 --- /dev/null +++ b/contents/gsoc/gsoc2024.md @@ -0,0 +1,51 @@ +--- +layout: collection +title: "GSoC 2024 Projects" +collection: gsoc2024 +permalink: /gsoc2024/ +author_profile: false +sidebar: + nav: "gsoc24" +--- + + + ++Mailing list: printing-architecture at lists dot linux-foundation dot org +
+ ++IRC: #openprinting on Freenode +
+ + + ++Code License: See project descriptions +
+ ++The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com). +
+ ++Please see the plans for our near future work to get an overview of our development direction and architecture changes. +
diff --git a/contents/gsoc/gsoc2025.md b/contents/gsoc/gsoc2025.md new file mode 100644 index 00000000..20e6f2f9 --- /dev/null +++ b/contents/gsoc/gsoc2025.md @@ -0,0 +1,51 @@ +--- +layout: collection +title: "GSoC 2025 Projects" +collection: gsoc2025 +permalink: /gsoc2025/ +author_profile: false +sidebar: + nav: "gsoc25" +--- + + + ++Mailing list: printing-architecture at lists dot linux-foundation dot org +
+ ++IRC: #openprinting on Freenode +
+ + + ++Code License: See project descriptions +
+ ++The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com). +
+ ++Please see the plans for our near future work to get an overview of our development direction and architecture changes. +
diff --git a/contents/gsoc/gsoc2026.md b/contents/gsoc/gsoc2026.md new file mode 100644 index 00000000..696df221 --- /dev/null +++ b/contents/gsoc/gsoc2026.md @@ -0,0 +1,51 @@ +--- +layout: collection +title: "GSoC 2026 Projects" +collection: gsoc2026 +permalink: /gsoc2026/ +author_profile: false +sidebar: + nav: "gsoc26" +--- + + + ++Mailing list: printing-architecture at lists dot linux-foundation dot org +
+ ++IRC: #openprinting on Freenode +
+ + + ++Code License: See project descriptions +
+ ++The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com). +
+ ++Please see the plans for our near future work to get an overview of our development direction and architecture changes. +
diff --git a/_gsod2020/01-Tutorial-Printer-Applications.md b/contents/gsod/gsod2020/01-Tutorial-Printer-Applications.md similarity index 100% rename from _gsod2020/01-Tutorial-Printer-Applications.md rename to contents/gsod/gsod2020/01-Tutorial-Printer-Applications.md diff --git a/_pages/about-us.md b/contents/pages/about-us.md similarity index 100% rename from _pages/about-us.md rename to contents/pages/about-us.md diff --git a/_pages/achievements.md b/contents/pages/achievements.md similarity index 100% rename from _pages/achievements.md rename to contents/pages/achievements.md diff --git a/_pages/codeofconduct.md b/contents/pages/codeofconduct.md similarity index 100% rename from _pages/codeofconduct.md rename to contents/pages/codeofconduct.md diff --git a/contents/pages/contact.md b/contents/pages/contact.md new file mode 100644 index 00000000..5a03af70 --- /dev/null +++ b/contents/pages/contact.md @@ -0,0 +1,36 @@ +--- +title: "Contact Us" +permalink: /contact/ +layout: collection +header: + overlay_color: "#000" + overlay_filter: "0.5" + overlay_image: /assets/images/contact_us.jpeg +excerpt: "Feel Free To Contact Us!" +author_profile: false +--- ++Important: We protect the e-mail addresses of our mentors and mailing lists against spam bots. Please replace all occurrences of “ at ” and “ dot ” by “@” and “.” resp. +
++ The lists were moved to the mail server list.linux.dev. +
+
+
+ +- {{ post.excerpt | markdownify | strip_html | truncate:200}} -
- {% endif %} - -This page shows printers that will work without any additional software because they support the AirPrint™ and/or IPP Everywhere™ standards for driverless printers. These printers also often support Mopria® as used on Android OS and Microsoft Windows®, and Wi-Fi Direct Print Services for printing directly via Wi-Fi.
- - -| Model | -Standard(s) | -
|---|
Generates multiple test document types (text, images, mixed content)
Sends documents to CUPS for processing
Waits for processed files to appear in ~/gsoc/openprinting/PDF/
Converts both original and processed documents to PNG images
Compares them using enhanced image analysis algorithms
Generates HTML reports with visual comparisons and quality metrics
Used for: Testing document rendering quality and content preservation print_quality_pipeline.py
Purpose: Complete automated print quality testing system
Takes only printer queue name as input parameter
Automatically discovers printer capabilities, modes, and filter chains from PPD files
Generates 37 comprehensive test images targeting specific quality aspects
Processes each image through detected CUPS filter chains for each printer mode
Key difference: Tests filter chain output directly (not physical printing)
Compares original images with filter-processed results using 11+ algorithms
Used for: Complete printer driver validation and filter chain correctness testing Here is Sanskar's GitHub repository. It has a detailed description of his work. Mentors: Jynn Nelson, Michael Murphy, Till Kamppeter Here is Mintu's work in his GitHub repository. Mentors: Jynn Nelson, Michael Murphy, Till Kamppeter, Chandresh Soni, Pratyush Ranjan, Bhavanishankar Ravindra Since my last update, I have made steady progress on the Rust bindings. After completing the setup and generating the raw bindings, I moved forward with implementing safe Rust wrappers for the core cpdb-libs functions. These wrappers focus on providing idiomatic Rust abstractions while ensuring memory safety through Rust’s ownership and borrowing rules. I have implemented functionality for printer discovery, job submission, and queue management, all wrapped in a type-safe API to minimize unsafe blocks. Error handling mechanisms have been introduced using Result types and custom error enums to better integrate with Rust’s ecosystem. Additional wrapper functions have been developed to handle print job management and authentication, ensuring that key cpdb-libs features are exposed cleanly to Rust applications. I have also refined the API design to make it more developer-friendly, using strongly typed structures instead of raw pointers wherever possible. Currently, I am finalizing the type-safe API for common CUPS functionalities and ensuring that the abstractions are both safe and efficient. This includes careful mapping of C data structures to Rust equivalents while avoiding unnecessary performance overhead. The next steps will involve writing unit tests for the implemented modules to ensure stability and correctness before moving on to integration testing with sample Rust applications. I will also commit and push the updated code to GitHub shortly so that you can review it. Here is Titiksha's work in her GitHub repository. Mentors: Jiongchi Yu, George-Andrei Iosif, Dongge Liu, Till Kamppeter, Shivam Mishra, Akarshan Kapoor The initial goal was to integrate the OpenPrinting projects into OSS-Fuzz-Gen in order to generate more fuzzers and improve code coverage. However, during practice I identified some major limitations of OSS-Fuzz-Gen: The biggest flaw is that when a YAML defines multiple functions, OSS-Fuzz-Gen creates a separate fuzzer for each function. This makes it hard to capture the relationships of functions called —— which limits coverage. Besides, OSS-Fuzz-Gen is highly encapsulated and heavy. Even minor issues like network instability can cause the entire pipeline to fail. It also generates many redundant Docker images. To address these issues, I developed light-fuzz-gen (https://github.com/pushinl/light-fuzz-gen), with the aim of eventually integrating it back into OSS-Fuzz-Gen. (Since the workflow of OSS-Fuzz-Gen is overly complex at the moment, light-fuzz-gen is being used separately for now.) In addition, I experimented with combining OSS-Fuzz-Gen, light-fuzz-gen, and AI-assisted IDE tools. This approach allowed me to generate a large number of harnesses and seeds, which significantly improved the code coverage of the OpenPrinting project. So far, I have generated a large number of fuzzers and actually added 6 effective. In particular, coverage for cups increased from 11% to 30%, and coverage for libcups improved from 14% to 17%. (https://introspector.oss-fuzz.com/project-profile?project=cups) The biggest challenge remains ensuring that fuzzers generated by LLMs can pass compilation and linking successfully. At present, I am encountering difficulties with the Makefile build process of cups-filters, and I am actively working on resolving this issue. Zixuan's work is going as pull requests into OpenPrinting's \"fuzzing\" repository. Here are the pull requests which are already merged. Zixuan's user name on GitHub is \"pushinl\". Mentors: Michael Weghorn, KushagraSharma, Till Kamppeter, Zdenek Dohnal, Shivam Mishra With guidance from my mentors and Till Sir, I successfully developed a custom GTK-based preview pane using Poppler library for PDF rendering. This component is fully integrated into the application and functioning as intended. This update also resolved an earlier issue: previously, clicking the “Preview” button in the print dialog would close the dialog. Now, the print dialog behaves like a modal window — it remains active until the preview pane is closed. This means users no longer need to repeatedly reopen the print dialog when making preview changes. I have now begun developing a combined print dialog with an integrated print preview. Rather than creating a new print dialog from scratch, I’m embedding the custom preview pane into the existing GTK print dialog, using GTK’s native embedding capabilities. My current focus is on adapting the preview pane into an embeddable component fully compatible with the GTK print dialog. For now, the preview will only update when users click the “Preview” button, as it does not yet refresh automatically when settings change. Yash has posted about his work on the internet a few days ago, on Reddit and on LinkedIn. His work is available on Github, note that main is the original, unchanged code, and the other branches are Yash's changes. Discussion on GNOME's Discourse. Mentors: Jiongchi Yu, George-Andrei Iosif, Dongge Liu, Till Kamppeter, Ira McDonald, Shivam Mishra Following up from my last update, I continued my work on fuzzing ipp-usb but eventually moved away from the original “import as a library” approach. This approach had caused persistent build failures due to unexported types and methods, as well as libusb CGO linker errors, when attempting to fuzz functions like sanitizeIppResponse. Even after exporting the required methods and struct fields, importing the usb package still pulled in the USB I/O layer, which depended on hardware-specific libusb functions that were difficult to satisfy in the OSS-Fuzz container environment. After discussing this with Alexander, we agreed that turning ipp-usb into an importable Go package was not practical since it is architecturally a standalone program. The only realistic way to fuzz it would be through its external HTTP-over-USB interface, which normally requires a real IPP-over-USB device. The ideal solution would be to create a virtual IPP-over-USB device simulator, which would allow fuzzing without relying on actual hardware. I began working on this by experimenting with usbip and the VirtualUSBDevice project to simulate an IPP-over-USB device. The goal was to implement a black-box fuzzing setup in which the fuzzer feeds input to the simulated device, the ipp-usb daemon runs and connects to it, and the fuzzed data is injected into the communication loop for processing. This architecture would allow monitoring the entire interaction for crashes while avoiding direct hardware dependencies. As part of this setup, I successfully created the required build.sh and oss_fuzz_build.sh scripts to compile both the ipp-usb daemon and the emulator. With these changes, the build for both AFL++ and libFuzzer engines now completes successfully without the previous linker errors. At runtime, however, AFL++ failed because it expects a binary fuzz target, whereas my setup was driven by a shell script. My initial plan was to create a small C++ wrapper to bridge the gap, but instead I decided to switch to libFuzzer, which provided a cleaner and simpler implementation for the black-box approach. With libFuzzer, I was able to write Go-native fuzz drivers that directly launch the ipp-usb binary and communicate with it during fuzzing. I implemented three main drivers: daemon_fuzzer.go, which starts the ipp-usb binary and fuzzes its /ipp/print HTTP endpoint with malformed requests; usb_fuzzer.go, which targets USB protocol parsing logic; and http_client_fuzzer.go, which fuzzes the HTTP client against malformed printer responses. This new setup now runs without the earlier importability or linking issues and keeps the fuzzing pipeline entirely black-box while still targeting key functionality in ipp-usb. I have created a PR to OSS-Fuzz for this integration. Links:
OSS-Fuzz PR: https://github.com/google/oss-fuzz/pull/13815
IPP-over-USB emulation: https://github.com/OpenPrinting/go-mfp/tree/master/proto/usbip Mohammed's work is going as pull requests into OpenPrinting's \"fuzzing\" repository. Here are the pull requests which are already merged. Mohammed's user name on GitHub is \"mdimado\". Mentors: Till Kamppeter, Zdenek Dohnal, Deepak Patankar, Bhavanishankar Ravindra Rudra is concluding his internship this week (Aug 22). He will actually start his GSoC work now. His final submission deadline is moved to November."
+ },
+ {
+ "id": "post:OpenPrinting-News-January-2020",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - January 2020",
+ "url": "/OpenPrinting-News-January-2020",
+ "headings": [
+ "Google Summer of Code 2020",
+ "Google Summer of Code 2019",
+ "Avahi local service support",
+ "Driverless scanning",
+ "Printing Stack Snap",
+ "CUPS",
+ "cups-filters",
+ "ippusbxd and ipp-usb"
+ ],
+ "tags": [],
+ "snippet": "Driverless scanning and AirScan, ippusbxd problems solved, cups-filters 1.26.2 released, lots of bug fixes for cups-browsed, GSoC 2020 org application for the Linux Foundation submitted and project idea list posted",
+ "content": "The application period for mentoring organizations has started on Jan 14 and we have submitted our application for the Linux Foundation as mentoring organization. Along with this we have posted our project ideas list with a total of 16 projects and within these there are 10 dealing with Printer and Scanner Applications. We still need to (preliminarily) assign mentors to the projects. We are currently contacting former students to ask them whether they want to mentor and if yes, which projects. We have started looking for students for this yaer and some are already working on assignments. Tanmay Anand is working on the Common Print Dialog Backends (CPDB) support for the GTK print dialog which he did not finish withing the GSoC. Here is his GitHub repository. Trent Lloyd has given another sign of life in the localhost-support issue on GitHub. This time he tells that he will merge the patch but fix this issue first. This was on December 22, 2019, after that nothing more happened. There is no IPP Scan implemented yet but in December, during the holiday season there came up projects of Linux support for Apple AirScan, or eSCL. eSCL is the HTTP-based protocol which Apple uses for AirScan, which is available on all multi-function printers which also do AirPrint, intended to allow scanning from Apple's mobile devices with the iOS operating system. The specifications of eSCL are not published but as an HTTP-based protocol it was not that difficult to reverse-engineer for the authors of the eSCL-related software. There are two (independently developed) SANE backends for using these scanners: \"escl\" (small, light, basic, already included in SANE 1.0.29) and \"airscan\" (complete functionality). There is also an AirScan server, AirSane, which is a SANE frontend which emulates an AirScan scanner scanning on any physical scanner supported by SANE. I have worked a lot with the two maintainers of the backends to get my HP DeskJet 2540 Ink Advantage (a cheap multi-function device with AirPrint) scanning with them (and without need of HPLIP). I tested not only via network (Wi-Fi) but also via USB, using ippusbxd and also got it working this way. One must note that the IPP-over-USB standard is not strictly about IPP but actually defines an HTTP-over-USB connection, to allow for extra functionality like web administration interfaces. The maintainers of the backends also investigated ippusbxd and its shortcomings. Thierry Hucahrd, maintainer of the \"escl\" backend (originally created by Nathan Touboul under Thierry's mentorship) even contributed DNS-SD advertising of the scanner part to ippusbxd and Alexander Pevzner, author of the \"airscan\" backend replaced ippusbxd altogether in a few hours. His ipp-usb, written in Go, fixes paractically all the problems of ippusbxd (Issues #9, #14, and #15). Currently he is working on doing the DNS-SD advertising correctly (Issue #11) in his ipp-usb project. Even if AirScan/eSCL is not PWG's IPP Scan, the code of the mentioned software can be a good base for implementing IPP Scan both as a client (SANE backend) and a server (Scanner Application). We are contacting the authors for a possible GSoC participation. Also good news is that 100s (1000s ?) of scanners in modern multi-function devices will soon \"just work\" with regular Linux distributions. There is no new release but I have done a bigger overhaul (on the GitHub repository): CUPS 2.3.1 cups-filters 1.26.2 QPDF 9.1.0 Added Ghostscript (9.50) as main PDF renderer, kept Poppler as backup Now based on Ubuntu Core 18 More debugging options Bug fixes The snap is working well now, including the integrated cups-browsed. Note that when running CUPS in a snap one cannot add classic drivers consisting of filters and PPDs. Drivers can only get added in the form of Printer Applications. No further releases. By the way, I have it currently working well in the printing-stack-snap. Currently released is 1.26.2. 1.26.2: Bug fix release mainly to make cups-browsed correctly working with a CUPS daemon on a non-standard port, and also for cups-filters smoothly building with GCC 10 1.26.1: Bug fix release, to make the cups-browsed-generated local print queues actually work on all OS distributions and to get legacy (not actually designed for driverless IPP) printers better working Good news! As already told earlier here in the section about driverless scanning we did intensive tests of ippusbxd with scanning (Apple AirScan) found several problem and Alexander Pevzner, author of the \"airscan\" SANE backend, wrote a complete replacement for ippusbxd in Go in a few hours, named ipp-usb. It fixes most long-standing issues (#9, #14, and #15) and Alexander is currently working on correct DNS-SD advertising, based on polling the device via HTTP/IPP and not only on the USB device ID (Issue #11). ippusbxd received some pull requests from Thierry Hucahrd, maintainer of the \"escl\" backend, DNS-SD advertising of the scanner part."
+ },
+ {
+ "id": "post:OpenPrinting-News-January-2021",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - January 2021",
+ "url": "/OpenPrinting-News-January-2021",
+ "headings": [
+ "Google Summer of Code 2021",
+ "Linux Foundation Mentorship Program",
+ "PostScript Printer Application",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "PAPPL 1.0.1, PostScript Printer Application, GSoC 2021, LFMP projects ended, CUPS, cups-filters",
+ "content": "The time window for the mentoring organizations to apply will be Jan 29 - Feb 19, 2021. See also the complete timeline. We will again apply for the Linux Foundation as mentoring organization, as in the previous years, OpenPrinting being one of the sub groups. We are still looking for project ideas to get a good number lined up before applying. As mentioned already in October student projects will only be half the time (6 weeks). So this has to be taken into account and larger projects we should consider to run under the Linux Foundation Mentoring Program instead of GSoC. Our IPP Scan LFMP project has ended, with both Abhik Chakraborty and Rishabh Arya having completed their work successfully and preparing their final reports. Their work of adding IPP Scan as a server to PAPPL is currently available in Abhik's GitHub repository and Rishabh's earlier work on sane-airscan in the IPP Scan repository of sane-airscan. The development of the PostScript Printer Application is going on and has driven the development of PAPPL forward. The PostScript Printer Application got several new features: Extra per-printer web interface page \"Device Settings\" for configuration of which optional hardware add-ons are actually installed (\"Installable Options\" group in the PPD files). The user selects which add-ons (extra trays, duplex unit, finishers, ...) are installed and the options and choices on the \"Printing Defaults\" page and also the capabilities reported as response to a get-printer-attributes IPP request from a client get appropriately adapted. Polling add-on setup and option defaults from the printer, triggered by buttons on the \"Device Settings\" web interface page. New \"Add PPDs\" web interface page for the user to add extra PPD files to the Printer Application, to use PostScript printers not supported by the already included PPDs. Especially important when the PPD for a printer is not available under a free license. Support for collated copies (PDF or PostScript input only) Support for custom page sizes (but currently the size can only be set in inches). Made \"Identify Printer\" work, simply by sending a zero-page job with a certain delay between beginning and end, to make the printer light up its display and make noise (and perhaps also show job info on the display). Next steps will be: When auto-selecting driver prefer user-added PPDs (the user added them because he wants to use them) and also prefer PPDs in the system's language or at least in English. Display results of PPD upload: Errors, warnings, successful uploads, issue a warning also for PPDs with *cupsFilter(2): ... lines. Display all user-added PPD files with checkboxes for deleting them. Ignore PPD options which do not have PostScript or PJL code snippets for the option choices. With appropriate features added to PAPPL we will be able to also add the following: Make Snap fire up Printer Application automatically as daemon and Printer Application set up USB printers automatically when they get connected (needs support in PAPPL. Human-readable strings for vendor options. Needs support in PAPPL. Ink level check via ps_status() function. Needs support in PAPPL. Once having these features implemented, the PostScript Printer Application is complete so far. As other retro-fitting Printer Applications also use most of what we have in the PostScript Printer Application now (as PPDs are used) I am thinking about renaming the \"ps-printer-app\" project into \"retro-fit-printer-app\", and adding conditional compiling to activate and de-activate the appropriate pieces of code for the actual Printer Applications: PostScript, Foomatic, Ricoh, HPLIP, ... and create appropriately named projects (like \"ps-printer-app\") on the GitHub only for the snapping and putting into the Snap Store. Currently released is 2.3.3op1. This release made it already into Debian and Ubuntu. Fedora/Red Hat is using the OpenPrinting fork of CUPS, too, and we already have some contributions from Zdenek Dohnal from Red Hat, meaning that the patches of the different distributions get merged in the fork. Currently released is 1.28.7. On the way towards 2.0.0 and driven by the further development of the PostScript Printer Application I have added the following new feature: Let the filter functions not load the PPD and not mark options in the PPD files to make them better usable with Printer Applications and to avoid race conditions in filter chains. Important bug fixes, applied to both 1.x and 2.x are The driverless utility does not check the printers for driverless support quality any more. Each printer got polled with up to 3 get-printer-attributes IPP requests and this takes significant time, especially when there are many printers, making CUPS timing out and do not show any available driver at all. In the PPD generator for setting up driverless IPP printers with CUPS prefer Apple Raster instead of PDF due to compatibility problems with some printers. 1.28.7: Bug fix release to remove the support quality check from the \"driverless\" utility to do not break CUPS' PPD listing facility and several fixes for generating PPDs for driverless printers Currently released is 1.0.1. Michael Sweet has now issued a first bug fix update of PAPPL, version 1.0.1. Many bug fixes are resulting from Coverity and also from my further development of the PostScript Printer Application. See also the currently open and closed issues of PAPPL. Didier Raboud, printing maintainer at Debian, is already starting on packaging PAPPL."
+ },
+ {
+ "id": "post:OpenPrinting-News-January-2022",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - January 2022",
+ "url": "/OpenPrinting-News-January-2022",
+ "headings": [
+ "Google Summer of Code 2022",
+ "Approaching cups-filters 2.0",
+ "CUPS-driver-retro-fitting Printer Applications",
+ "CUPS Snap",
+ "LPrint",
+ "PDFio",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "GSoC 2022 timeline, approaching cups-filters 2.x, PAPPL 1.1.0, LPrint 1.1.0 PAPPL_based, PDFio 1.0.0, cups-filters 1.28.11",
+ "content": "Save the dates! The timeline for 2022 is out! Mentoring organizations can submit their applications in the time from February 7 to February 21. We will apply again with the Linux Foundation. Code contributor (not only students) applications are accepted from April 4 on, up to April 19, and coding starts on June 13, and either ends on September 4 if the work was done in the standard period, or on November 13 if the extended period was made use of. Now we need to write up our project ideas for the organization application. Main work areas for 2022 are: Complete the scanning support in PAPPL and create a retro-fit framework to convert SANE drivers into Scanner Applications Create a GUI to find Printer Applications for discovered non-driverless printers and set them up Common Print Dialog Backends in GTK, QT, ... print dialogs Get Braille embosser support of cups-filters into a Printer Application Switchover of pdftopdf() and bannertopdf() to from QPDF to PDFio (?) We are also already looking for contributor candidates and as part of our community onboarding program we have assigned GitHub issues, mainly of cups-filters to them. Several are investigating the issues and working on fixes and so helping us towards the cups-filters 2.0 release. Currently, I am doing a lot of testing, bug-fixing, cleaning-up, polishing, ... to prepare the release of cups-filters 2.0. Before doing this release, the second generation of cups-filters, I still want to discuss some points in order to optimize the release. I have tried to initiate this discussion with a post on the OpenPrinting mailing list but, unfortunately, did not get a single answer. So I am re-posting the text here: With the background of CUPS 3.x, planned to get released 2 years from now, not supporting PPD files any more and only considering driverless IPP printers, I have changed the architecture of cups-filters, converting filter executables (CUPS filters) into filter functions (library functions doing a filter's task, with standardized call scheme/interface) so that the code of the filters is preserved but they get more universally usable. In addition I have created some auxiliary functions (partially filter functions by themselves) to call filter functions in a chain, feed data into a filter function through a pipe, call classic CUPS external filter/backend executable wrapped into a filter function, save data stream between chained filter function calls into a file for debugging, ... Perhaps you have followed all this development here in the news posts or in the GIT repository of cups-filters. With this I was especially able to create Printer Applications retro-fitting classic CUPS printer drivers (Snap Store), an important step to be able to switch to a PPD-less and driverless CUPS without dropping support for legacy printers. Now I am also thinking about making use of the filter functions somehow in CUPS, both to get improvement in the upcoming 2 years where CUPS still supports PPD files and classic drivers and also in PPD-less CUPS 3.x, where data-format conversions are still needed, as for example print jobs usually come in PDF but it is not required for a driverless IPP printer to support PDF. Also implementation of functionality like N-up or flattening filled PDF forms (both tasks currently done by pdftopdf) is needed in CUPS 3.x. We should do our best to avoid duplicate code in OpenPrinting and not re-invent the wheel. \"universal\" filter for CUPS As a first approach to improve PPDish CUPS 2.4.x and 2.5.x I have run the GSoC project of a universal CUPS filter, where one single CUPS filter executable does all the filtering for a job by calling filter functions, in a chain if needed. This reduces the number of external executable calls by CUPS vastly, as normally CUPS calls for each filter to run first the cups-exec helper program and cups-exec then calls the filter executable, making up 2 external executable calls per filter. The filter function chaining in the universal CUPS filter still does a fork for each filter function though and pipes the print data from filter function to filter function. Also filters of printer drivers and CUPS backends are not part of the universal filter and need to get called separately by CUPS. The disk space saved is low, as with cups-filters 2.x each filter executable in /usr/lib/cups/filters/ is only a little code stub calling the actual filter function in libcupsfilters, Also the universal filter still needs a fix to work correctly with PPD files which use \"cupsFilter2\" instead of \"cupsFilter\" lines. So it is a little bit of a question whether it is really worth the effort to replace the individual filters called by CUPS 2.4.x and 2.5.x by this universal filter, especially also that we have only more 2 years where CUPS uses PPD files. So before I complete this (if not, the universal filter will at least be used to make cups-browsed's implicitclass backend use filter functions instead of external filters) I want to hear some opinions about this, especially also whether actually saving external executable calls is more resource-saving than for example saving forked parallel tasks and pipes between them. Forking and piping vs. one filter after the other In general if forking and piping for a filter chain consumes much more than calling each filter function one after the other directly and let them write their output into temporary files for the next filter functions in the chain reading from the previous filter function's temp file I am also thinking about adding a second mode to filterChain() to let it operate this way. WDYT? Using filter functions directly in CUPS And, finally, should we make the filter functions be directly used by CUPS, either that in CUPS 2.5.x in scheduler/job.c we call filter functions instead of external filter executables (at least for standard, non-driver filters), or that for CUPS 3.x we do the needed file format conversions by filter function calls (there are no driver filters)? Backends could also be converted to filter functions and be directly called. WDYT? Also, do we need extra functionality in the filter function concept for using it directly in CUPS? For example add a field to the records of the filter functions called by filterChain() to tell as which user each individual filter function should get run? Also, if we want CUPS to use filter functions, we need to do re-structuring to avoid circular dependencies, as libcupsfilters uses libcups and if a function in libcups would call a filter function of libcupsfilters, libcups is using libcupsfilters, ... The planned splitting of libcups, local CUPS daemon, sharing CUPS daemon of CUPS 3.x could help here as if the daemons call filter functions but not libcups, we will not get a circular dependency. WDYT? It would be great if we could discuss these topics before finalizing cups-filters 2.x I am inviting everyone to discuss on the OpenPrintingmailing list (subscription required for posting), either answering to the existing thread or starting a new one. When getting some UTAX PostScript PPD files I found a bug with the PPD file handling in the retro-fitting Printer Applications. PPD files contain a metadata field named NickName (like UTAX 350ci (KPDL)). It contains make and model name of the printer followed by information about the PostScript interpreter or printer driver. This field, plus the two-character code for the PPD's user interface language in parentheses (like (en)) are put together (UTAX 350ci (KPDL) (en)) in a string and then normalized (all-lowercase, no non-alpha-numeric characters, word separation with -) to get a unique driver name (utax--350-ci--kpdl-en) for each PPD and no loss of PPD list entries caused by duplicate names. Unfortuately, the normalization code had a bug, throwing away all characters after the first closing paranthesis. This way the language code got lost and as UMAX PPDs come in 6 languages, only the versions with the language coming first in the alphabet ((de)) remained. In the PostScript Printer Application not only the PPD files for the 3 UTAX printers were affected but also PPDs for all Kyocera PostScript printers (they also have (KPDL) in their NickName), so users of these printers had a working printer but with printer-specific options on the Printer Defaults web interface page in German or another language. This is fixed now. Now options appear in English when auto-selecting the PPD and all supported languages are available when manually selecting the model/PPD from the list when adding the printer. CUPS Snap in the Snap Store The CUPS Snap uses cups-filters 2.x (GIT master) now (commit)! Not only we use the newest generation of cups-filters now, but alo there are many bug fixes, especially also that Raster-only printers in cups-browsed print correctly now. So please test the CUPS Snap, especially also whether everything in it also works nicely in the Snap environment. I am still waiting for the snapd team to implement the security concept on the snapd side, but we have agai progress here. Only few things still need to get adjusted, once to prevent breaking the AppArmor profile by the CUPS socket path specified in the client Snaps (discussion) and second, the best location for the CUPS socket to do not interfere with other files (discussion). Also the bug that the interface needs to get reconneted after an update of snapd needs to get fixed. Main TODOs are: Complete the cups interface in snapd. Testing Add a migration script so that OS distributions can easily switch over from classic packages to the CUPS Snap LPrint in the Snap Store LPrint the Printer Application for label printers, created by Michael Sweet, got now 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 it gives 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. Announcement of the 1.1.0 release. Project page PDFio is a simple library for reading and writing PDF files, but it is not a PDF renderer/rasterizer. So it does similar things as the QPDF library, but using only simple C, not C++. It does not replace renderers like Ghostscript or Poppler. Some weeks ago, the first stable release, 1.0 of PDFio got issued! Im am 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. From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|3730| |ipp-usb|ipp-usb|1191| |ps-printer-app|PostScript Printer Application|2031| |ghostscript-printer-app|Ghostscript Printer Application|875| |hplip-printer-app|HPLIP Printer Application|3039| |gutenprint-printer-app|Gutenprint Printer Application|2373| Currently released is 2.4.0. CUPS is now on its best way to version 2.4.1, the first bug fix release. Most visible fix for users and admins is probably the fix of the default setting for the \"ColorModel\" option in the PPD fles generated for temporary CUPS queues, as instead of the \"best\" choice getting selected, the \"print-color-mode-default\" printer IPP attribute gets used. So the PPD will have the actual default setting of the printer. This is once the most intuitive and when the printer´s default gets changed on the server, the client follows. This makes administration a lot easier.See also the original bug report. This change I have also ported to the PPD generator of cups-filters (in both master and 1.x, included in 1.28.11), so PPDs of cups-browsed-generated print queues and PPDs created by the driverless utility use the printer's color mode defaults now. Ubuntu Jammy Jellyfish (22.04 LTS) will come with CUPS 2.4.x, if all works well as Snap. The CUPS Snap and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master of CUPS. Currently released is 1.28.11. We are continuing to polish and to fix bugs for the 2.0.0 release. I have especially switched the implicitclass backend over from using external CUPS filter executables to using filter functions, using the universal() filter function to create the needed filter chains. This revealed a lot of bugs in cups-filters which I have fixed now. I have also adapted the queue naming scheme of cups-browsed to the new naming of temporary CUPS queues, without trailing underscore. This suppresses ugly duplicate entries in print dialogs. cups-browsed's implicitclass backend to dispatch jobs to cluster member printers now uses filter functions and with this it is able to print to Raster printers (see also issue #426. The implicitclass also polls the destination printer with a get-printer-attributes IPP request now to get exact details for the data format to send. Before only the cluster queue's PPD was used with has insufficient info, especially for raster printing (commit). cupsRasterPrepareHeader() creates a complete header now, especially setting page/margin dimensions for the job's page size, filling all dependent fields, initializing header to zero, handle invalid orientation-requested values (commit). pdftopdf() is now correctly applying all print-scaling settings also when the unprintable margins are not symmetric (top != bootom and/or lef != right, commit). Fixed bugs in resolver functions for DNS-SD-based URIs, to not use stdin without need (and so blocking the job data stream in a filter/backend) and to use the actually supplied destination URI (commit). Added PCLm support in cupsRasterPrepareHeader(), to cover all kinds of driverless print data formats (commit). Fixed Apple Raster and PCLm output in universal() filter function, especially make PCLM being generated directly by Ghostscript (commit). Updated the naming of cups-browsed's locally created print queues to match CUPS' naming of temporary queues, to avoid duplicate listings in print dialogs (commit). PPD NickName normalization does not throw away extra text after parentheses any more now, so now Kyocera's KPDL (PostScript) printers appear correctly in ps-printer-app (commit). 1.28.11 Bug fix release, containing backports of many of the bugs recently fixed during the preparation of the cups-filters 2.x release. Important is that cups-browsed’s queue naming is aligned with CUPS’ temporary queue naming now and several bugs affecting driverless printing are fixed. Ubuntu Jammy Jellyfish (22.04 LTS) will most probably come with cups-filters 2.x. 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. Currently released is 1.1.0. PAPPL v1.1.0 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-January-2023",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - January 2023",
+ "url": "/OpenPrinting-News-January-2023",
+ "headings": [
+ "Google Summer of Code 2023",
+ "Linux App Summit 2023",
+ "New Architecture makes it into Ubuntu (and Debian)",
+ "cups-filters bug fixes and second beta (2.0b2)",
+ "LPrint 1.2.0 release",
+ "PAPPL 1.3.1 release"
+ ],
+ "tags": [],
+ "snippet": "GSoC 2023 project ideas and more, LAS 2023 in Brno, New Architecture going into Debian/Ubuntu, cups-filters fixes and 2.0b2, LPrint 1.2.0, PAPPL 1.3.1",
+ "content": "Have you already been in need of a new printer and wanted to make sure it works with your prefered operating system, Linux? If this happened longer ago you had to find out whether there is a driver, in most cases one not coming from the manufacturer amd you were looking up the printer models interesting for you in our database, often with the frustration that they were not listed at all or categorized as a \"Paperweight\". Several years ago we got driverless IPP printing as part of IPP 2.x. Printers advertizing their presence in the network by themselves, telling about all their capabilities und user-settable options by themselves, and using only standard page description languges. This was mainly pushed forward by the fact that the industry wanted that users can print from smartphones. So Apple's Airprint (for the iPhone's iOS and similar) got the most present incarnation of driverless IPP printing. Is this solution the perfect solution making sure that every new printer from now on prints perfectly under Linux and you can simply grab that promotion from your supermarket? In most cases and with certain manufacturers (like HP for example) it works very well, but there are always bugs in manufacturer's implementations of the standards. You see that most bug reports on cups-filters and many on CUPS are a user complaining that output of their printer (used in driverless mode) is not correct. To avoid such problems, the PWG (Printer Working Group), creator of the IPP (Internet Printing Protocol) has created a self-certification program for their own flavor of driverless IPP printing, IPP Everywhere, so that manufacturers can certify their printers, and several did. So we have a long list of printers, either listed by Apple as supporting AirPrint or certified to support IPP Everywhere, more than 8000 printers! For the printers listed as only supporting AirPrint and not IPP Everywhere we do not exactly know how Apple tests the compatibility and how Apple's operating systems exactly communicate with the printers. This can easily lead to issues like this one where a printer does perfectly do AirPrint with Apple clients but has problems when the client is running Linux. Changing the way how to poll the printer's capabilities via IPP solves the problem. For IPP Everywhere everyone can see what the standard includes and how the certification works, as at the PWG all standards and all development are open. All the specifications for the standards are freely downloadable and the self-certification utilities are free software. So if a user reports an issue on an IPP-Everywhere-certified printer we can check why the certification utility succeeds but the user's system fails and more easily do a fix. And, back to buying a printer, now you can download the certification tools, put them on your laptop, phone, or other portable device and run it on the printers which are on display in the store, finding a printer passing all tests and that is the one you will buy ... As the tool does a series of sophisticated tests and so it is much more reliable than if you randomly try to print some file. And in the future this gets even easier: Michael Sweet is working on a graphical certification tool, written in Flutter and probably put up in the Snap Store and other system's app stores once released, making your printer shopping even easier, if needed with the help of the laptops on display and WSL ... While still doing the aftermath of GSoC 2022, having the contributors integrating their work in the appropriate upstream projects, we are already preparing GSoC 2023. So we are involved in the GSoC year-round. As the application period for mentoring organizations is soon starting (Feb, 23, 2023), we have already lined up our project ideas (after some discussion with Michael Sweet): Adding support for the new functionality/attributes of IPP Everywhere 2.x to libcupsfilters and the Common Print Dialog Backends (CPDB) CPDB support for application's print dialogs: Firefox, Chromium, LibreOffice, ... Scanning support in PAPPL Turn cups-browsed into a Printer Application PAPPL-based Printer Applications: Option setting presets via web interface Make a native Printer Application from Gutenprint CI Testing programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, ... GNOME Control Center: List and handle IPP print services for the New Architecture cups-filters: Create OCR filter to deliver scans as searchable PDFs Please contact us at any time if you are interested in being a GSoC contributor for OpenPrinting on one of these projects or on your own project idea. We also have already many contributor candidates doing assignments, in stage 1 building CUPS and cups-filters, learning about the code, the printing architecture, driverless printing, ... in stage 2 working on issues in cups-filters, CUPS, and other OpenPrinting projects, and some already in stage 3 learning about the project in which they want to do their GSoC work. The work on the GSoC 2022 projects and their integration is going on and some are getting continued in GSoC 2023 projects: Common Print Dialog Backends Gaurav Guleria continued his work on the CPDB integration in the print dialogs. Especially he added an option group concept, implemented support for translated UI strings for option, choice, and option group names (commit) and also did a fix on the API of libcupsfilters for that (commit). Gaurav's best friend and dorm roommate Kushagra Sharma got inspired by Gaurav's enthusiasm, started volunteering on CPDB and wants to participate in GSoC 2023. I have put him then to study the print dialogs of the browsers and I had really motivating and inspiring Telegram 1:1s with him, he is currently studying a semester in Germany and I animated him to attend FOSDEM. GNOME Control Center \"Printers\" module I worked with Mohit Verma on preparing his work on the \"Add Printer\" part for Elio Qoshi and Canonical's UI/UX design team to work on the UI design for the upstream integration. They asked me for some screenshots and screencasts and so Mohit has provided them. Mohit is also starting to look into work to be done on the main panel (list of printers/IPP services). PAPPL scanning support I also found a volunteer/GSoC-2023 candidate for doing the remaining work for the scanning support in PAPPL, Akarshan Kapoor. He has studied the project and created documentation for Bhavna Kosta's scanning API work of GSoC 2021. He followed the standards of PAPPL, auto-generating the documentation for the functions with Michael Sweet's codedoc and wrote an introduction manually. He only needed to do a few corrections in the comments of the code which codedoc turns into documentation (Thanks, Bhavna). Here is his pull request for PAPPL. Braille Printer Application I am currently helping GSoC-2022 contributor Chandresh Soni to fix a bug in his Pull Request to upstreamize the Braille Printer Application. Some of our contributors of GSoC 2022 and contributor candidates for GSoC 2023 have provided little write-ups: Mohit Verma
GSoC 2022 contributor on updating the \"Printers\" part of GNOME Control Center (G-C-C) for the New Architecture After my GSoC, I had worked on the new method of finding binaries as suggested by Marek Kasik but it didn’t prove to be useful since this method was returning the snap’s binary path. So, it was decided that it is better to add an IPP request to do this task. I had also started working on integrating Divyasheel’s Panel (DNS-SD Window), Shivam’s Panel (IPP Setup Window) & Lakshay’s Panel (Administrative-MF-Devices-GUI) in the G-C-C. I have completed integrating the DNS-SD window after removing the deprecated call’s and fixing some bugs. This window is now working fine. Currently, I am working on Administrative-MF-Devices-GUI Panel and IPP Setup Tool Panel. I am first trying to revamp the GUI to GTK4 along with fixing any bugs that come along. The second step would be to introduce Avahi DBus calls for the Discovery of Device and then finally integrating them into G-C-C. Gaurav Guleria
GSoC 2022 contributor on adding Common Print Dialog Backends support to the print dialogs of GTK and Qt After my GSOC, I have added few improvements to CPDB. Firstly some serious flaws in CPDB have been fixed, like major memory leaks and CPDB not supporting reconnecting to DBus once disconnected from it. CPDB now follows XDG directory specification instead of hardcoding system paths. CPDB also provides generic groupings for most IPP options so print dialogs can now separate the options into several tabs accordingly. Furthermore, CPDB now has full translation support, where the translations are fetched from the backends in user's requested locale. In cpdb-backend-cups, this is achieved by using translation support provided by cups-filters in catalog.h. Certain changes were also made to these functions (cfCatalog...) so that they accept locale as additional parameter instead of just defaulting to en-US. Finally, CPDB has now much more verbose debugging which should be really helpful since it'll make bug fixing much easier in the future, considering that CPDB is a fairly new technology. Chandresh Soni
GSoC 2022 contributor on turning the Braille embosser driver into a Printer Application After the GSOC period, I submitted a pull request to combine my braille printer application code with the cups-filters 2.0 braille support code. This was separated from cups-filters. In the following days, we will release version 1.0 of the braille printer application. I also corrected several errors in my code, which involved switching to a new cfFilterExternal, which is an updated version of ppd_ filter_external_cups and removing ppd support to make it work with newer cups. Kushagra Sharma
GSoC 2023 contributor candidate preparing for CPDB support in application print dialogs I have been studying the repository of chromium to locate and understand print backend and print dialog. I still need some time to get the gasp of whole thing and meanwhile Gaurav asked me to confirm with chromium team whether they need CPDB support or not and if they do agree how they expect it to be implemented. I will continue same for this week. If I need to change anything please let me know. I continued my study on the code base of chromium. I studied their print dialog implementation and print backend implementation for cups and had some discussions with Gaurav on CPDB. I have basic understanding of chromium and now I have started expanding my scope to CPDB as Gaurav is teaching me about its backend implementation. Thanks a lot for all this great work! Probably you remember the great Linux App Summit 2022 in Rovereto, Italy. We will this year have a Linux App Summit again, this time in Brno in the Czech Republic. Brno is home of a Red Hat office and so many of our free software colleagues are located there, especially those on GNOME. And they will be for sure on the LAS, making this year's edition an awesome conference. Update: Call for proposals is open right now!! Until Feb 18, 2023! Submit your great, awesome, and interesting talks, lightning talks, BoFs, workshops ... (No boring talks, please, or while you are on stage you will miss the best hallway sessions of the conference ...). I will also be there ... Now, with having a release (at least a beta) of all the important components: libcupsfilters, libppd, cups-filters, cups-browsed, pappl, pappl-retrofit, cpdb-libs, cpdb-backend-cups, cpdb-backend-file I have started to create Debian packages from everything so that it gets into the Debian and Ubuntu distributions. Unfortunately, Debian is currently entering the freeze for finalizing their Bookworm release. So their developers are going from the add-new-packages-and-new-features into the debugging phase. But fortunately, Debian has at least finally accepted the Common Print Dialog Bsckends (CPDB) components, cpdb-libs (ITP), cpdb-backend-cups (ITP), cpdb-backend-file (ITP) into Debian unstable (after a reminder on their printing mailing list). The versions are still 1.x versions though, the latest stable ones on OpenPrinting, for the 2.x versions libcupsfilters needs to get updated to 2.x first. But the update to the second generation of cups-filters will only happen after bookworm. So all further packages and updates to their new generations will, if at all before the Bookworm release, happen in Debian's Experimental branch. For getting new Packages into Experimental while most Debian developers are busy with Bookworm I get help from my colleagues in Canonical's Desktop Team, Sebastien Bacher and Jeremy Bicha, both long-time Debian developers with the appropriate experience and access rights, and due to Canonical more focused in Ubuntu. Thanks already no for the cooperation. For Ubuntu I can simply upload the new packages, or sync them from Debian (copy the Debian package without changes into Ubuntu), but, in contrary to Debian, the Ubuntu repository of free software packages is split into two parts: Main and Universe. The most important and essential parts of the operating system, which are covered by Canonical's commercial support, are in Main. Universe is a wide range of additional packages for Ubuntu, usually maintained by the community. Packages newly added to Ubuntu, like PAPPL for example, land in Universe. To promote a package into Main, a Main Inclusion Request (MIR) has to be posted into the bug tracker on Launchpad. This is to check whether a free software package is reliable enough to be a core part of a commercially supported operating system. It must be well-maintained, security vulnerabilities quickly fixed, code fulfilling security standards, depending only on other packages which are also in Main, ... The printing stack is usually a core part of the operating system and in Ubuntu, packages like CUPS, cups-filters, Ghostscript, most printer drivers, ... are in Main. Now several new packages which are entering via Universe have to transferred into Main with a MIR: cups-filters 2.x components: libcupsfilters, libppd, cups-browsed: Simplified MIR, PPA cpdb-libs: MIR cpdb-backend-cups: MIR cpdb-backend-file: MIR MIRs for PAPPL and libpappl-retrofit still need to get posted, and for libpappl-retrofit also the Debian package still needs to get created. For the new component packages of cups-filters we do only a simplified MIR, as the code is already in Main, in the old cups-filters 1.x and partially also in libcups (PPD support code). Therefore this change is only distributing the code into more source packages and not introducing new code. Here I want to thank Sebastien Bacher for helping me with the preparation of the packages for the MIR requirements, especially the new ones which got introduced after my last MIR several years ago. Another challenge was that I found an old package named \"libppd\" which was a library providing the PPD support functionality ripped out of libcups to LPD users, via the \"gpr\" and \"ppdfilt\" utilities. It stayed unmaintained (and forgotten) for more than 20 years while all the distros had switched to CUPS. This package is clashing with the name of the libppd of the new generation of cups-filters. I discussed its removal/renaming with Debian folks and we settled on renaming this into \"libppd-legacy\" after the Debian Bookworm release. The renaming has already taken place in Debian Experimental now, where all the packages of the New Architecture will go for now until Bookworm is released. For Ubuntu I asked for a complete removal, which is now done. So now nothing is in the way any more for the upload of the new packages, especially also libppd. During the selection and onboarding process for the GSoC 2023 (see above) we are assigning many of our issues on GitHub to contributor candidates for them to learn about our code base. This leads us to deeper investigation of several bugs and to fixes of them. Like with this issue: To get the full capabilities of a driverless IPP printer, a client (CUPS, or the driverless utility) needs to poll the attributes all and media-col-database with a get-printer-attributes IPP request (media-col-database is not included in all as it is often a very long list). Some printers cannot cope with the two being polled in a single request]. So I added separate polling of the two to work around this, and also parsing the media-col-ready attribute now, to lower chances to overlook something (like borderless printing support). I need to later on add the separate polling of all and media-col-database also in CUPS. During packaging of the components in Debian packages I have found and fixed some build system and documentation bugs and also an API bug discovered during the CPDB work. After that I have released the second beta: In addition to documentation and build system fixes discovered during the Debian packaging, the following changes have been done: libcupsfilters Filter functions did not handle the page size correctly when no printer IPP attributes are supplied (in case of classic CUPS filter no PPD file). Now if a page size is supplied with the job, this one is simply used, otherwise the sizes of the input pages and as a last mean US Letter. In the cfCatalog...() API for obtaining human-readable strings and translations of attribute/option and choice names, we added suport for specifying the user's UI language now, to receive the requested strings in the correct language, and not only human-readable strings in English. libppd In the PPD file generator for driverless printing with CUPS we now support more than 2 resolutions in Apple Raster/AirPrint. The urf-supported IPP attribute was only parsed correctly when its RS part had only 1 or 2 and not more resolutions specified. We have corrected now for an arbitrary amount of resolutions, taking the lowest for \"draft\", the highest for \"high\" and one in the middle for \"normal\" print quality. ppdFilterEmitJCL(): Added NULL check for PPD not being supplied. Classic CUPS filters created based on filter functions using ppdFilterCUPSWrapper() and also filter functions of libppd (ppdFilter...()) should also work without PPD file and not crash if no PPD file is supplied. The Printer Application for label printers, LPrint v1.2.0 (Snap Store) adds support for snap configuration and EPL/ZPL auto-typing support, and fixes a number of bugs. Changes include: Documentation corrections (Issue #53, Issue #76) Added snap server configuration. Added --with-systemd configure option and install to $prefix/lib/systemd/system by default (Issue #50) Added EPL2 and ZPL auto-typing support (Issue #64) Changed the default log level for systemd to info (Issue #82) Fixed macOS installer to start LPrint server (Issue #48) Fixed configure script not using warning/preprocessor options in build (Issue #60) Fixed printer renaming algorithm to not truncate the name (Issue #60) Fixed missing print-color-mode=bi-level for bar code printing (Issue #76) Fixed label mode support in EPL and ZPL drivers (Issue #79) Fixed driver names for EPL printers (Issue #52) More Details and Download Michael Sweet has released PAPPL 1.3.1. It is a general bug fix release. Changes: Fixed auto-add of USB printers Updated \"ipp-attribute-fidelity\" support Reduced sleep interval for USB gadget initialization More Details and Download GitHub Discussions"
+ },
+ {
+ "id": "post:OpenPrinting-News-January-2024",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - January 2024",
+ "url": "/OpenPrinting-News-January-2024",
+ "headings": [
+ "HP madness",
+ "FOSDEM 2024",
+ "Google Summer of Code 2024",
+ "Snap automation",
+ "What is hot on the OpenPrinting mailing list",
+ "New printing-users mailing list"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/W8IAszo8SjM/hqdefault.jpg",
+ "snippet": "HP madness, Framework printer?, tattoo printer, FOSDEM 2024, GSoC 2024, Snap automation, User mailing list",
+ "content": "You probably remember the October News, where, based on experience of some colleagues and also based on discussions on Mastodon, I changed from recommending HP printers to Brother printers. Unfortunately, there are many more reasons to move on from the formerly well-respected printer manufacturer, mainly their agressive enforcement of their razor-and-blades business model. Already before reading about all this, back on the Ubuntu Summit 2023 in November after attending Daniel Schaefer's great talk about Framework laptops and also getting a hallway demo from him, I came to the idea why Framework could not also make a modular, easily upgradeable and repairable multi-function printer and some weeks ago, I posted this idea on their community forum. I got a lot of likes, and D.H from Framework's Mainboard Developer Program gave a nice answer: I love the idea. Especially if the repairable items list expanded to power supply, main board, WiFi module, Ethernet module, etc. In my current case I have a 7 year old brother laser that is preventing me from going to all WPA3 network, because the firmware and/or WiFi chip in it does not speak WPA3. Economics make the printer space a difficult one to introduce a new, different, more complex, and by necessity slightly higher entry price point product. It would have to be paired with sufficient advertising, media coverage, etc to really sell the long term total cost to own advantage. Probably pretty easy for a professional IT department to do the cost analysis, effect the repairs, etc. A self managed small office, typical home office is certainly capable of the same but many will prefer to stay with commodity disposable hardware unfortunately. But yes from an e-waste and TCO standpoint, I love the idea of a repairable, upgradable, open source, etc paper printer, whether Framework or some other company decides to make it. I also take feedback on Mastodon. And the thread seems to have inspired Framework to cite the Ars Technica article about the HP madness on Mastodon. Many of you know that we work here with Structured deposition of ink and toner particles on paper substrates or, just printing. But some people do Structured deposition of ink particles into skin substrates Oh, this sounds like tattoos, a traditional art done by hand ... By hand? No, also for that we have printers. There are actually tattoo printers now, which print with inked needles into the human skin! But sorry, no color, only grayscale. Imagine and a kind of dot-matrix printer is doing its work on your skin ... Mastodon No information about the software used is known, though. So let us see what happened at OpenPrinting in January ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Hewlett-Packard (HP) was for long time a symbol for robust and reliable printer workhorses lasting for decades. And they also were a preferred brand for Linux users as they usually understood PostScript or PCL, and for the few which did not, quickly third-party drivers based on reverse engineering appeared as free software drivers. Also with the advent of driverless IPP printing HP printers behaved well and just worked. And for me as developer HP printers were a good choice as they still understand many languages, starting from good old PostScript and PCL up to the needs of driverless IPP printing, PDF and the different raster formats, and also some HP-proprietary languages and variants in addition. Also all communication protocols, LPD, raw socket, IPP, ... are present, which allows testing for compatibility with many old and modern printers. But in recent years, HP tried to enforce more and more their razor-and-blades business model on printers and multi-function devices, meaning that the printer is sold with loss to actually earn on the high prices for the ink or toner cartridges, where a new set of cartridges often costs near as much as the printer itself. They not only sell ink subscriptions where the printer \"calls home\" through the internet so that the user gets automatically sent new cartridges when the current ones are nearly used up but also started to add more measures against using third-party supplies. Especially they automatically install firmware updates via the internet adding these new measures to printers which are already around, without any warning to the user, making the printer suddenly stop working due to the third-party cartridges in use. This practise even led to a lawsuit against HP, and HP responds telling that it is for security reasons, as third-party cartridges could contain viruses which infect the printer and compromise the user's network. They call these updates \"Dynamic Security\". But if such a thing would be possible, it is a clear sign of bad design, as it would mean that cartridges contain executable code which the printer executes, or at least a way to inject code into the printer via forged data on the cartridge, but this requires a vulnerability in the printer's firmware plus a rather high amount of storage on the cartridge. A cartridge's chip is expected to contain some cryptographic signature and/or copyrighted data from HP to identify itself as original, plus info about the cartridges capabilities, perhaps also color calibration tables. All this should not require such a lot of storage, and well-engineered software can reliably read the data and reject it if not in the correct format. In addition, it is also not proven that such an attack ever happened. In the article it is also told that such kind of firmware updates make people refuse to update and so actual security vulnerabilities especially against attacks from the internet do not get fixed. Another trick to force users to buy original HP supplies is HP+. They offer an Instant Ink subscription to the user of a very cheap printer, with the first 6 months of ink cartridges for free, but couple it with a firmware update which makes the printer only working with original cartridges, and if the customer cancels the ink subscription, the firmware change is not reverted, excluding the use of third-party ink for the rest of the printer's live. And many of HP's printers have the EPEAT ecolabel which requires the printer accepting third-party ink. With the firmware updates revoking that permission the International Imaging Technology Council (IITC), representing the third-party ink/toner industry, wants to have these printers removed from the EPEAT list and they call these updates \"Killer firmware updates\". All this shows that HP does everything to lock in their users on original cartridges to make money ... And HP's CEO Enrique Lores actually admits that they are using the razor-and-blades business model, by telling that when you buy a printer, HP is investing in you, but if you do not print enough or do not use HP's supplies, it is a bad investment. In addition he tells that HP's long-term goal is to make printing a subscription ... Another interesting observation on an HP printer, on the very cheap DeskJet 2700, is that it comes with a sticker over the USB port telling to connect by Wi-Fi and not by USB. This printer was bought by Mastodon user netspooky and they tell in a post that HP most probably wants to make users install an app which lets the user's documents being stored in a cloud service from HP. They also tell that they made it working by Wi-Fi without the app (does most probably driverless IPP). This caused a long thread, with some people saying that the USB principally works but only for ~20 pages as long as the user did not install the app yet. And people tell that the app possibly tries to make users subscribe to the HP+ ink subscription, preventing them from being able to use third-party ink. And with all this, HP claims their printers are \"Made to be less hated\" (Mastodon) ... FOSDEM is approaching! This Friday, in the early morning I will fly to Brussels to attend the FOSDEM on Saturday and Sunday. And many people I will already meet on Friday, during the day and also at a dinner of former and current Canonical employees, mainly from the Desktop Team. And with Brno, the city of RedHat's Europe office, only 2 hours from Vienna, I could even meet one or another Red Hat person on my flight (Brussels Airlines SN2902 VIE - BRU 9:15am - 11:00am, on Fri, Feb 2, if you happen to be on the same one ...). Most of the sessions in the 32 rooms on the 2 days are already scheduled ... Most?! Yes, there are still some missing at this point in time, it seems that the lightning talk submissions are not yet all decided about, especially my two submissions are still pending: Opportunity Open Source conference in the IIT Mandi, India: Motivating people to be a part of us! Save Legacy Printers under Windows with WSL and Printer Applications On the Schedules page follow the links to the schedules of each room, full schedules for each day, in which room is which track, ... From my other 4 proposals which I have submitted two talks are accepted and scheduled now, and another talk and a workshop got rejected. So here are my scheduled talks up to now: (Update) Videos of the talks are available now. OpenPrinting - We make printing just work! On Sunday, February 4, 11:00 – 11:50 CET, in K.1.105 (La Fontaine) Main Track Video, Slides OpenPrinting: What it is, how it emerged, what we are doing, what are our challenges, what are we in need of ... (Update) I will give an overview of our organization and how we make printing just work. I will also give a short overview on the planned development on CUPS and tell about Windows Protected Print, the way Microsoft will switch to all-IPP printing in Windows. Zdenek Dohnal, printing maintainer at RedHat, originally wanted to participate, but unfortunately, he got sick and is not able to attend FOSDEM. We all wish him that he will get better soon. Desktop Linux, as easy as a smartphone! Just in a Snap! On Sunday, February 4, 13:30 – 13:55 CET, in UA2.118 (Henriot) Distributions Track Video, Slides There are many immutable distributions around, and several talks in the Distributions track are naturally about them, there will also be demos of several of them on the booths. But one immutable distribution is special as it is based on Snap, actually an all-Snap distribution, Ubuntu Core Desktop, and a Distributions Track, and especially one on a conference with many Canonical and Ubuntu folks, should not omit this distribution. And also Snap got 10 years old! (Thanks for the hint, Oliver Grawert) In this 25-min talk I will give a quick overview about how Snap, Ubuntu Core, and Ubuntu Core Desktop work, showing the advantages of a sandboxed packaging system which allows packaging everything, not only desktop apps, but also CLI apps, system and user daemons, desktop environemnts and even kernels, boot systems, and the immutable system core. (Update) During all the event there will also be several demos of Ubuntu Core Desktop, I will have a virtual machine of it on my laptop, Philipp Kewisch (Community Team manager at Canonical) plans to bring an Intel NUC with it, and Alan Pope (\"Popey\") will perhaps bring also a demo. He has succeeded to install and run it on his Steam Deck, but he is not sure whether he will bring this one. Note that we do not have an Ubuntu/Canonical booth. We will demo at the standing tables in the hallways, on Sunday most probably in front of the Distributions devroom (UA2.118, Henriot) where I will give my talk. So that's it from my presentations for now, but up to 2 lightning talks can still get added here ... For whom is not able to attend there will be live streams. I am not sure whether all rooms will do it, but very probably the Main Track (2 rooms) and the Lightning talks will do. Please check here for the links. The organizers of the Google Summer of Code will also be on FOSDEM and have a booth there, and there is a GSoC meeting/dinner on Saturday night, kind of mini Mentor Summit, which I will attend, to meet the organizers and also fellow mentors. And after that, also on Saturday night, there will be the GNOME Beers which I will also most probably join. For the 20th Google Summer of Code the time window for the mentoring organization applications has opened (closing on Feb 6) and so I have posted the application for the Linux Foundation (Mastodon: #LinuxFoundation) again, naturally with OpenPrinting participating as one of its sub-organizations. For this we have also set up our project ideas list, this time with a vastly updated introduction part about our work, now with sections for videos and for desktop integration. And there are 9 project ideas this time (further ones can get added later): Desktop integration: CPDB support for the print dialogs of Mozilla (Thunderbird/Firefox) and LibreOffice Desktop Integration: Update system-config-printer for the New Architecture of printing Desktop Integration: User interfaces for using OAuth2 with printers and scanners Replace QPDF by PDFio as PDF manipulation library in libcupsfilters (cfFilterPDFToPDF() filter function and others) Turn cups-browsed into a Printer Application Converting Braille embosser support into a Printer Application Make a native Printer Application from Gutenprint CI Testing programs for libpappl-retrofit and libppd cups-filters: Create OCR filter to deliver scans as searchable PDFs Please contact us at any time if you are interested in being a GSoC contributor for OpenPrinting on one of these projects or on your own project idea. We also have already many contributor candidates doing assignments, in stage 1 building CUPS and cups-filters, learning about the code, the printing architecture, driverless printing, ... in stage 2 working on issues in cups-filters, CUPS, and other OpenPrinting projects, and in stage 3 learning about the project in which they want to do their GSoC work. Especially to mention here is Rudra Pratap Singh, to whom I have give the task of introducing Snap update automation into the 4 Printer Application Snaps at OpenPrinting as a stage 2 assignment. It is principally a rather easy task as the steps are well described in my Snap automation workshop (video, slides). But he went far beyond his task. See below ... As most of you already know, we are offering several Snaps in the Snap Store: CUPS, ipp-usb, and several Printer Applications. All these Snaps need maintenance, especially they are composed of several different upstream packages, which means that whenever of one of these upstream packages a new release is issued, the Snap needs to get updated. This causes a significant amount of maintenance work, especially many upstream projects need to get followed to not miss any new releases. In the Desktop Team at Canonical, Heather Ellsworth (currently at Thunderbird), has developed a GitHub action to automatically update Snaps when one of their upstream components has issued a new release, as we have to deal with many Snaps for Ubuntu and especially also for Ubuntu Core Desktop. Applying Snap update automation As the procedure is rather simple to apply to existing GitHub repositories following above-mentioned article, or even better, my workshop about Snap update automation (video, slides), I have given it as an assignment to a contributor candidate for GSoC 2024, Rudra Pratap Singh. He started modifying the 4 Snaps of the retro-fitting Printer Applications according to the instructions and it mostly worked afterwards, but he has also bumbed into some issues. And here is the point where he really showed his engagement, as he solved all these problems. foomatic-db foomatic-db, the printer/driver database, is used by 2 of the 4 Printer Application Snaps, the PostScript Printer Application and the Ghostscript Printer Application, for the former providing manufacturer PPD files for PostScript printers and for the latter providing the data for building PPD files for all the built-in printer drivers of Ghostscript ad even some more drivers. As foomatic-db is pure data, not containing any code, we have never issued official releases of it. For easier handling by OS distributions we have a cron job which creates a tarball of it, once a day, versioned by the date of the day. There are no release tags in the repo. So I suggested Rudra to add a GitHub workflow to the foomatic-db repo, to once in 24 hours check whether there was at least one commit in the last 24 hours and in this case create a release tag. This way on each day with at least one commit the Snap update automation of the Printer Application Snaps get triggered, and not on days without any change. Rudra got it quickly working without any problems. Automation GitHub action: More versioning schemes and Debian GitLab support Even Canonical's GitHub action itself got some changes from Rudra. The original GitHub action only supported release tags containing up to 3 integers embedded in a fixed string. So we bumbed into problems with some new, not yet finally released software of OpenPrinting (pappl-retrofit) from which we are using a beta version and also with Debian packaging as upstream code where we have the more complex Debian package version number. So I suggested Rudra to modify the GitHub workflow to allow free-formed version numbers and he added this functionality and posted Pull Request #487. After that he posted Pull Request #489 to support repos from Debian's Salsa GitLab as upstream source, as due to the fact that there is no \"gitlab\" in the URL, they were not identified as GitLab repos. To complete, he posted also the two further Pull Requests #490 and #493. All of them got merged by my Desktop Team colleague Sergio Costas, who also guided him on these pull requests. With all this the Snap update automation on the CUPS Snap and the 4 Printer Application Snaps is working now. Snap versioning automation Another point is the version number of the Snap. It would be useful if Snaps have a versioning scheme like DEB or RPM packages, the version number of its main upstream package plus a package release number, like cups 2.4.7-1. If there is a new version of the upstream package, its version number in the Snap's version number will get updated and the package release number reset to 1. If changes made are only on the packaging or on auxiliary upstream repos, the package release number will get bumped: 2.4.7-1 -> 2.4.7-2 -> 2.4.8-1 -> ... This way on any change the Snap gets a new version number, without needing to create an over-complex numbering scheme. Scripting for this I had already in the CUPS Snap, and made it completely working recently. I asked Rudra to add this scripting also to the Printer Application Snaps and he did. And as all the Snaps now contain complex scriptlets which are practically identical, and therefore on any change on the scriptlet one had to update 5 Snaps, I came to the idea to move this functionality into the Snap update automation GitHub action and Rudra posted Pull Request #516. This Pull Request is still in the works and Sergio Costas is guiding Rudra again to correctly integrate his changes. The posting of the Pull Requests and the work with Sergio to get the Pull Requests merged, Rudra did without needing my help, completely on his own. Thanks a lot to Rudra and Sergio for that great work! Current interesting discussions We had some interesting discussions in the last weeks. See the mailing list archives. The following links are to the initial posting of each thread: Printer's IPP response declares AirPrint, but it's missing urf-supported - workaround?: Another firmware bug in a driverless printer and whether we should have a workaround Congrats, Mike! IPP Everywhere is now really Everywhere!: Microsoft Protected Print - all-IPP printing in Windows CUPS Trademark: Are there no trademark issues with Apple when CUPS moved to OpenPrinting? If you want to participate, please subscribe following the links on the \"printing-aechitecture mailing list entry on this page. e-mail: printing-users AT lists DOT linux DOT dev Archive: https://lore.kernel.org/printing-users/ Subscribing/Unsubscribing instructions A first discussion thread already appeared: Cups automatic duplex printing problems: User cannot print duplex on autodetected printer"
+ },
+ {
+ "id": "post:OpenPrinting-News-July-2020",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - July 2020",
+ "url": "/OpenPrinting-News-July-2020",
+ "headings": [
+ "NEW: The OpenPrinting web site got comments sections",
+ "Google Summer of Code 2020",
+ "Google Season of Docs 2020",
+ "Linux Foundation Mentorship Program",
+ "CUPS Snap",
+ "Driverless Scanning and IPP-over-USB",
+ "CUPS",
+ "cups-filters",
+ "IPP-over-USB: ippusbxd and ipp-usb"
+ ],
+ "tags": [],
+ "snippet": "We take comments! Students working in GSoC, GSoD, LFMP; libppd and pclmtoraster in cups-filters",
+ "content": "Our web pages, these news posts but also most other pages have a comments section now. So you can leave your comment about the page in the comments section at the bottom. The first evaluations have ended and all the 15 students for the Linux Foundation have passed, including the 7 for OpenPrinting. Most of our 7 students also gave a short introduction to their project on this month's OpenPrinting tele conference. Some student's work reports for the first month: Mohit Mohan Hi everyone, I am Mohit Mohan, junior at IIT Kanpur in the CSE department. I am a GSoC student this year working with Open Printing on the project “Speed/Scaling optimisation of cups-browsed”. As the first coding period completed a few days back, I wanted to inform you all about what I did in that time. But first a bit about the problem with cups-browsed. The cups-browsed is a very useful tool for networks with large numbers of printers, but as it discovers the printers on the network one by one, so as the number of printers increases, the time taken to create a queue for all of them greatly increases. To understand more about this issue I tested cups-browsed with different numbers of printers to find out how much time it takes to create queues. Next thing to find out was where it was taking most time. To do that I found out time taken by some of the important functions during a queue creation. From the results it was quite clear that update_cups_queues() was taking the most time. This function actually creates the queue. As my mentors Till Kamppeter and Deepak Patankar suggested I looked at where it was taking most of the time in update_cups_queues(), and found out that it was cupsGetNamedDest(), which is a part of CUPS API to get a specific destination from the list of available destinations. We tried all available alternatives, but none of them worked faster than it, so in the end we decided to stay with it. You can find the above results at https://github.com/mohitmo/Testing. I also created a design document for implementing multi-threading in cups-browsed. You can find it here. In the next phase I am working on implementing multi-threading in cups-browsed. Jai Luthra [...] here's my progress with PAPPL. Device discovery via DNSSD, SNMP. Command line interface (papplMainloop) PCL driver (CUPS rastertohp) example Next for work is the packaging and documenting the driver. During the last months was also the time window for the technical writer's applications and we got actually many applications, also for the 2 OpenPrinting projects. Some of the candidates were already interacting with us while writing up their proposals. We got accepted in the LFMP for a 2-student project letting one student to create a framework for converting existing proprietary printer drivers intp Printer Applications and another student to integrate IPP Fax Out support into the Linux desktop. The project is currently open for student applications and the work period will be August 1 to October 31. Several students have applied already and to introduce them into OpenPrinting and select them we have given the cups-filters issues to work on as assignment. The Snap is now renamed to simply be the \"cups-snap\" project on the OpenPrinting GitHub and \"cups\" in the Snap Store. The build service of the Snap Store is now attached to our GitHub repository and builds the CUPS Snap for 6 architectures (amd64, i386, armhf, arm64, ppc64el, and s390x). Note that the CUPS Snap cannot be downloaded and installed through the Snap Store yet as it will need new \"cups\" and \"cups-control\" interfaces which are not yet added to snapd. I have already tested them and they work as expected. I have tested the CUPS Snap a lot during the last month and fixed a lot of bugs, especially make all components build on all the 6 architectures supported by the Snap Store, make utilities like lpoptions, cupsfilter, and driverless correctly work, make DNS-SD-service-name-based URIs correctly resolve if the service is local (Printer Application or IPP-over-USB), and updated the README.md to reflect the renaming and the current use of interfaces. Alexander Pevzner, author of the IPP-over-USB daemon ipp-usb and of the AirScan/eSCL/WSD scanner driver sane-airscan asked me to post the news of his work: sane-aiscan Though sane-airscan is not included into any any major distro, its popularity among users grows, and it receives more testing on a growing variety of hardware. Most of newly discovered issues are either firmware bugs that require workarounds, or certain corner cases, like not running Avahi daemon or device announces 2 IP addresses, one of them is not reachable from host. A couple of hard to reproduce crash bugs were found and fixed with a help of clang static analyzer. Added packaging for ARM32 and ARM64, targeting Raspberry Pi users. There already 7 devices in the list that supports WSD, but doesn't support eSCL, so idea to implement WSD was useful. Integration into SANE project seems to finally stuck. Meanwhile I work directly with Benjamin Gordon on integration into ChromeOS and Zdenek Dohnal on integration into Fedora. ipp-usb Initially ipp-usb was targeting distro maintainers. That is why its initial documentation is rather short technical and no binary packaging were provided. Recently I've discovered certain interest among end users to install and use ipp-usb. So I've provided packages for many distros, including ARM32/ARM64. It also known to work on mipsel Linux, but I can't provide packaging for this platform due to OBS limitations. As with sane-airscan, growing popularity implies more testing, and some issues were discovered and fixed. Some users were interested into direct exporting printer into local network segment, which is safe and reliable with ipp-usb. In result, incompatibility with iOS devices were found and fixed (Android devices were always working). This fix was ported to ippusbxd too. Most of other issues are of the same class: device returns truncated HTTP response, and ipp-usb stuck forever, waiting for missed part of response, which effectively blocks USB connection. The solution is also the same in all cases: properly set \"Connection: close\" or \"Connection: keep-alive\" header in outgoing HTTP request. Unfortunately, different device require different setting of this header. As it is hard to organize testing on hundreds of devices, more generic solution of this problem is required. Zdenek Dohnal seems to begin working on integration of the ipp-usb into Fedora. The projects are not only on the way into Red Hat but also into Debian. Packaging requests for both ipp-usb and sane-airscan have been posted and Didier \"OdyX\" Raboud, printing maintainer of Debian, has taken up both and uploaded the appropriate packages. Also thanks to Brian Potkin to post the request for ipp-usb. Currently released is 2.3.3. No further releases or GIT commits, also 79 open issues and 18 open Pull requests. Only few answers from upstream developers. I have asked several people about what is happening here but did not get really clear answers, but it seems the learning needed by the new engineers, COVID-19, and the switch of Apple from Intel to ARM architecture have influence on this. I am thinking about as a last mean to temporarily fork CUPS so that distribution maintainers can collaborate on fixing bugs there. Currently released is 1.27.5. No new release, due to the fact that I am currently on a major feature addition which I want to complete before releasing 1.28.0 and which is important for the switch over to Printer Applications: libppd One important point for the CUPS Snap is that it does not support classic printer drivers, consisting of PPD files and filters. So for using it as default CUPS implementation in a Linux distribution, all existing printer drivers need to get turned into Printer Applications, and this with a minimum effort of coding. Most of them (probably all except Gutenprint) are difficult to get converted by their original authors, as they do not maintain the drivers any more, supported printers are old and no one wants to code for that any more, driver is simply only a big bunch of PPD files, no code, driver is proprietary, closed source, ... So we need a way to retro-fit these drivers by wrapping them into Printer Applications with lowest coding effort possible and if needed also without needing to modify the original driver executables. This works best if we use the driver's PPD files inside the Printer Application and so we need to handle PPD files, also after the PPD handling support got removed from CUPS and especially libcups. To avoid that we have to invent the wheel again, writing a lot of handling code for a totally obsolete file format, I have grabbed all the PPD handling functions from libcups (current GitHub state, CUPS 2.3.3) and put them into the new libppd which I have added to cups-filters. It has the following properties: All PPD-handling-related functions from libcups (except loading the PPD from a CUPS queue or polling a PPD repository on a CUPS server) are overtaken Also the CUPS-private functions related to PPDs are overtaken and added to libppd's public API. Other private or internal functions are overtaken from libcups as they are needed for the PPD-related functions to work. They are not added to the API. Some functions of tools and utilities like ippeveprinter and ippeveps are overtaken. All API functions have names starting with \"ppd\" and written in camel-case, some needed to get renamed for that. libppd is separate from libcupsfilters, so it does not need to get included in a Printer Application which uses functionality of cups-filters but does not use PPD files NOTE: This is NOT to encourage printer driver developers to continue to create new PPD files for new printers. It is ONLY for retro-fitting existing classic CUPS drivers and PostScript PPD files. There will be no further development on the library's code, especially no new PPD format extensions. The next release of cups-filters, 1.28.0, will contain libppd for the first time. It is already, shortly before completion for 1.28.0 in the GitHub repository, in the ppd/ subdirectory. Further work: pclmtoraster GSoC student Vikrant Malik's project is to extract raster data from PDf files which only consist of embedded raster images, not containing text, fonts, or vector graphics. This allows for higher print quality of such PDFs as input files (for example scanned files) and also to convert PDF output of scanners into dedicated raster formats like TIFF, PWG Raster, ... One known raster-only PDF format is PCLm and therefore Vikrant has started his work by adding the new pclmtoraster filter to cups-filters. He also worked a lot on converting raster formats between color spaces an bi depths. Bug fixes Many bug fixes in cups-browsed, the filters, and the sample PPDs have been performed, often with the help of our GSoC students or candidates doing assignments. Thanks to all of them. Note also that the sample PPD files have moved to the new ppdfiles/ subdirectory. ippusbxd got some bug fixes and improvements from Fletcher Woodruff (PR #38 and #43) and Thierry Hucahrd (PR #41). Thanks very much to the contributors. In ipp-usb Alexander Pevzner added lots of bug fixes and hardware workarounds/quirks. Thanks to all the users who have tested with their devices and reported their problems. Probably many more users will have their device just work by that. ipp-usb is on the way into Red Hat (according to Alexander Pevzner) and also into Debian. This is the packaging request and Didier \"OdyX\" Raboud, printing maintainer of Debian, has taken it up and uploaded the appropriate package. Also thanks to Brian Potkin to post the request."
+ },
+ {
+ "id": "post:OpenPrinting-News-July-2021",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - July 2021",
+ "url": "/OpenPrinting-News-July-2021",
+ "headings": [
+ "Google Summer of Code 2021",
+ "CUPS Snap",
+ "PostScript Printer Application",
+ "Retro-fitting of CUPS printer drivers into Printer Applications",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "GSoC mid-term, PostScript Printer Application, Retro-fitting CUPS printer drivers, CUPS, cups-filters",
+ "content": "The mid-term evaluations are done now and all our 5 students have passed. Thanks a lot to them for the great work they did during the first half of the coding period. On this month's OpenPrinting conference call all students participated giving a short screen-share-based presentation of their GSoC projects. Here is some short summary about what got done: cups-filters: Make sure all filter functions work without PPD files
Student: Suraj Kulriya
Mentors: Jai Luthra, Till Kamppeter, Dheeraj Yadav Suraj made the following filter functions working also without PPD file, based on printer and job IPP attributes: rastertopdf() ghostscript() texttotext() imagetoraster() pdftops() imagetopdf() He also created some library functions for common functionality needed here, like a function which converts IPP attributes to option lists. cups-filters: Convert filters to filter functions
Student: Pratyush Ranjan
Mentors: Till Kamppeter, Dheeraj Yadav Pratyush converted the following CUPS filters to filter functions: pdftoraster() rastertopwg() (filter from CUPS) cups-filters: Create a single, universal CUPS filter to replace the chain of individual filters
Student: Pranshu Kharkwal
Mentors: Till Kamppeter, Dheeraj Yadav Pranshu is making very good progress on the universal CUPS filter. Most conversions already work. It also depends on the progress of Pratyush to convert filters to filter functions. The code can be found in this GitHub branch. GUI for listing and managing available IPP Print/Scan services (or DNS-SD-advertised network services in general)
Student: Divyasheel
Mentors: Till Kamppeter The graphical frontend part is mostly done and in the second half the internal functionality, like Avahi browsing and so on, will be worked on. Here is the GitHub branch with the code. PAPPL: Printer setup tool support and Scanning support
Student: Bhavna Kosta
Mentors: Jai Luthra, Till Kamppeter, Michael Sweet The original project, \"Firmware and other file handling in PAPPL\" turned out to be not that useful and so we decided to switch to other PAPPL work. I presented the list of feature requests on PAPPL and Bhavna decided to start on features to support printer setup tools and after that to add scanning support to PAPPL. For printer setup tool support I earlier requested to have device IDs listed with the drivers when listing all included drivers of a Printer Application with the drivers sub-command and to make Printer Applications tell whether a printer is supported by them if one supplies the printer's device ID. Bhavna implemented both these features via pull requests, the one for the former got already merged and for the latter not yet. After that, Bhavna started on scanning support, which should not be too difficult do to the fact that Michael Sweet already posted an excellent project description. Here she already posted 3 pull requests: \"Add scanner object and header files\", \"Add scanner.c and scanner-accessors.c files\", and \"Add scanner-driver.c\" CUPS Snap in the Snap Store, Call for testing on the snapcraft.io forum and on the Ubuntu Discourse, more than 2000 installations via Snap Store I am still waiting for the snapd team to implement the security concept on the snapd side, but unfortunately, they are very busy currently. A pull request with a suggested implementation of the new \"cups\" interface to which client Snaps which just want to print are supposed to plug automatically got posted and discussion on it has happened. There got also posted a test package of snapd with which I could confirm that the implementation is actually working (see my comments on the pull request). Once this pull request is merged, as a next step a pull request on snapcraft for easily using the interface in client application Snaps is planned. In addition, the CUPS Snap uses newer upstream sources for its components now, of QPDF version 10.3.2 and of cups-filters the current GitHub master branch (2.x under development). Main TODOs are: Complete the security concept on the snapd side, especially implement the content interfaces (see above) Testing Turn classic CUPS drivers into Printer Applications (see progress below) Add a migration script so that OS distributions can easily switch over from classic packages to the CUPS Snap PostScript Printer Application in the Snap Store, Call for testing on the snapcraft.io forum and on the Ubuntu Discourse, more than 1200 installations via Snap Store I Continued on the support for CUPS filters used in PostScript PPD files, also in preparation for retro-fitting of actual CUPS drivers, adding the following features (follow the links to the commits for more detailed descriptions and motivations): Added foomatic-rip to the Snap (for PIN-secured printing on Ricoh) Support for CUPS' PPD extension for custom (string, integer, ...) option settings Added parameters like job UUID, date/time of submission/processing, ... to calls of external CUPS filters On the Snap's included PAPPL applied the patch for custom string option support (PAPPL's PR #142) With all this now all ~4000 PostScript printer PPD files which come with the Snap are fully functional, especially also supporting PIN-secured printing on HP and all Ricoh brands. Note that these changes only apply to a few PostScript Printers and only to enable features which are not used very often, but they are especially done with general retro-fitting of CUPS printer drivers in mind, where CUPS filters defined in the PPD file and string/text/numeric/fax number options are more commonplace. With appropriate features added to PAPPL we will be able to also add the following: Support for string/text-style vendor options. Needs support in PAPPL (Patch already applied in the Snap). Human-readable strings for vendor options. Needs support in PAPPL. Ink level check via ps_status() function. Needs support in PAPPL. Once having these features implemented, the PostScript Printer Application is complete so far. Currently I am continuing with the work towards retro-fitting classic CUPS printer drivers into Printer Applications. Here I have especially done the following: Turning the PostScript Printer Application into the retro-fit library To start the planned libpappl-retrofit library I have taken the PostScript Printer Application and modified the functions it is composed of to make them \"library-ready\" and to generalize them to support all types of drivers and PPD files, especially also non-PostScript ones. I have done the following modifications on the original ps-printer-app.c file: Get rid of global variables: Instead of using global variables for data which should be accessible from all the functions I have created a data structure (pr_printer_app_global_data_t) for all these items and carry it through the whole Printer Application via the context data pointer of the callback functions. Generalization of data conversion methods: Depending on what kind of driver (High-level graphics like PostScript or PDF or raster/bitmap graphics) you want to accept different sets of input formats and therefore have different format conversion methods. For spooling (usually high-level graphics) conversions there is an array of pr_spooling_conversion_t records and for streaming (usually raster) conversions an array of pr_stream_format_t record now, with input and output data types, and filter functions to be used for the conversion (Hint: If you need more than one filter function for a conversion, simply use the filterChain() filter function). Easy configuration of the Printer Application by the implementer: One only needs to put some basic data into a structure of type pr_printer_app_config_t (which is a part of the global data structure), create the arrays of data format conversion methods in priority order, make sure that the CUPS filters and PPD files are at the right place, and call the Printer Application's main loop. Can all be done in the main() function. Future library functions start with pr_..., the ones starting with ps_... are specific to the PostScript Printer Application. As a sneak preview I have uploaded the code as an attachment to a GitHub discussion. Or simply download it directly: ps-printer-app.c.txt To try it out, take the GIT master of the PostScript Printer Application and replace its ps-printer-app.c file by this file. Then build the Snap (or build classically with newest snapshots of cups-filters and PAPPL) as described in README.md. As a result you should get the PostScript Printer Application with its usual features, probably indistinguishable from the original, but with the new innards. And this will also be the future of it, once the library is started as a new GitHub repo at OpenPrinting. pwgtoraster() filter function Many of the classic CUPS drivers are the so-called CUPS Raster drivers, where the job in a device-independent, designed-for-printing, standard raster format, CUPS Raster, is fed into a CUPS filter, usually with name starting with rasterto, which turns the input into the printer's native, often proprietary language. One can easily recognize these filters by a line like in the PPD file. Retro-fitting those into a PAPPL-based Printer Application is not trivial, especially if one wants to use the streaming raster-printing mode of PAPPL, which is once required to be supported in a Printer Application and second, very useful for large jobs and especially large paper sizes and that even more in combination with low-spec IoT devices. In spooling mode the retro-fit of these drivers is easy, as one can easily call the filter chain which CUPS would use. In streaming raster mode we run into the problem that CUPS Raster supports a lot of different, often exotic color spaces and that also in several different color depths. This would mean, that the 5 raster printing callbacks (start job, start page, print pixel line, end page, end job) need to be able to convert the input into all these color spaces. To implement this only for retro-fitting old drivers is a lot of work, especially as we have this already nicely working in cups-filters, in the gstoraster and pdftoraster filters (ghostscript() and pdftoraster() filter functions). So I have gone another way: The pdftoraster() filter function has everything to convert the 8-bit RGB raster output of Poppler into any of the color spaces needed for CUPS Raster, and this filter already exists for long time and just works. So I have derived a new pwgtoraster() filter function (there is also a pwgtoraster CUPS filter executable for easy testing) from the pdftoraster() filter function, throwing out Poppler and taking PWG Raster as input, allowing only the color spaces 1-bit monochrome, 8-bit grayscale, and 8-bit RGB and converting to the destination color spaces from these. As what the raster printing callbacks of a Printer Application receive is more or less PWG Raster I can simply pass through this raster data when pre-filtering with pwgtoraster() before calling the rasterto... filter defined in the PPD. The new filter function has the following special properties: As streaming as possible: For chunked and banded color orders the data streams \"by-pixel-line\", meaning that a line is read from the input, converted, and immediately sent to the output, before the next line is read. Only when the colors are ordered in planes the streaming is only \"by-page\". Pre-conversion of resolution and color space: The resolution and color space/depth/order for the CUPS Raster data to be fed into the filter is not simply defined by options and choices with intuitive names, but by the PostScript code attached to the choices of the options in the PPD which are selected for the job, like <>setpagedevice or <>setpagedevice. The CUPS filters collect all of the selected ones and interpret them with a mini PostScript interpreter (ppdRaterInterpretPPD() in libppd) to generate the CUPS Raster header (data structure describing the raster format) for the page. Unfortunately, resolutions are not always defined in the \"Resolution\" option (for example in \"Print Quality\" instead) or the resolution values do not correspond with the human-readable choice names, same for color spaces not always defined in \"ColorModel\". As with this the information the Printer Application has from the PPD often does not reflect the driver's actual requirements, the filter function pre-converts resolutions and color spaces as needed. Note that the integration of this filter function into the retro-fit Printer Application code is not yet done, meaning that a CUPS Raster driver retro-fit will not work yet. Capturing of stderr output in the log Printer Applications with PAPPL have a nice logging facility and filter functions in cups-filters support this logging facility. Now I have added capturing of stderr of the called external CUPS filter executable for logging to the new filterExternalCUPS() filter function (see last month's news) and also capturing of stderr of Ghostscript to the ghostscript() filter function. This way the stderr output gets correctly into the log file of the Printer Application instead of leaking into the syslog. Currently released is 2.3.3op2. Development of CUPS 2.4 is in progress, currently mainly fixing of bugs which were reported to Apple's CUPS GitHub in the last 18 months. Ubuntu Hirsute Hippo (21.04) comes with CUPS 2.3.3op2, the CUPS Snap and the PostScript Printer Application Snap use the current GIT master. Currently released is 1.28.9. Feature additions are principally done for retro-fitting classic CUPS drivers, see details in the separate section, but also work of our GSoC students: Added pwgtoraster() filter function In filterExternalCUPS() and ghostscript() filter functions now stderr output of external executables is captured for logging rastertopdf(), ghostscript(), texttotext(), imagetoraster(), pdftops(), and imagetopdf() support printer and job IPP attributes now and so do not need PPD files any more The pdftoraster CUPS filter is converted to a filter function now The rastertopwg filter of CUPS is now added as filter function rastertopwg() Also several bug fixes were done: cups-browsed: Make NotifLeaseDuration configurable and renew after half the lease duration not 60 sec before end The pdftopdf() filter function now works correctly with unseekable input Removed unneeded test code from libfontembed Fixed pdftopdf() filter function to correctly support page ranges without upper limit, like \"10-\" Minor fixes 1.28.9 Bug fix release, fixes backported from the master (2.x) branch (see below) Ubuntu Hirsute Hippo (21.04) comes with cups-filters 1.28.8, also the CUPS Snap currently uses this version. The PostScript Printer Application Snap uses the current GIT master of cups-filters. Currently released is 1.0.3. See also the currently open and closed issues of PAPPL."
+ },
+ {
+ "id": "post:OpenPrinting-News-July-2022",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - July 2022",
+ "url": "/OpenPrinting-News-July-2022",
+ "headings": [
+ "New web pages about our work",
+ "GUADEC 2022",
+ "Google Summer of Code 2022",
+ "CUPS Snap and snapd printing interface",
+ "Approaching cups-filters 2.0",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "New pages about our work, GUADEC, GSoC 2022 projects, \"cups\" snapd interface bugs fixed, PPD-independent cups-filters 2.x, CUPS",
+ "content": "At Canonical I got told some weeks ago that someone asked what Canonical is doing for printing with Linux. The person seems not having been aware that Canonical is paying me to lead OpenPrinting full-time. This brought us to the idea to soon post a Ubuntu Blog article and to support such an article we need more detailed information about what OpenPrinting is doing, to link it from there and also partially re-post it in the blog. Therefore I have decided to add three articles to our static web site (not the News and Events blog series here): How did this all begin? Our principal achievements What we are currently doing The first is derived from my blog article about how I got started with OpenPrinting, the second one is about what we have achieved in all the time, and the third will be about what we are currently doing. The first two are already available (simply follow the links) and the third I will write soon after I an back from GUADEC. The new pages are all linked from our \"About Us\" page. GUADEC 2022 in Guadalajara in Mexico is approaching! Next week we will celebrate the 25th anniversary of GNOME! It is the first time for me to attend a GUADEC and also the first time for me to visit Mexico. In my talk (July 21, 14:20 - 15:00 local time, Bosch Auditorium) I will spread the news about our GSoC work on the \"Printers\" module of the GNOME Control Center and on the GTK print dialog and also introduce the GNOME Community into the New Architecture of printing and scanning (Update: slides). You will probably often enough find me at the Canonical booth (or better gathering table, see last month's news). If you cannot make it to Guadalajara in Mexico but to Berlin, you can get to a satellite event, the Berlin Mini-GUADEC 2022 in the C-Base and meet Berlin's/Europe's GNOME community and besides local sessions, hackfests, ... also have a public viewing of the complete GUADEC. And some talks of the GUADEC are even performed in Berlin and transmitted live to Mexico. This is the wonderful world of hybrid (in-person + online) conferences! Now we are one month into the coding period of the Google Summer of Code 2022 and all our 8 contributors are doing great work! All of them have posted a little summary of what they have done in our group chat on Telegram: Converting Braille embosser support into a printer application
Contributor: Chandresh Soni
Mentors: Till Kamppeter, Samuel Thibault
I researched the existing implementation of Braille in cups-filters and how things operate to have a general concept of how braille embossers work and what functionality they bring. I learned about liblouis and ImageMagick, which are used to transform basic text or images to Braille. I've also configured a virtual BRF printer. Now I'm attempting to implement the current filter features, which is converting old shell scripts to C. Scanning Support in PAPPL
Contributor: Deepak Khatri
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
I have already looked over PAPPL code and some implementations of it, and it is functioning well. I've also seen the PAPPL scanning work that Bhavna Kosta and others have done in the past. I'm currently going through the current PAPPL scanning issues. I'll try to fix some of the issues in the approaching days as I continue working. Adding Common Print Dialog Backends (CPDB) support to existing Print Dialogs
Contributor: Gaurav Guleria
Mentors: Till Kamppeter
Hello. I have been working on writing the GTK CPDB print dialog backend, and it's going good. It has been a bit slow, as there is no online documentation regarding it and I have to constantly refer the GtkPrintBackendCups and GtkUnixPrintDialog files along with various others. Some of the files aren't even commented and follow old Gtk code conventions, so it takes some time to understand them (I even talked to Emmanuele Bassi about this). Nevertheless, due to the progress I had made earlier as well as putting in some extra hours, I will be able to complete it by the end of first month of GSoC as proposed in the timeline. I plan to finish it by this week, so I can fix any bugs or continue with the qt backend. I just have to add support for multiple backends, configure media-margins and borderless option properly, and add a few more things. I also fixed some more issues with the cpdb-backend. Gaurav's GitHub repository GNOME Control Center GUI for discovering non-driverless printers and finding suitable Printer Applications for them
Contributor: Mohit Verma
Mentors: Till Kamppeter, Michael Sweet, Pranshu Kharkwal, Divyasheel, Deepak Patankar
Hello all, I am currently working on updating the discovery of devices in cups-pk-helper.We will use PAPPL, Printer apps, and lpinfo (as long as it is accessible) in the new approach of device discovery .I had to understand the current functions of cups-pk-helper and the general architecture of G-C-C, which was using it to locate and configure printers.I will try to complete this by next week.After that, I will be working on creating a GUI for printer application set up dialog whose design is ready. I will be sharing the design on the link given below once I am done updating cups-pk-helper. One of the most challenging task for me till now was to use gnome-builder to build current branch of G-C-C. There were too many dependency errors and other weird errors while building it.I had to ask for help at several Gnome IRC channels and even creating a issue at gnome-builder gitlab's page.Finally, I was able to build it successfully after a lot of errors and using few tricks suggested by Christian Hergert(maintainer of gnome-builder).Here's the link for discussion on the new printer dialog. Issue report with discussion on Mohit's work. Scanning Support in PAPPL with eSCL Support
Contributor: Rishabh Maheshwari
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
I have completed learning about both AirSane and PAPPL and have marked the important files and some other related files in them and I have prepared short notes for the description and usage of these files. Currently, I am trying to use the code from AirSane and use it in PAPPL in one of the scan functions to make our eSCL parser by making the required changes in it in. Add Avahi calls for discovering and resolving driverless IPP printers and Optimize the processes
Contributor: Sachin Thakan
Mentors: Till Kamppeter, Michael Sweet, Deepak Patankar
Hi all, until now I was doing online reading and trying to understand the implementation for service discovery using avahi and bonjour. From this week I starting to work on segregating the tasks of service browse and service resolve and will try to finish the utility for at least one of them and subsequently make a push. Make a native Printer Application from Gutenprint
Contributor: Sahil Kumar Dhiman
Mentors: Till Kamppeter, Michael Sweet, Solomon Peachy, Robert Krawitz
I have been actively working to understand the PAPPL framework. I have learnt basics of PAPPL and proceeded to knowing the libgutenprint library. I had made myself familiar with the most of the APIs. Having read and understood the workflow of hp_printer_app I have begun modifying the code for Gutenprint Printer Application. The hard task of getting the capabilities of printer using the libgutenprint library has been almost completed. I am also finishing my code after which I will be working on printer admin web interface. All the documentation will also be updated as time progresses. Sahil's GitHub repository Create new printer setup tool for the GNOME Control Center
Contributor: Shivan Mishra
Mentors: Till Kamppeter, Pranshu Kharkwal, Divyasheel, Deepak Patankar
Hello all, I have been working on modifying Divyasheel's code for adding functionality to list IPP printing services in the main panel along with CUPS queues. I plan to finish it by this week so that I can move over to adding IPP Device Configuration System Service in the base hybrid module. Other than this, I have also been working on removing widget for setting of drivers (PPD) in the Printer Details dialog for printers advertised as IPP services over DNS-SD. Feature requests so far: #1877: Improve setting of IPP options #1878: Allow to add new printers via Printer Applications #1879: Do not show setting of drivers for IPP printers #1911: Printers: Make adminurl available for IPP printers CUPS Snap in the Snap Store The cups snapd interface is now fully working as documented! The bugs we told about last month are all fixed and appropriate CUPS Snap and snapd versions are released. Also the CUPS Snap is now auto-connecting the system's cups-control interface. So snappers only need to follow the instructions in the mentioned documentation to use the cups interface in their apps and users of applications plugging the cups interface can just print. Note that there is still no further application using the cups interface except the first two, especially Firefox, Chromium, and LibreOffice did not switch over to it yet. Continuing the restructuring to have libppd depend on libcupsfilters instead of libcupsfilters depend on libppd, as introduced in May. Continuing to restructure the code to separate the siamesian twins of the filter functions and PPD file support: Made the cfFilterRasterToPWG(), cfFilterPWGToRaster(), cfFilterGhostscript(), cfFilterImageToRaster() and cfFilterImageToPDF() filter functions free of PPD file support and created appropriate ppdFilter...() wrapper filter functions in libppd for them. Also had a look into the cfFilter...ToPS() filter functions but they will not get converted but completely moved over to libppd, considering not only PPD files obsolete but also the PostScript format (at least when not used in a PostScript printer driver with PPD). Tested handling of media size, margins, and page geometry and found some issues. Did several improvements on the cfGetPageDimensions() and cfGenerateSizes() functions to solve the problems. Added support for page size variants in PPD files (A4, A4.Borderless, A4.Duplex, ... differences in margins, sometimes even a bit in the size dimensions) Now we are also matching of custom page sizes and pages rotated by 90 degrees. Support for the Duplex (sides) option. Support for using the sizes of the input file's pages when not explicitly requesting a page size, no page scaling (page-scaling=none), and no special layout features like N-up or booklet printing. This allows documents with differently sized pages to be printed. When working on the cfFilterGhostscript() filter function bumped into problems with Ghostscript's cups output device. It allows supplying the backside orientation for duplex, the need of software copies, and the CUPS Raster version only via PPD files, so added appropriate functionality for setting these parameters without PPD file to the Ghostscript device in the Ghostscript upstream repository. Have the cfFilterPDFToPDF() and cfFilterImageToPDF() sharing the JCL/PJL support code for classic native PDF printers. Remaining filter functions to be converted: cfFilterBannerToPDF(), cfFilterTestToPDF(), and cfFilterUniversal(). I still need to check whether to convert also cfFilterTextToText(). So we come close to cups-filters 2.x. From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|74900| |ipp-usb|ipp-usb|2287| |ps-printer-app|PostScript Printer Application|2313| |ghostscript-printer-app|Ghostscript Printer Application|1482| |hplip-printer-app|HPLIP Printer Application|4864| |gutenprint-printer-app|Gutenprint Printer Application|4128| Currently released is 2.4.2. There will be further bug fix releases in the 2.4.x series. Some bug fixes were done during the last month, see changes below. Ubuntu Jammy Jellyfish (22.04 LTS) comes with 2.4.1. Ubuntu Kinetic Kudu (22.10 will most probably come with a later 2.4.x. The CUPS Snap and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master of CUPS. Currently released is 1.28.15. We are continuing to restructure the code to separate the siamesian twins of the filter functions and PPD file support and after that we will finally polish and bug-fix the code for the 2.0.0 release. See above for more details. The re-structuring made me not doing any further bug fixes on cups-filters, so there is also nothing to backport to 1.x. Ubuntu Jammy Jellyfish (22.04 LTS) comes with cups-filters 1.28.15. Ubuntu Kinetic Kudu (22.10 will be the first Ubuntu coming with cups-filters 2.x. 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. Currently released is 1.2.1. In the last month only some minor bug fixes got done, also fixes for libcups3 (CUPS 3.x) compatibility, and addition of translations from Weblate. I have started to work on adding the new PAPPL 1.2.x features (SNMP-based supply level readout, localization/human-readable strings for options/attributes) to pappl-retrofit. See above. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-July-2023",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - July 2023",
+ "url": "/OpenPrinting-News-July-2023",
+ "headings": [
+ "GUADEC 2023 in Riga",
+ "Opportunity Open Source in the IIT Mandi, India",
+ "DebConf 2023 in Kochi, India",
+ "Ubuntu Summit 2023 in Riga",
+ "Google Summer of Code 2023",
+ "The CUPS Snap in Ubuntu 23.10",
+ "Rehearsal for the all-Snap desktop distro",
+ "Snappy scanning: simple-scan Snap is working now!"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/dVVyokoQl2k/hqdefault.jpg",
+ "snippet": "GUADEC 2023 in Riga, Opportunity Open Source in IIT Mandi, India, Ubuntu Summit 2023 in Riga, GSoC 2023, Ubuntu 23.10 with snapped CUPS, versioned Printer Applications.",
+ "content": "My work since the last news post was mainly organizing and preparing for conferences and updating and improving our Snaps, of CUPS, ipp-usb, and the 4 Printer Applications. The work on our Snaps is to prepare them for the default inclusion in Ubuntu 23.10 and in Ubuntu Core. We had to version the Printer Applications, promote them to the stable channel, the cups-control interface got checked for different system types and fixed to work on all of them, ... And we have a lot of conferences again, GUADEC, DebConf, the second Ubuntu Summit, and a new one: The Opportunity Open Source in the IIT Mandi! And this one is my baby! We have many students from the IIT Mandi under our GSoC contributors, and so Aveek Basu and me decided to neet them in-person to motivate even more. But next up is GUADEC. On the GNOME developer conference I will tell about the state of the art of the GNOME UI for printing, teach application developers how to make Snaps to be distributed in the Snap Store, an discuss the printing-related topics in a BoF with GNOME developers. And stay updated on Mastodon: #OpenPrinting. Tomorrow the GUADEC in Riga, Latvia, will start! I am already on the way to there. Update: All session times corrected I have now prepared everything for my 3 sessions, especially the slides (linked below) but also the exercises and examples and a virtual machine image for the Snap workshop. See the schedules. Please also keep an eye on Mastodon for updates: #GUADEC2023, #GUADEC Also note that if you cannot make it to Riga you can register as remote attendee and then watch all the talks live (and also ask questions via keyboard, as far as I remember). On Tuesday I will get to Riga, meet my colleagues and friends, attend some exciting sessions, have an even more exciting hallway track, and will host these sessions: The New Printing GUIs: GNOME Control Center and Common Print Dialog Backends Wed, July 26, 11:00 EEST, room 2 Slides Update: Video Right on the first day I will talk about the state of the art of the printing GUIs for the New Architecture, the \"Printers\" part of the GNOME Control Center and the Common Print Dialog Backends (CPDB) support in the print dialogs and will also demo the GUIs. I will also announce my BoF then. Your app everywhere, just in a Snap! (Workshop) Sat, July 29, 15:15 EEST, room 1 (Update) Slides This GUADEC will get snappy! In this 2-hour interactive workshop you will learn how to snap (= package as a Snap) your favourite applications! You will snap a simple GNOME application on your own laptop and after that we (me and Jesús Soto) will also help you to snap your applications. Update: The workshop got moved to two hours later to not run in parallel with the only other workshop on the GUADEC, \"Discover GNOME development with Workbench\" at 12:00 in room 2. If you want to attend the workshop, please prepare your laptop for the hands-on exercises, by installing the needed software or downloading our virtual machine image. Instructions are in the \"Setup\" section of the slides and here is the Ubuntu 23.04 virtual machine image with everything needed alrady installed. Note that the *.qcow2 image is 5.7GB large, so please download it as soon as possible and especially not during the workshop. GNOME/GTK Printing BoF Sun, July 30, 13:30 EEST, room 3 Slides During my work on the New Architecture for printing and a recent discussion with GNOME developers and designers, I have 2 subjects I want to discuss in-person: UI Design for the GNOME Control Center \"Printers\" module with support for the New Architecture Separation of GTK printing API into its own project Main participants of the discussion are me, Matthias Clasen, and Jakub Steiner. Anyone is invited to participate. Remote participation is possible and I expect that Mohit Verma, GSoC contributor on the \"Printers\" module of G-C-C, and Gourav Guleria, GSoC contributor (2022) and mentor (2023) on CPDB support in print dialogs will connect. Canonical/Ubuntu Booth Wed-Fri I will also be at the booth for some time and will be able to demo recent work on printing, scanning, Snap, and Ubuntu, and also help you preparing your laptop for the Snap workshop. Organizing every year the participation of the Linux Foundation as mentoring organization in the Google Summer of Code (GSoC) and mentoring contributors for OpenPrinting I work together with Aveek Basu who joined OpenPrinting when he worked at Lexmark in India. He is reaching out to colleges and universities in India and this way we have every year around 5-7 students as contributors for OpenPrinting, most of them studying at the Indian Institute of Technology (IIT) in Mandi. With the DebConf being in India, Aveek and me have decided to meet most of our current and former contributors in-person and motivate the students, professors, and researchers to join the community of developers, designers, doc writers, … in a 2-1/2-day conference, the \"Opportunity Open Source\". We will talk with our contributors about their GSoC experience on a panel have a GSoC Q&A session have the contributors presenting their work have talks about OpenPrinting have talks about Zephyr have Rudra Saraswat on the conference giving talks about his projects Ubuntu Unity and blendOS. have a panel and Q&A with Canonical employees telling about jobs at Canonical, how to apply, how the work will be. have a talk (and perhaps also a workshop) about Snap by me. By a Call for Proposals (extended to August 14) we hope to get even more contributions. And for the attendees getting some real-life experience we are running this year’s OpenPrinting Roadmap Sprint (like our micro-conferences on Linux Plumbers: 2019, 2020, 2021, 2022) on the conference and attendees can participate in the discussion and planning of the next 12 months in printing and scanning. We will also live-stream and record everything and allow remote participation. The conference takes place on September 8-10, right before the DebConf. By the way, I have extended the Call for Abstracts to close on August 14. There is a thread on Ubuntu Discourse. And we keep you informed via Mastodon: #OpportunityOpenSource I hope to see you all in Mandi! And thsi year I will be on Debian's annual developer conference, DebConf, for the first time! This year´s edition takes place in Kochi, in the south of India. This is the annual 2-week meeting of the Debian developers to plan their work, 1 week DebCamp on Sep 3-9, informal, hackfest, BoFs, and a second week on Sep 10-17, with talks, panels, workshops, ... I will attend the second week, starting from the 11th or 12th, depending on when and how well I will arrive from Mandi. I have submitted two presentations: The New Architecture for Printing and Scanning on Debian With the DebConf taking place right in the new cycle after the Bookworm release I will tell the Debian developer community about the New Architecture of printing and scanning to help them switch the Debian distribution to the new IPP-only PPD-less realm. The talk will also cover any news from our roadmap sprint in Mandi. Opportunity Open Source conference in the IIT Mandi, India: Motivating people to be a part of us! This talk is about how we have organized the conference, the challenges, and naturally also the outcome and experiences with running it, having come right from there to the DebConf. And we will have a Q&A session about organizing conferences and also being a mentoring organization for the Google Summer of Code. So everyone interested in running a free software conference and/or participating in the Google Summer of Code is welcome to participate in this session. Preparations for another great Ubuntu Summit are going on. The Call for Proposals has ended on July 21 and we got a whopping 178 proposals!! So we are reviewing like hell as we have a lot to select from. I have also submitted some proposals, partially together with colleagues, a talk telling about my experience with the Opportunity Open Source in the IIT Mandi, a workshop about packaging applications as Snaps (\"snapping\") together with Lucy Llewellyn, and another workshop, about Snap update automation on upstream releases with Heather Ellsworth. Notification of acceptance of the sessions is planned to be sent out on July 31, probably we will also have the schedules then. 5 of our 6 contributors have passed midterm and I as mentor and org admin got many positive evaluations from them. The 6th contributor did not fail, but we have postponed his remaining part of the GSoC, including midterm. Some of the contributor's evaluations: Akarshan Kapoor (Scanning support for PAPPL): Both the organization and the mentors have been excellent throughout my participation in GSoC. The well-structured and supportive environment provided by my organization has made the program a highly enriching experience. My mentors have been outstanding, offering consistent support and sharing their expertise, contributing significantly to my learning and growth. My experience with GSoC has been exceptionally positive due to their concerted efforts and dedication. Kushagra Sharma (CPDB support for Chromium, Mozilla, LibreOffice): I wanted to take a moment to express my utmost gratitude and appreciation for the invaluable guidance and mentorship you have provided by mentors at linux foundation Pratyush Ranjan (CI Testing for OpenPrinting): Hi, you guys have been great, and I appreciate working with you all. Write-up from Kushagra: OpenPrinting: CPDB support for application's print dialogs: Firefox, Chromium, LibreOffice
Contributor: Kushagra Sharma
Mentors: Till Kamppeter, Gaurav Guleria, Shivam Mishra, Rithvik Patibandla, Ira McDonald After building chromium from source, I have created a dummy print backend which implements all the virtual functions in /printing/backend/printing_backend.h. After this next task is to add this dummy print backend to build files of ninja. The implementation requested from chromium dev team is that they want to select which print backend in runtime. I am currently working on how to tackle this task as currently if CUPS print backend is available then it is automatically using it and not the dummy print backend. Chromium team has asked me to push the changes on the gerrit so that they can assist. This will be my upcoming task And Google does the Mentor Summits in-person again! So I will be on this year's Mentor Summit, October 13-15 on the Google Campus in Sunnyvale, California! Here I will meet my fellow mentors from a lot of different free software organizations to exchange experience, tell about the Opportunity Open Source in the IIT Mandi, and, with Ubuntu 23.10 being released on October 12, celebrate the release! Now it finally happened! Ubuntu is switched over to use the CUPS Snap as its printing stack. The Debian package of the CUPS daemon and of the classic CUPS drivers are going away. First, do not rush out to grab Ubuntu 23.10 (Mantic Minotaur) and install it for testing it out, it has still too many rough edges in terms of printing. Especially do not install it on your daily driver machine, as usual, you should not use a development branch for your daily work ... I worked together with Sebastien Bacher, leader of the distro squad in the Canonical Desktop Team. He told me what is needed for the installation image inclusion (\"seeding\") of my Snaps and I told him which Snaps have to get seeded and which Debian packages removed, and finally he switched over and current daily ISOs use the CUPS Snap as their printing system. The Snaps being all migrated to core22 (Ubuntu 22.04 LTS) as base distro and all their components updated to the newest upstream versions already last month I now had to give them version numbers nad release all of them on the \"stable\" channel in the Snap Store. CUPS is already versioned, by CUPS' upstream version number plus a package release number, similar to the (classic) packages of Linux distributions. The upstream version number is taken from the metadata of the GIT snapshot of the CUPS upstream code loaded. The correct GIT snapshot is selected via the release tag (source-tag: in snapcraft.yaml). This method is already a preparation for future automation of updating the CUPS Snap triggered by a new upstream release of CUPS via GutHub workflow. The 4 retro-fitting Printer Applications get their version numbers from their principal component, plus a package release number: PostScript Printer Application: foomatic-db, current version 20230715-1 Ghostscript Printer Application: Ghostscript, current version 10.01.2-1 HPLIP Printer Application: HPLIP, current version 3.22.10-1 Gutenprint Printer Application: Gutenprint, current version 5.3.4-1 For all of them I select the version via upstream release tags, so that later automation will get easy. No with all Snaps versioned I have promoted the current versions of them into the \"stable\" channel, and in addition, created ubuntu-23.10 branches for them in the Snap Store, as this is needed for inclusion in Ubuntu 23.10. With this in place we could change the seeding in Ubuntu 23.10: Removed Debian (binary) packages: cups-daemom cups-browsed cups-filters ipp-usb printer-driver-* system-config-printer-* Added Snaps: cups ipp-usb ps-printer-app ghostscript-printer-app hplip-printer-app gutenprint-printer-app Note that the removal of the mentioned binary packages of CUPS does not eliminate the need of the source Debian package \"cups\", as we still need the CUPS library, libcups2, of it. Applications with print functionality installed classically, as Debian package, need this library. Here things get improved with CUPS 3.x, as here the CUPS library comes as separate upstream source. To be able to remove system-config-printer, Sebastien has updated the gnome-control-center package, removing the patch which adds the button to start system-config-printer for advanced configuration. system-config-printer is not actively developed any more and therefore did not get updated to support the New Architecture. Principally, it is planned that the Printer Applications are only downloaded and installed if actually needed, and not included by default. We are temporarily seeding them as the work on the needed functionality in GNOME Control Center is not yet completed. As soon as this is done, they will not get seeded any more. I have also tested the cups-control interface whether it is working correctly with the different system configurations, especially if the classic CUPS installation is replaced by the Snap, both on classic Ubuntu and on Ubuntu Core (all-Snap immutable distro). Here we already got a bug report of cups-control not getting correctly auto-connected on Ubuntu Core, which made me more intensely testing and discussing my observations on this thread. And we really needed a fix here, which James Henstridge fixed by this pull request. Now, if a Snap is installed from the Snap Store which has permission to auto-connect cups-control, gets it auto-connected to the system's :cups-control slot only if a classic CUPS is installed, identified by the presence of an /etc/cups/cupsd.conf file, otherwise it gets connected to the cups:cups-control slot of the CUPS Snap. This way we can have printer setup tools distributed as Snaps and they connect to CUPS as expected by the user. Next steps are: CUPS migration script:
Similar to how it got done for the introduction of the Firefox Snap in Ubuntu we will create a transitional Debian package providing a binary package with the name \"cups-daemon\" and a version number higher than the one of current CUPS. This way the package will replace the current cups-daemon package which actually contains the CUPS daemon on a update. It does not install any files but has a post-install script which installs the CUPS Snap, migrates the classic CUPS' configuration from /etc/cups/ to the Snap (/var/snap/cups/common/etc/cups/), taking into account that we now need Printer Applications instead of classic drivers, so installing the needed Printer Application Snaps and migrating the print queues from CUPS into the Printer Applications. In the end the /etc/cups/ directory gets deleted (or at least renamed), so that cups-control of client Snaps gets auto-connected correctly to the CUPS Snap. Add support for the New Architecture to GNOME Control Center:
We need at least the essential parts from Mohit Verma, GSoC contributor on this part, before Feature Freeze mid-August. This is to make the \"Add Printer\" part working and to let the main view show visible grouping of the listed IPP services if they come from the same Printer Application or the same multi-function device. More detailed changes, like the UI design worked out by Mohit together with Canonical's Elio Qoshi Mohit will implement during his extended GSoC time until end-October. Add Common Print Dialog Backends (CPDB) support to all print dialogs:
All print dialogs will be migrated from direct CUPS use to using the Common Print Dialog Backends. Once we replace \"bad\" CUPS access implementations which do not support temporary CUPS queues which CUPS creates for discovered IPP print services or directly access PPD files in /etc/cups/ppd/, and second, we pass the maintenance responsibility for the print dialogs to suppor the print technologies correctly from the GUI and app maintainers to the maintainers of the print technologies themselves, as they also should provide the backends. For CUPS this is OpenPrinting. But as long as we do not achieve this goal, we will keep cups-browsed in the distro to assure that the old dialogs keep working ... Install the Legacy Printer Application (legacy-printer-app) by default:
With it installed, a classic CUPS driver, like a proprietary driver from a printer manufacturer, will get visible in this Printer Application and so printers can get set up with this driver. For actual seeding I will need to post a Main Inclusion Request (MIR), to get it into the Canonical-supported Main part of the Ubuntu distro. The switchover from classic Debian packages to Snaps for printing in Ubuntu 23.10 serves not only to prepare for Ubuntu 24.04 LTS and even more future Ubuntu versions which will use CUPS 3.x, but it is also a rehearsal for the all-Snap desktop. As already told about on an Ubuntu blog post by Oliver Smith, product manager Desktop at Canonical, we are also working on an all-Snap desktop distro based on Ubuntu Core (there are already first images of it for testing, but please, do not use for your daily driver). This is also an immutable distro, but not as immutable as most others, because of the fact that its application package format, Snap, cannot only distribute desktop applications, but also daemons and system components. One good example of such Snaps is the CUPS Snap with is not just an application but a complete printing stack in one Snap. On most other immutable distribution, the printing stack, probably even the printer drivers, are in the immutable core, making it hard for printer manufacturers to add drvers. So here we have, as usual, an immutable core (based on the current Ubuntu LTS, currently 22.04), but then not only immutable user applications but also immutable system components, like the CUPS Snap providing the printing stack and printer and scanner drivers in separate Printer/Scanner Application Snaps. By the way, even GPU drivers are available as modular components. Note that printing in Ubuntu Core Desktop is only superficially tested, so do not bet on it already working currently ... And as users of also want to be able to scan from snapped applications, especially also if we have an all-Snap distribution, we need to test this, too. As a first Snap of a scanning application, there is the Snap of Simple Scan. It was already there longer ago but probably never got well tested, as it turned out that it actually did not work, not being able to access scanners (Pull request) and that it was not prepared forall types (eSCL and WSD) driverless scanners and Scanner Applications (Issue). I have investigated the problem and fixed it and the fix is now included. Now we have tested it on driverless scanners (scanning part of driverless IPP multi-function printers) and it works. So we are ready for a consistent scanning experience in the Snap and Ubuntu Core Desktop world!"
+ },
+ {
+ "id": "post:OpenPrinting-News-July-2024",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - July 2024",
+ "url": "/OpenPrinting-News-July-2024",
+ "headings": [
+ "GUADEC 2024 in Denver",
+ "Opportunity Open Source in IIT Kanpur",
+ "UbuCon Asia 2024 in India",
+ "Google Summer of Code 2024",
+ "Pull Requests"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/zU035efP2p0/hqdefault.jpg",
+ "snippet": "Caution, non-driverless printer!, Interview by Podcast Ubuntu Portugal, Flatpaking daemons, GUADEC 2024, Opportunity Open Source in IIT Kanpur, UbuCon Asia 2024, GSoC 2024, Pull Requests",
+ "content": "This month I will start with a very important warning: Some months ago I talked here about HP's crazinesses to lock their users into expensive original ink and that following reported user experience I recommended to buy Brother printers instead of HP. I also told that typical modern printers, also cheap ones, are driverless IPP (AirPrint, Mopria, IPP Everywhere, Wi-Fi Direct Print) nowadays. But unfortunately, there are still exceptions: There is the ultra-cheap USB-only Brother DCP-L2600D (for Europe/Africa/Asia markets), which is not driverless and therefore useless under Linux! Thanks to Zdenek Dohnal from Red Hat, who got note of it and reported on our developer mailing list. Michael Sweet mentions this printer's North-American Wi-Fi sibling DCP-L2640DW which is also not driverless and tells we need to do better in telling which printers to buy. Solomon Peachy (Gutenprint) answers that inside printers the print engine and the networking engine are separate parts and the IPP support comes from the networking engine, and so IPP-over-USB is usually only available in network printers and not in USB-only printers. All-in-all one should really check whether a printer supports driverless IPP protocols like AirPrint or Mopria, according to what is written on the box, and what most printers do, fortunately. And to make it even easier we have now a button to get to our driverless printer list right in the banner of our home page. By the way, HP has withdrawn from one of their madnesses. They were selling cheaper versions of several laser printers with an \"e\" added to the end of the model name and users of those printers were required to join HP+ and to keep the printer always connected to the internet. These models are now discontinued and only the somewhat more expensive versions without \"e\" but full liberty continue to be available. But existing \"e\" models continue to require HP+. I am back from GUADEC 2024 in Denver and did not only give a talk about Snap but learned about the efforts towards flatpaking daemons and methods of analysing graphical results in CI testing. And the next conference is already around the corner. The CfP for the second Opportunity Open Source in Kanpur, India, has ended and the schedules of 50 sessions are published. Once in India I will be on two conferences again, also on the UbuCon Asia 2024 in Jaipur on the following weekend. Some weeks ago I got interviewed by Diogo Constantino, one of the hosts of the Podcast Ubuntu Portugal, and now this interview got published as episode #310. I talk about how I got into computers, free software, printing, ... How I started OpenPrinting. And I also talk about Snap ... But note that it is all in Portuguese, Diogo speaking Portuguese of Portugal and I speaking Portuguese of Brazil. And Diogo invited me to the Festa do Software Livre 2024 in Aveiro, Portugal, which is co-hosting the UbuCon Portugal. While I have put a lot of work into the Opportunity Open Source the Google Summer of Code contributors have carried on with their great work. And even better, they did not only work on their code but Biswadeep Purkayastha, contributor for CPDB support in LibreOffice and his mentor Michael Weghorn did a lot of fixes and improvements on the CPDB code. Also Zdenek Dohnal from Red Hat posted some Pull Requests on OpenPrinting code. See it all here. Did you know that humans have even printed in space? The Space Shuttles had a 59-pound-weighing 80-column line printer on board. See also the comments, where it is told that the line printers got later on replaced by stock Epson Stylus Color 900 inkjet printers. So let us see what happened at OpenPrinting in July ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat Photos and Videos I am back from a great GUADEC in Denver, Colorado, in the US! It was a great event. First I met some good friends, especially Heather Ellsworth from Thunderbird and Ken VanDine, Marco Trevisan, Aaron Prisk, and Jeremy Bicha from Canonical, but also many others on the event. I already arrived on Wednesday afternoon to attend a GSoC Meet-up which GSoC lead Stephanie Taylor organized as she was already there anyway for her keynote on Sunday. So I met Stephanie and some GSoC mentors and contributors, one even from the beginning of the GSoC, wearing the t-shirt from 2005, the very first year (I was late on the party, started mentoring from 2008 on). The next day I finally met the GNOMies and who else attended GUADEC on the pre-registration meeting. Friday to Sunday were the 3 days for the talks (All videos). I have given a talk, too: Snap and Ubuntu Core Desktop - Desktop Linux, as easy as a smartphone! Slides, Video Here I explained what Snap is and how it worked and also how the all-Snap immutable operating system, Ubuntu Core, for which Snap was originally created, works. In the end I also showed how adding a desktop session Snap (Wayland + Desktop Environment) turns it into the Ubuntu Core Desktop operating system. As usual, having proposed the talk as a 40-min talk I got only 25 min, but this time I succeeded to finish in around 20 min leaving some time for questions and Ken VanDine, one of Canonical's Ubuntu Core Desktop promoters, helped my nicely to answer them. There were also great keynotes, the subject matters of both affecting me especially: Thunderbird, The Death and Rebirth of an OSS Project Video Ryan Sipes, lead of Thunderbird, tells how he saved Mozilla's e-mail client from the death and made it awesome again. I am long term lover and user of Thunderbird, I use it already for more than the 20 years that it is named Thunderbird, in the beginning as part of Netscape Communicator even. Ryan, thanks to keep it rolling. Google Summer of Code 20 years of OSS Mentorship Video Stephanie Taylor, lead organizer of the Google Summer of Code at Google, tells everything about the Google Summer of Code and what was achieved with it. I did not participate from the very beginning, but I am long-term org admin for the Linux Foundation as mentoring organization in the GSoC, from 2008 on (4th GSoC). And GSoC has done very well for OpenPrinting. Monday and Tuesday were the days of BoFs and workshops. I have attended some of the sessions, especially Workshop: openQA testing for your GNOME app, module or service openQA GitHub Here Sam Thursfield and Outreachy interns Dorothy Kabarozi and Tanjuate Achaleke have shown how automatic testing of GNOME's GUI application works. Especially the graphical content of the application window after doing an operation must be compared against the expected content. And that is something which would be also useful for CI testing at OpenPrinting, comparing the output of print filters against the expected page content. To compare graphical content they use the free software computer vision library OpenCV and also the universal file comparison tool diffoscope is used to check output. Especially OpenCV seems to be also useful to check on an output file (if it is PDF or PostScript we would raster it first) whether it is the \"correct printout\", not doing a pixel-by-pixel comarison, but checking whether the expected text content is there, and whether nothing got cut off at the borders, ... We could offer that as a GSoC project idea in 2025 ... Flatpak & Portals BoF Notes Georges Basile Stavracas Neto has hosted this session about all kinds of Flatpak related issues. The discussion started with how to flatpak system services (daemons), led by Christian Hergert who works on this already for some time. Also Adrian Vovk with whom I already had a short conversation about this subject matter Thursday night, was participating. If all this works out, we at OpenPrinting will also start to flatpak CUPS and the Printer Applications, making it easy for users of most immutable Linux distributions to install printer drivers and also the newest CUPS. That would be another GSoC project idea. Note that this is still in a very experimental stage and it is not yet clear whether Flatpaks of non-GUi system applications and daemons will ever appear. Back on the Canonical Engineering Sprint 2023 in Prague Heather Ellsworth and Aaron Prisk talked about going to a tattoo studio together for each of them getting a little Tux tattooed, on the next Sprint, in November 2023 in Riga, but before that Sprint happened, Heather had left Canonical. Now, on the GUADEC, Heather and Aaron met again, and turned their old plan into reality, but not only them, also Thomas Crider (\"Glorious Eggroll\" or just \"Eggy\"), a good friend of Heather, living in Denver, joined the action, and now all the three are wearing a nice Tux tattoo ... It is only little more than two weeks from now and we have the second Opportunity Open Source in the Indian Institute of Technology (IIT) Kanpur, on August 24-26! As we have opened the CfP for the event hardly any proposal appeared and we were already fearing not getting the one plenary room filled with talks on the two days. So I asked the on-location organizers to ask around, and especially Sanskar Yaduca started to e-mail lots of people (I got CCed) mainly in India as they do not need expensive overseas travel to come. Many declined but in the end we got so many proposals that we had to ask for a third room and now we have two rooms for talks and panels and one for workshops and the time slots are nearly completely booked out! Thanks a lot Sanskar! We have published the schedules now and the conference is stuffed with great content of lots of different areas, a total of 50 sessions: OpenPrinting, including talks (CUPS, PAPPL) by Michael Sweet, author of CUPS Zephyr, several talks and a workshop, by Jonas Remmert, Oliver Völckers, and others I give a talk about Snap and Ubuntu Core (Desktop) and my workshop where you learn snapping applications Hands-on with firmware programming: A ChromeOS firmware team from Google gives 2 talks (Intro, Advanced) and a workshop Rudra Saraswat introduces into his BlendOS system, immutable, arch-based, sandboxes/containerizes classic app packages on-the-spot. Rudra Saraswat will also give 2 workshops, one to make your own Ubuntu flavor with his Iona framework and the other about creating Arch-based immutable distros Jiongchi Yu, GSoC contributor on deploying OSS-Fuzz testing on OpenPrinting and his mentor George-Andrei Iosif show that they are not only an excellent team at OpenPrinting but also in presenting security-related talks, this time 3. More current and former GSoC contributors will speak: Akarshan Kapoor, Rudra Pratap Singh, Shivam Jaiswal, Deepak Patankar, Sahil Arora, ... Large Population Models, AI for simulations of millions of interacting agents (there is not only generative AI) Pierre Clisson will talk about building brain-computer interfaces 20 years of the Google Summer of Code - I am hosting a panel about what it is, how to participate, experiences of mentors and contributors, questions & answers Want to know how it is to work at Canonical? I am hosting a panel with some colleagues from Canonical and we tell our experience. a lot more ... So if you come to Kanpur you will for sure find a lot of interesting sessions, plus a great hallway track. We have especially also 9 workshops during the 3 days, if you want to try out the things by yourself, often even on your laptop. And on Monday we will run a Hackathon, the subject is still to be determined by the organization team in India. We will also live-stream the Plenary Room and the Breakout Room, and record the sessions in the Workshop Room. So if you cannot make it to Kanpur, please follow the menu entry \"Attending Remotely\" on our event page for instructions and links to watch the live streams on YouTube and to ask questions via the live comments there. Note that the links are not yet there. I will post them some days before the conference. Special thanks to Shivam Mishra for suggesting the IIT Kanpur and to Pratham Sahu, Sanskar Yaduca, and Mohammad Rabhar for leading the on-location organization, to the 50 volunteers on-location, and to Aveek Basu. Also thanks to Canonical and there especially the Community Team (Mauro Gaspari, Aaron Prisk) for all the support, providing me Indico, StreamYard, lots of swag, and giving me support and answering my questions concerning conference organization. Also my participation in the organization of the Ubuntu Summits has given me a lot of experience. Please follow us on Mastodon: #OpportunityOpenSource From Kanpur I will continue my trip to Jaipur (with stop-over in Agra, to see the Taj Mahal) for the UbuCon Asia 2024, on Aug 31 - Sep 2 (Sat - Mon), and give a talk and a workshop about Snap. If you attend, please make sure to not miss my two snappy sessions: Desktop Linux, as easy as a smartphone! Just in a Snap! Sat, August 31, 11:35 AM IST, Main Hall The motivation, advantages, and concept of the sandboxed, immutable Snap packaging format is shown and how it is used to make up immutable all-Snap OS distros, the IoT distro Snap was originally designed for, Ubuntu Core, and the easily usable and maintainable Ubuntu Core Desktop. Your app everywhere - Just in a Snap! - Interactive Workshop Sun, September 1, 1:55 PM IST, Room 2 Interactive workshop to learn how to package applications in the sandboxed, immutable package format Snap to publish them in the Snap Store. Attendees will create simple Snaps in several hands-on exercises. With the workshop I got featured speaker on the front page. Full schedules I will also meet Soumyadeep Ghosh from the Snapcrafters and present Snap with him at his booth and also work with him on the plans for the Snapcrafters booth and workshops on the Ubuntu Summit. 10 of our 11 contributors have passed their mid-term evaluations! And the 11th, Arun Patwa (Braille Printer Application) did not fail. He just started coding 6 weeks late, due to his graduation, and therefore did not reach mid-term yet. And we got write-ups of nearly all of them: Packaging CUPS and Printer Apps into OCI images
Contributor: Rudra Pratap Singh I have thoroughly tested cups-rock. Added instructions in the cups-rock GitHub repository for testing the OCI image. Implemented GitHub Actions from ubuntu/desktop-snaps to support version automation in cups-rock. Started containerizing ps-printer-app. Added GitHub Actions to test cups-rock on every push. CPDB support for the LibreOffice print dialog
Contributor: Biswadeep Purkayastha This month I worked on conforming my code to the reviews left by my mentor Michael Weghorn, of LibreOffice. Apart from minor fixes such as dropping DBus headers, changing low level handling of the options hashtable and writing some documentation for the newer API functions of CPDB frontend, it also included bigger tasks such as changing the way the print dialog was interacting with CPDB. Initially my approach was to write custom DBus calls to subscribe to signals and use the API callback function so that changes were made to both the CPDB and LO printer lists simultaneously. However in the end we agreed upon using the API calls for the signals so that changes were first made to the CPDB printer lists and using a custom callback to make changes to the LO printer list later. This would prevent low-level DBus calls in LO ensuring any future changes in the way signals are processed by CPDB does not require any code change for maintenance in LO. Apart from that I also added the support for translations in LO so that the options and their corresponding choices are displayed in a human-readable format. While working on this I discovered that options such as media and media-types did not produce expected logical translations. On raising a bug for it in CUPS, I got to know that CUPS provides only a limited number of localized names for common media sizes and types and as such translations for them may not always be logically correct. Quoting Michael R Sweet's response on the bug, \"We provide a limited number of localized names for common media sizes since some sizes have multiple names not tied to a particular language or region (like “ledger” which is also “tabloid” and “b”) and others are so esoteric as to be meaningless (most photo sizes). Thus, the localized size name will be a dimensional name in many cases using the language/region’s appropriate units and separators.\" So although most translations work, not all will be correct. You can find my WIP PR here. PAPPL API Bridging for Scanner Applications
Contributor: Akarshan Kapoor This month, my major goal was to successfully complete a significant portion of the API handling and finalize the integration schemes for the PAPPL Scan API. Additionally, I discussed with Till Kamppeter and Alexander Pevzner the essential elements that should be included in the scan API documentation. I aim to have the main documentation ready by the first week of August to ensure the project is comprehensible to the larger Linux community. Our next focus will be to complete the API integration by the third week of August and then begin the eSCL server-side integration, which was covered in the last GSoC. As usual, updates to the Work in Progress PR can be found at: https://github.com/michaelrsweet/pappl/pull/349. The documentation for the initial PAPPL project (not updated for scanners) can be found at: https://www.msweet.org/pappl/pappl.html. Akarshan's ongoing work you find in this work-in-progress pull request on PAPPL and in his GIT clone of PAPPL 1.4.x. CPDB support for the print dialog of Mozilla
Contributor: Kushagra Sharma Successfully Built Mozilla Firefox. Adding a demo print backend with dummy function calls, these calls will later be replaced by CPDB APIs. Also working on adding package config file for CPDB that will check if CPDB is present or not , if present then it will use CPDB for performing print jobs. Kushagra created a good collaboration with the Mozilla developers now, via my original feature request. Desktop Integration: Update system-config-printer for the New Architecture of printing
Contributor: Shivam Jaiswal Firstly, as I mentioned before, I looked into the GNOME Control Center telegram group for UI ideas related to the system-config-printer. Additionally, after discussing with Mohit Bhaiya, we decided to change the IPP discovery code to make it discover services asynchronously (currently, it does this synchronously). So, I have been working on these code changes. I was quite busy with internship stuffs. Now, my goal is to finalize the IPP discovery code and the UI as discussed. Make a native printer Application from Gutenprint
Contributor: Ankit Pal Singh Successfully created driver callback for the native guten printer applications. Tested the functionality like listing of supported drivers, options specific to printer Currently working on start_job, end_job, print_job functions using libgutenprint. User interfaces for using OAuth2 with printers and scanners
Contributor: Shivam Sharma I have written a code for token exchange which will help clients to authenticate their identity. For this I am using GOA and GOA API has several inbuilt functions which I am using to add various features. I completed the setup of the GOA DBus connection. I am using Google as the account type because GOA supports Google accounts only. Currently I am working on designing the UI for this OAuth process. After successfully completing the token exchange code I will merge it to CPDB and then I will modify the UI and the functionality of the token exchange code. I can also add the authentication server which the printer will provide to the client for verification. Converting Braille embosser support into a Printer Application
Contributor: Arun Patwa I have implemented a foundational structure for a Braille printer application using the PAPPL framework. This includes defining the printer drivers, setting up callbacks for device auto-adding, MIME type handling, and driver configuration. I have also implemented a test page printing callback and a print filter function specifically designed to handle the conversion of input files to Braille-ready formats. Additionally, I have created data structures and global configurations necessary for managing printer settings and job processing within the application. In this month I will add the functionality of text to brf conversion. Replace QPDF by PDFio as PDF manipulation library in libcupsfilters
Contributor: Uddhav Phatak I have ported the code from C++ to C for the files 'nup.cxx' and 'intervalset.cxx', which I have updated into my GitHub repo. I have also ported 'pdftopdf-processor.cxx' and 'qpdf-pdftopdf-processor.cxx' into C. I am currently testing all the outputs of the functions. Here is Uddhav's work on GitHub. Adding Common Print Dialog Backends (CPDB) support to the Qt print dialog (GSoC 2022) Contributor: Gaurav Guleria Gaurav is now finishing the merge requests, actively working out the remaining rough edges with the Qt developers (#556476, #437301, #471258, #116726). I had an in-person meeting with Axel Spoerl (Qt developer, works at Qt in Oslo, Norway, and does the, otherwise abandoned, print dialog as pet project) in Vienna to discuss the merge of the CPDB support merge request in upstream Qt. His summary (reported to Volker Hilsheimer from Qt): We have changed the commit message slightly and verified, that the merge conflict disappears. What remains to be done: bump the provisioning verison to CPDBlibs 2.0b6 move the code references from gerrit comments to source code comments What remains to be decided, Volker's input needed: There is a compiletime CPDB switch, which will always remain. We will default it to ON from Qt 6.9 onward, meaining that we build with CPDB support by default. That will enable users to build Qt with CUPS only, CPDB only, both or none. In addition to that, we need a runtime switch to cover the following case: host system doesn't have CPDB support => fall back to CUPS use CUPS as default in 6.9, opt in for CPDB use CPDB as default from 6.10 onward, opt in for CUPS This still needs to be developed. Decisions to be made: implement runtime switch on QGuiApplication level? (we proporse: yes) confirm the versions: 6.9 still defaults to CUPS, implement CPDB default from 6.10 onward. @Volker: Are you fine with that? Should we ask the mailing list as well? It currently also seems to build only locally and not on Qt’s servers. Volker likes the roadmap but wants to have it completely implemented before making CPDB the default (instead of direct CUPS), ideally in the next LTS+1 release of Qt. Important remark: CPDB will be required for using Qt with CUPS 3.x. I agreed with Axel, to not update the direct CUPS support of Qt to CUPS 3.x. From CUPS 3.x CPDB will have to be used. While I was putting a lot of work into the Opportunity Open Source, GUADEC and into mentoring the GSoC contributors, the development of our code base has continued. Special thanks go to Biswadeep Purkayastha (CPDB support for LibreOffice) and his mentor Michael Weghorn (LibreOffice upstream developer) as they did many changes and improvements, mainly on the CPDB libraries (cpdb-libs) and also on the CUPS backend for cpdb-libs (cpdb-backend-cups). Also Gaurav Guleria (CPDB support for GTK and Qt peint dialogs, CPDB 2.x development) did a change. Many changes are bug fixes but there are also several library-internal functions promoted to the public API of cpdb-libs. Since the 2.0b6 releases they did 18 Pull Requests on cpdb-libs and 4 on cpdb-backend-cups: cpdb-libs PR #35: API functions to refresh printer list and to get D-Bus connection, by Biswadeep Purkayastha PR #36: Turn some static functions into frontend API functions, by Biswadeep Purkayastha PR #37: Turn cpdbFillBasicOptions() into a frontend API function, by Biswadeep Purkayastha PR #38: text-frontend: Quit on EOF (Ctrl+D), by Michael Weghorn PR #39: text-frontend: Don't crash when printer doesn't exist, by Michael Weghorn PR #40: Pass backend name to cpdbRefreshPrinterList() as const char*, by Michael Weghorn PR #41: Removed unused parameter instance_name, by Biswadeep Purkayastha PR #42: Replace cpdbGetStringCopy() with g_strdup(), by Michael Weghorn PR #43: Documentation for newly added API functions, by Biswadeep Purkayastha PR #44: Correct DBus calls to add, delete and state change of printers, by Biswadeep Purkayastha PR #45: Fix bad free, by Biswadeep Purkayastha PR #46: frontend: Drop unused own_id member, by Michael Weghorn PR #47: Fix a memory leak in cpdbGetSysConfDir(), by Michael Weghorn PR #48: cpdbConcatPath(): Actually check XDG_CONFIG_DIRS, by Michael Weghorn PR #49: Add capability to check CPDB version at runtime, by Gaurav Guleria PR #50: text-frontend: Add null check for get-default-printer, by Michael Weghorn PR #51: text-frontend: Get locale via GLib, by Michael Weghorn PR #52: text-frontend: Drop unused local vars, by Michael Weghorn cpdb-backend-cups PR #32: Use g_strdup instead of cpdbGetStringCopy(), by Michael Weghorn PR #33: Always query current CUPS default printer, by Michael Weghorn PR #34: Add support for CUPS printer instances, by Michael Weghorn PR #35: Use NULL Instead of \"NA\" if there's no default printer, by Michael Weghorn Zdenek Dohnal, printing maintainer at Red Hat, did several fixes on libppd and cups-browsed: libppd PR #30: ppd-cache.c: Use PPD size name from CUPS if size is standardized PR #46: ppd-cache.c: Use 0.5mm for delta when comparing sizes cups-browsed PR #32: cups-browsed.c: Ignore attributes with empty values PR #33: cups-browsed.c: Ignore IPP attributes with \"no-value\""
+ },
+ {
+ "id": "post:OpenPrinting-News-June-2020",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - June 2020",
+ "url": "/OpenPrinting-News-June-2020",
+ "headings": [
+ "Google Summer of Code 2020",
+ "Google Season of Docs 2020",
+ "CUPS Snap (Printing Stack Snap)",
+ "CUPS",
+ "cups-filters",
+ "IPP-over-USB: ippusbxd and ipp-usb"
+ ],
+ "tags": [],
+ "snippet": "Renaming of CUPS Snap, cups-filters 1.27.5, GSoC 2020 coding period has started",
+ "content": "On June 1st the coding period of this year's Google Summer of Code has started! All the 7 students (announced here last month) have prepared themselves and even partially started with the coding (and first code pieces being comitted to the project's repositories) and now they will all work on their projects. Some of the students are currently getting printers from us to test their work. Now in the end of each of the three months there will be evaluations which the students have to pass to get the money for the month done and stay in the program to continue their project. The coding will end in the end of August and the students will post their work products. We got already some e-mails from potential candidates and they are in contact with the mentors of the appropriate sub-organizations of the Linux Foundation. The application period starts on Tuesday, June 9 and will terminate on Thursday, July 9 and here are the project ideas for OpenPrinting. The Snap will soon get renamed, from Printing Stack Snap to simply \"cups\" and the GitHub repository will then also be renamed, to \"cups-snap\" (Link will work after the renaming). The CUPS Snap on OpenPrinting will be the official Snap, as we cannot expect that CUPS' upstream, Apple, will make a Snap of CUPS and also CUPS on any non-Apple system is used with cups-filters, which is an OpenPrinting project and it is based on the parts of CUPS which Apple has spun out due to the fact that they are not needed by Mac OS X and so Apple did not want to maintain them. Therefore it should be no problem to name our CUPS Snap simply \"cups\". The GitHub repository will be named \"cups-snap\" so that the visitor of our GitHub will not think that this is a fork of CUPS but rather the set of files needed to build the CUPS Snap. I have also continued work on the Snap: Updated upstream packages: cups-filters 1.27.5 When checking for an already running CUPS using lpstat, check also for lpstat errors Put groups listed as \"SystemGroups\" in cups-files.conf in correct order, so that \"root\" is not the first group Removed patches to lift CUPS' internal security features of not allowing to run filters/backends as root, the filters/backends user group being an admin group, and to run the helper program cups-deviced as root CUPS is run as root without CAP_DAC_OVERRIDE capability, so CUPS has to obey ownerships and permissions of files/directories, corrected directory/file permissions appropriately Set fontconfig environment variables to files/dirs inside the Snap Clean up temporary directories by the run-cupsd script, using a special algorithm to work without CAP_DAC_OVERRIDE capability Let CUPS create the root certificate with group ownership root and without ACLs Installed fonts-arphic-uming package to print CJK plain text files Added the Berkeley-style printing utilities lpr, lpq, lprm, and lpc Cleaned up the Snap from unneeded files: C headers, documentation, DejaVu fonts, System V startup scripts, static libraries, ... Currently I am testing the Snap and fixing bugs. Also a migration script to switch over from classically installed CUPS to the CUPS Snap is still needed. Currently released is 2.3.3. No further releases or GIT commits. Currently released is 1.27.5. 1.27.5: Several fixes/improvements on cups-browsed, to correctly determine the CUPS server to attach to, to correctly create queues pointing to a second local CUPS instance, and to not remove the locally created queues on shutdown. Also included several bug fixes from contributors We have a new contributor for ippusbxd who wants to solve its problems in C: Fletcher Woodruff is working on Issue #15, of ippusbxd returning invalid data to TCP clients when communications got interrupted. The problem was solved by ipp-usb making use of Go's HTTP library. Fletcher is now trying to find a suitable library in C. Fletcher has also already made a small contribution, raising the internal buffer size to speed up data transfer between the printer and the host."
+ },
+ {
+ "id": "post:OpenPrinting-News-June-2021",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - June 2021",
+ "url": "/OpenPrinting-News-June-2021",
+ "headings": [
+ "Want more news?",
+ "Google Summer of Code 2021",
+ "CUPS Snap",
+ "PostScript Printer Application",
+ "Retro-fitting of CUPS printer drivers into Printer Applications",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "GSoC, PostScript Printer Application and PIN-based printing, Retro-fitting CUPS printer drivers, cups-filters 1.28.9",
+ "content": "Are you always eagerly waiting until I issue my next news post here after a month? Due to the fact that I am working at Canonical (the company behind Ubuntu) I also post weekly updates about my work (which is mainly OpenPrinting but also printing integration in Ubuntu) in the Discourse forum of Ubuntu. The coding period has started a week ago and now, after some of the students having finished their exams, they are all working on their projects. They have now 9 weeks until mid-August for their coding work. CUPS Snap in the Snap Store, Call for testing on the snapcraft.io forum and on the Ubuntu Discourse, more than 1800 installations via Snap Store I am still waiting for the snapd team to implement the security concept on the snapd side, but unfortunately, they are very busy currently. Main TODOs are: Complete the security concept on the snapd side, especially implement the content interfaces Testing Turn classic CUPS drivers into Printer Applications Add a migration script so that OS distributions can easily switch over from classic packages to the CUPS Snap. PostScript Printer Application in the Snap Store, Call for testing on the snapcraft.io forum and on the Ubuntu Discourse, more than 1000 installations via Snap Store Features and fixes in the past month (follow the links to the commits for more detailed descriptions and motivations): Support for CUPS filters used in PostScript PPD files. The manufacturers of PostScript printers got aware of the shortcomings of the PPD file concept and work around them using CUPS filters for more complex conversion of option settings into PostScript or PJL code. The PostScript Printer Application supports such filters now and if the appropriate filter is actually installed, all PPD options for the printer get available. This is the first application of the new filterExternalCUPS() filter function in cups-filters. Support for printing private jobs (with PIN protection) on HP printers in the Snap of the PostScript Printer Application. Here we make use of the CUPS filter support for the first time, adding the hpps filter of the HPLIP package. The options to control PIN-protected printing are under the \"Printing Defaults\" in the web interface. Support for the CUPS extension of PPDs for custom option settings, as strings, password, numeric values, fax/phone numbers, ... This is especially needed by the PostScript printer PPD files from Ricoh and OEMs as here the PINs are entered as string-type options. Note that this change is not yet in the GIT repository of the PostScript Printer Application, as it still needs PAPPL's string option support to get fixed. Patches with the changes on both PAPPL and the PostScript Printer Application for implementing this feature are included in the issue report. Note that these changes only apply to a few PostScript Printers and only to enable features which are not used very often, but they are especially done with general retro-fitting of CUPS printer drivers in mind, where CUPS filters defined in the PPD file and string/text/numeric/fax number options are commonplace. With appropriate features added to PAPPL we will be able to also add the following: Support for string/text-style vendor options. Needs support in PAPPL. Human-readable strings for vendor options. Needs support in PAPPL. Ink level check via ps_status() function. Needs support in PAPPL. Once having these features implemented, the PostScript Printer Application is complete so far. Currently I am working towards retro-fitting classic CUPS printer drivers into Printer Applications. Here I have especially done the following: Automatic selection of extended Color spaces Completed first version of implementing automatic selection of the extended print quality features 16-bit-per-color (high color depth/dynamic range) and AdobeRGB (wide color gammut) via print-quality=high setting and document color space on driverless IPP printers. Created library functions in libcupsfilters for it and applied them to the ghostscript() filter function. Modified the PPD file generator for CUPS queues appropriately. Discussion in this thread on the OpenPrinting mailing list and this thread on the Ghostscript developer mailing list. Details of my commit in the threads on OpenPrinting and Ghostscript mailing lists). We came to the conclusion that the PDF print job output of user applications lacks information about the actually used color space/profile (sRGB, AdobeRGB, custom). I was unable to correctly print a JPEG photo shot with the camera set to AdobeRGB on an AdobeRGB-supporting printer with CUPS from photo management/editor applications. Please subscribe to the OpenPrinting mailing list and/or to the Ghostscript mailing list to participate in the discussions. Made foomatic-rip streaming PostScript, feed Raster to it as PostScript I investigated how raster data can get streamed into foomatic-rip for the Foomatic/Ghostscript Printer Application and also for using foomatic-rip with Ricoh's PostScript PPD files in the PostScript Printer Application to enable secure (PIN-protected) printing. Started a thread about this on the Ghostscript mailing list. Please subscribe to the Ghostscript mailing list to participate in the discussions. As PostScript is a streamable format but PDF is generally not, I decided to make Raster input data to be converted into a PostScript stream, especially with this already being implemented in the PostScript Printer Application. So the Ghostscript used by the legacy driver gets the Raster input streamed in as PostScript and prints each page as it completes, allowing streaming and infinite jobs as required by the driverless IPP printing standards. If the input was PDF Ghostscript reads until the end of the job/document before starting to print the first page. For this I also did a fix on the zero-page job handling in foomatic-rip to make it able to stream PostScript input again. filterExternalCUPS() filter function to call classic CUPS filters The ideal way to convert a classic CUPS driver into a Printer Application is to take the copde of the driver and re-arrange it into a native Printer Applications, to get rid of calling external executables and using PPD files altogether. Problem is that this requires access to the source code, understanding of the source code andf reliable ways for testing, ideally having all supported printer models at hand. Unfortunately, many of the drivers we want to convert are old, unmaintained code, authors do not have these printers any more, not remembering any more for waht exactly all these parts of their code were good for, and there are even proprietary drivers for which we do not even have the source code. And do not think that OpenPrinting has every printer which ever came to the market, so that we can test. Therefore our strategy of converting such printer drivers is wrapping their unchanged code into Printer Applications, what we call retro-fitting printer drivers. To call the original CUPS printers without turning them into filter functions I have created the new filterExternalCUPS() filter function in libcupsfilters which calls a CUPS filter, specified in the filter-function-specific parameters. The filter function also allows to supply options and environment variables only applied to this filter, not to the whole filter chain. The new filter function is already in use in the PostScript Printer Application to support PostScript PPD files which specify CUPS filters, as the ones from HP which use a filter for secure, PIN-based printing. Filter and custom option support in PostScript Printer Application As already described above we got more techniques important for retro-fitting classic CUPS drivers into the PostScript Printer Application, which will be the base for a driver retro-fitting library. This is especially the support for CUPS filters and the support for custom (string/text/numeric/...) option settings. Currently released is 2.3.3op2. Development of CUPS 2.4 is in progress, currently mainly fixing of bugs which were reported to Apple's CUPS GitHub in the last 17 months. Ubuntu Hirsute Hippo (21.04) comes with CUPS 2.3.3op2, the CUPS Snap and the PostScript Printer Application Snap use the current GIT master. Currently released is 1.28.8. Feature additions are principally done forretro-fitting classic CUPS drivers, see details in the separate section: Automatic selection of extended Color spaces Made foomatic-rip streaming PostScript, feed Raster to it as PostScript Added filterExternalCUPS() filter function to call classic CUPS filters Also some bug fixes were done, especially letting the driverless utility not error-exit if no supported printer got discovered. Update: 1.28.9 Bug fix release, fixes backported from the master (2.x) branch (see below) Ubuntu Hirsute Hippo (21.04) comes with cups-filters 1.28.8, also the CUPS Snap currently uses this version. The PostScript Printer Application Snap uses the current GIT master of cups-filters. Currently released is 1.0.3. See also the currently open and closed issues of PAPPL."
+ },
+ {
+ "id": "post:OpenPrinting-News-June-2022",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - June 2022",
+ "url": "/OpenPrinting-News-June-2022",
+ "headings": [
+ "OpenPrinting Summit/PWG Meeting",
+ "GUADEC 2022",
+ "Google Summer of Code 2022",
+ "GNOME Control Center - The new \"Printers\" module",
+ "Scan support for PAPPL",
+ "Common Print Dialog Backends (CPDB)",
+ "CUPS Snap and snapd printing interface",
+ "Approaching cups-filters 2.0",
+ "New feature in PAPPL 1.2.x and implementation in pappl-retrofit",
+ "CUPS-driver-retro-fitting Printer Applications",
+ "ipp-usb: Solution for non-driverless IPP-over-USB-reporting printers",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/CBPefa0Ckq8/hqdefault.jpg",
+ "snippet": "OP Summit Summary, GUADEC, GSoC 2022 projects started, first apps use \"cups\" Snap interface, PPD-independent cups-filters 2.x, PAPPL 1.2.1, CUPS 2.4.2",
+ "content": "On May 17-19 we had our annual meeting together with the PWG (Printer Working Group) again, the OpenPrinting Summit/PWG Meeting. We presented and discussed our work of the last 12 months and what we plan to do next. Especially CUPS 3.x, use of OAuth with CUPS, cups-filters 2.x, and the GSoC 2022 projects for the New Architecture were the main subjects of the meeting. A summary got posted by Jeremy Leber from Lexmark and minutes of the OpenPrinting sessions posted by Ira McDonald. Thanks a lot for this. The conference also initiated some interesting discussion with Alexander Pevzner (author of ipp-usb) and Smith Kennedy (firmware developer at HP) about too many quirks in printer’s IPP-over-USB implementations (see below). As already mentioned here last month I will be on the GUADEC (GNOME developer conference) this year which will take place on July 20-25 in Guadalajara in Mexico. I will not only give my talk about the New Architecture of printing and scanning for GNOME developers (July 21, 14:20 - 15:00 local time, Bosch Auditorium), but also come with my colleagues from Canonical, similar as on the LAS 2022 (video). As of now the Canonical Gang will be me, Heather Ellsworth, Britt Yazel, Marco Trevisan, and Nathan Pratta Teodosio. Heather will give a lightning talk about the Linux Application Summit 2023 showing how to submit a proposal if one wants to host the event. I hope this will help to have another great LAS as we had this year. It will take place most probably on July 22, somewhere between 14:25 and 15:05 local time in the Bosch Auditorium. We will also have a Canonical booth. But do not think about at the GUADEC booths being these sales/marketing people in neatly tucked-in company polo shirts, no, on GUADEC booths you will encounter developers there, of the different companies and projects participating. The booths are just tables to sit around them and chat. This makes it much easier to find people for fruitful hallway sessions. Google has officially announced the contributor projects for 2022. We got 18 contributor slots for the Linux Foundation, all 8 projects for OpenPrinting are accepted! Converting Braille embosser support into a printer application
Contributor: Chandresh Soni
Mentors: Till Kamppeter, Samuel Thibault
Scanning Support in PAPPL
Contributor: Deepak Khatri
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
Adding Common Print Dialog Backends (CPDB) support to existing Print Dialogs
Contributor: Gaurav Guleria
Mentors: Till Kamppeter
GNOME Control Center GUI for discovering non-driverless printers and finding suitable Printer Applications for them
Contributor: Mohit Verma
Mentors: Till Kamppeter, Michael Sweet, Pranshu Kharkwal, Divyasheel, Deepak Patankar
Scanning Support in PAPPL with eSCL Support
Contributor: Rishabh Maheshwari
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
Add Avahi calls for discovering and resolving driverless IPP printers and Optimize the processes
Contributor: Sachin Thakan
Mentors: Till Kamppeter, Michael Sweet, Deepak Patankar
Make a native Printer Application from Gutenprint
Contributor: Sahil Kumar Dhiman
Mentors: Till Kamppeter, Michael Sweet, Solomon Peachy, Robert Krawitz
Create new printer setup tool for the GNOME Control Center
Contributor: Shivan Mishra
Mentors: Till Kamppeter, Pranshu Kharkwal, Divyasheel, Deepak Patankar
With all the contributors I had already introductory meetings/chats, partially also by video calls. I have also created groups on Telegram, Signal, and Discord (according to participant's preferences) of the contributors and mentors for their daily chat about their work, questions, planning, design, ... I am also trying to include upstream developers into the team's whenever possible. The 2 contributors on the \"Printers\" module in the GNOME Control Center and the 2 on scanning support for PAPPL are even together in contrinutor/mentor teams. During the introductory communication we already have planned the work, explained to the contributors how things are working, and especially made the principal design decisions for each project. The official coding period starts today and it seems also that the end-semester exams at the Indian colleges have ended, so the contributors will be active coding from now on. I had intense e-mail discussion with the upstream maintainer of the G-C-C \"Printers\" module, Marek Kasik from Red Hat, and also with Michael Sweet. I got a first answer from Marek Kasik about the original idea of replacing the module by one for the New Architecture. He suggests a different solution, instead of replacing the module adding the functionality needed for the New Architecture to the current module making it supporting both old and new. CUPS 2.x already supports most features of the New Architecture (printers as IPP service, Printer Applications) and with CUPS 3.x old-style items (like PPD/driver-based queues) simply will not show. I agreed with that. I asked Michael Sweet several questions about how to handle managing printers via pure IPP and he helped a lot. Then finally Marek posted 3 feature requests describing the needed work on the upstream GitLab: #1877: Improve setting of IPP options #1878: Allow to add new printers via Printer Applications #1879: Do not show setting of drivers for IPP printers I presented them to the 2 GSoC contributors and they agreed. Thanks a lot to Marek and Michael for their kind help and great communication! With this the GNOME Control Center module and CUPS can get independently updated (as long as the module comes first) and also new elements, like for example Printer Applications or IPP-over-USB printers, can enter at any time and get fully supported. This means, that the main view (to be worked on by Shivan Mishra) of the \"Printers\" module will show both classic, permanent CUPS queues, created locally with PPD file/driver and backend, and IPP services, for which CUPS would auto-create a temporary queue. On classic queues we will get the same operations as we already have: Set option defaults, change driver, ... On IPP services we get operations like entering the web admin interface of the service-providing device, IPP System Service configuration, local option settings, ... Also if an IPP service has more than one print destination (like for example a Printer Application), we will list these destinations together. The \"Add Printer\" part (to be worked on by Mohit Verma) will also support both the current way and the New Architecture. As long as the underlying CUPS supports it, both classic queues with drivers or Printer Applications can get installed for a discovered printer. As long as classic drivers are still available (CUPS 2.x, not the CUPS Snap) it will be possible to choose. Internet search for OS-distribution-independent packages of Printer Applications will get included as originally planned. Initial tests of installing Printer Application Snaps on the OpenPrinting web server were already performed. Thanks Violet Kurtz from OSUOSL! There will be no \"Printers & Scanners\" module, due to the very different nature of print, scan, and fax operations for the user we will continue with a \"Printers\" module. Faxes would be shown on a seperate panel, but the code of the \"Printers\" module could be shared here. Two GSoC contributors (Rishabh Maheshwari and Deepak Khatri) will continue where Bhavna Kosta has left off in GSoC 2021: They will add scanning support to PAPPL. This will allow complete suppport for multi-function devices (they get really common nowadays, practically the standard form for paper-processing peripherals) and also with Scanner Applications generally a way to provide scanner drivers in OS-distribution-independent packages. Originally, Rishabh's main part was to make PAPPL accepting and processing eSCL scan jobs and Deepak's main part to do the same for IPP Scan jobs, but it turned out that IPP Scan got a still birth. It is a nicely worked out standard, also IPP as our printing standard, but no one in the hardware industry adopted it, eSCL won as driverless scanning de-facto industry standard, its specs got also published by Mopria, it works also under IPP-over-USB (not being IPP though), so we go eSCL-only in PAPPL. This means that we are currently re-organizing and re-defining the projects of our two contributors, to get a great eSCL-based driverless scanning support in PAPPL. I have started a kick-off mail thread with the two contributors, their assigned mentors, Michael Sweet (PAPPL), Alexander Pevzner (sane-airscan), Bhavna Kosta (GSoC 2021 student who started this work) and got a lot of help from Mike and Alex, thanks a lot to them. Our GSoC contributor for adding CPDB support to the current print dialogs, Gaurav Guleria, has already started very early, already before submitting his proposal, especially he has already done some fixes the CPDB libraries. He especially worked on support for human-readable strings for options and choices in the CPDB libraries (commit) and removed CUPS-specific functions from the frontend library (commit). He also has already started on the CPDB support for thr GTK print dialog. In a recent chat I worked out with him how to handle if the PPD of the CUPS queue contains variants of the same page size, like A4, A4.Borderless, and A4.Transverse. we decided on sending each actual page size (here A4, 297x210 mm) only once to the frontend (in the \"Page Size\" option) and send additional enumerated choice or boolean options to select borderless or transverse (long-edge-first) printing. CUPS Snap in the Snap Store The cups snapd interface now having been officially launched and documented gets started to be actually used. The first application using this interface got uploaded to the Snap Store on May 17, onlyoffice-desktopeditors and after that, on June 13 FreeCAD. Congratulations to the developers of these applications and thanks to Daniel Manrique from the Snap Store Team at Canonical for this valuable information. But the code now getting actually exercised, we also found first bugs: On a first test with the Chromium Snap by my colleague Nathan Pratta Teodosio from Canonical some bugs got found which are all already fixed as of now. While starting to make use of the new cups printing interface in the web browsers, replacing cups-control by cups there, as recommended now, it turned out that the CUPS Snap in proxy mode did not clone the print queues, at least if there are no network IPP printers around (observed by Nathan Pratta Teodosio and also Olivier Tilloy, both from Canonical's Ubuntu Desktop Team, thanks a lot for reporting and especially Nathan's patience in investigating it). This was caused by bugs in the CUPS Snap itself, cups-proxyd not doing an update right after starting (fixed) and the CUPS Snap needs to plug cups-control to use D-Bus services of host system's CUPS (fixed)), and a bug in snapd, an erroneous restriction peer=(name=org.freedesktop.DBus,label=...) for CUPS D-Bus access (Pull request #11843 on snapd). The fix on snapd got already merged and should be in snapd 2.56 (Snap Store) and the fixes on the CUPS Snap are included in version 2.4.2-2 also already in the Snap Store, so everything should work now. Only missing piece is approval from the Snap Store team to auto-connect the cups-control interface. The request is posted here. For now, should you not connect cups-control manually (sudo snap connect cups:cups-control) and/or not have snapd 2.56 or newer, at least when starting the CUPS Snap the cloned queues are updated, as well as on appearing or disapperaing of a network printer. So if a new print queue does not get cloned (not appear in print dialogs of snapped applications), either power-cycle an arbitrary printer in your local network or restart the CUPS Snap (sudo snap stop cups; sudo snap start cups). Thanks, James Henstridge (Canonical Desktop Team) for the pull request on snapd, and Michael Vogt (snapd Team Manager at Caninical), Alberto Mardegan, and Alex Murray for quickly approving this pull request. To assure that the CUPS Snap works correctly with the current cups-filters 2.x, we are now building the included Ghostscript 9.56.1 with all output devices needed for the 4 page description languages needed for driverless IPP printing (PDF, PWG Raster, AppleRaster, PCLm) (commit, issue fixed). The CUPS Snap is also updated to CUPS 2.4.2 now. Continuing the restructuring to have libppd depend on libcupsfilters instead of libcupsfilters depend on libppd, as introduced last month. Continuing to restructure the code to separate the siamesian twins of the filter functions and PPD file support. After having made the cfFilterPDFToPDF() filter function free of PPD file support I have done the same now also for the cfFilterPDFToRaster() filter function, the Poppler-based PDF rasterizer. The ppdFilterPDFToRaster() wrapper filter function now adds PPD file support to that. To reach this I have especially removed the PPD support from the color management support functions (cfCm...() and cfColord...()), moved the reading from PPD keywords for CUPS/Apple/PWG Raster/PCLm attributes, backside orientation, even number of pages for duplex, and rendering intent into the PPD loader/parser functions for the wrapper filter functions in libppd, added fields to the filter data structure for input and output formats and also for a sample Raster header which can be derived from the PPD (from pseudo-PostScript code in Raster driver PPDs). Also some crash bugs in code which did not get exercised enough in our PPDish world got fixed. Most of the PPD attribute readouts are transferred to libppd now. Especially also some code duplication in filter functions got eliminated. Now it is mainly to go through the remaining filter functions and apply the new PPD handling functionality also to them. Michael Sweet released version 1.2.0 (and bug fix follow-up 1.2.1) with support for SNMP-based supply level readout, localization, and human-readable strings for vendor options. Features which were still missing for the development of pappl-retrofit. Supply level readout The supply-level readout I made already use of in a first implementation in pappl-retrofit (plus crash fix, extra crash guards, no premature backend shutdown, following the implementation in hp-printer-app after talking about how to do the supply-level readout with Michael Sweet on the OpenPrinting mailing list. For now it only works for network-connected printers and when using PAPPL's own print backends. Later on we will also add support for supply-level readout for embedded CUPS filters. I also started work on finding out how to read out supply levels with embedded CUPS backend calls and found out that also CUPS backends need access to the PPD file. So I made sure the PPD is also available when a printer uses a CUPS backend (commit). I found the way how to complete it but had no time to implement it due to the more urgent work on the cups-filters 2.x release. Localization and human-readable strings I had also some chat with Michael Sweet on the OpenPrinting mailing list, about localization and human-readable strings for the vendor options and how to implement it in pappl-retrofit, as here the set of strings is variable on run-time due to the PPD files. They are once too many for pre-building the strings file and second, in the PostScript Printer Application the user can add their own PPD files. The 4 retro-fitting Printer Applications are now also built with PAPPL 1.2.1 and so getting all the new features and bug fixes, but due to the fact that they use CUPS backends and not PAPPL's own backends to communicate with the printers they currently do not support supply level readout. This will be added later, but most probably only after the release of cups-filters 2.x. Also the support for human-readable strings for the vendor options will come. For those who are printing JPEG images shot with digital cameras directly to a Printer Application (using the setting print-scaling=none) and expect the photo coming out in its \"original size\" according to the image file's metadata will have much better chances now, as the image resolution information in the image's EXIF data (metadata saved in the image file by the camera, more commonly used to find out about ISO, shutter speed, aperture, ...) is made use of now. See cups-filters Issue #362 and Pull request #466 which implements the EXIF support. Thanks to Brian Potkin from Debian for reporting and to Sachin Thakan (GSoC contributor on Avahi support, see above) for the implementation. As a follow-up of the discussion about printers with a 7/1/4 USB interface but not doing driverless IPP via IPP-over-USB on this interface (see last month), Alexander Pevzner has found a solution for ipp-usb not blocking classic access to these printers. He simply lets the ipp-usb daemon disconnect as soon as the access to the device during the preparation of the daemon fails. See Issue #52. Thanks, Alex, for this. From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|41888| |ipp-usb|ipp-usb|2186| |ps-printer-app|PostScript Printer Application|2390| |ghostscript-printer-app|Ghostscript Printer Application|1413| |hplip-printer-app|HPLIP Printer Application|4725| |gutenprint-printer-app|Gutenprint Printer Application|3974| Note: The sky-rocketing of the number for the CUPS Snap from ~4200 last month to ~42000 this month is due to the fact that Application Snaps in the Snap Store which use the new cups snapd interface auto-install the CUPS Snap as it is needed for the interface's security concept. The new interface got launched April 25 and the first application using it uploaded on May 16 (see above). Currently released is 2.4.2. There will be further bug fix releases in the 2.4.x series. Some bug fixes were done, see changes below. Ubuntu Jammy Jellyfish (22.04 LTS) comes with 2.4.1. Ubuntu Kinetic Kudu (22.10 will most probably come with a later 2.4.x. The CUPS Snap and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master of CUPS. Currently released is 1.28.15. We are continuing to restructure the code to separate the siamesian twins of the filter functions and PPD file support and after that we will finally polish and bug-fix the code for the 2.0.0 release. See above for more details. The re-structuring made me not doing any further bug fixes on cups-filters, so there is also nothing to backport to 1.x. Ubuntu Jammy Jellyfish (22.04 LTS) comes with cups-filters 1.28.15. Ubuntu Kinetic Kudu (22.10 will be the first Ubuntu coming with cups-filters 2.x. 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. Currently released is 1.2.1. I have started to work on adding the new PAPPL 1.2.x features (SNMP-based supply level readout, localization/human-readable strings for options/attributes) to pappl-retrofit. See above. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-June-2023",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - June 2023",
+ "url": "/OpenPrinting-News-June-2023",
+ "headings": [
+ "GUADEC 2023 in Riga",
+ "Ubuntu Summit 2023 in Riga",
+ "Google Summer of Code 2023",
+ "CUPS 2.4.6",
+ "Approaching final release of cups-filters 2.0.0",
+ "Snap updates",
+ "Test the CUPS Snap!",
+ "Classic Ubuntu",
+ "Ubuntu Core (immutable)"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/t0_qvADqLsY/hqdefault.jpg",
+ "snippet": "GUADEC 2023 in Riga, Ubuntu Summit 2023 in Riga, GSoC 2023, CUPS 2.4.6, cups-filters 2.0rc2, Snap updates, Test the CUPS Snap!",
+ "content": "Perhaps one or another of you remembers that in last month's news I have announced that I want to switch Ubuntu 23.10 (Mantic Minotaur) from the CUPS packages in Debian format to the CUPS Snap as its printing environment and correspondingly to Printer Applications instead of classic CUPS printer drivers. And this announcement had a high impact, opened a downright can of worms ... First, as usual, I announced my news post on Mastodon and a few days later OMG! Ubuntu picked up on this. As usual, if something is written or told about Snap somewhere it tends to provoke a heated debate, the naysayer's voices usually the loudest, nearly masking the few telling about the advantages of Snap ... Near 200 comments! After all this lively Snap discussion, a few days and subsequent blog posts later, Oliver Smith, product manager desktop at Canonical, issued a great post on Canonical's Ubuntu Blog about immutable Linux distros, a great explanation of how immutable Linux distributions work, the different already existing approaches Chrome OS, Fedora Silverblue/OSTree, and MicroOS/Btrfs, and Canonical's Ubuntu Core/Snap with the possibility to use also this one for a desktop operating system. And from then on, immutable distros and distro-independent, immutable packaging was what everyone talks about: Jorge Castro, Brodie Robertson on immutable distros, on packaging, ... By the way, YouTuber Brodie Robertson did a nice interview with former Canonical employee (and free software veteran as me) Alan Pope. Alan especially tells about how Snap started. But careful! It is 2 hours, like a full-sized movie ... So Snaps get more and more important, and therefore I am also on it here at OpenPrinting. I have already switched all our 6 Snaps to core22 as base Snap. So please help us and test the CUPS Snap! We especially need to fix as many bugs as possible but also do some tuning with the interfaces, partially also on snapd. Also, if our Snaps should get included in Linux distributions, independent of whether immutable or classic, we need a proper versioning and release management for all our Snaps. Heather Ellsworth, responsible for Snap packaging of several desktop applications for Ubuntu in Canonical's Desktop Team, has created scripting for automatic release of a new Snap build into the --candidate channel of the Snap Store always when the upstream repo gets a new tag (usually a release). All files needed for that are available in a GitHub repository and Heather explains on Canonical's Ubuntu blog site how to use them. We have also progress in many other OpenPrinting projects thanks to our Google Summer of Code contributors, they tell us what they have done since our previous news post. And Canonical's security team liked my GitHub security bug tutorial from last month. It made it into their Ubuntu Security podcast! But note, the first, near 20 min of the podcast is a, for many people rather boring, list of all security fixes which got done in that week. The part about our tutorial starts at 19:33 min into the podcast. Only 4 weeks until GUADEC in Riga, Latvia! Now also the contributions from the second Call for Proposals for extra workshops and BoFs have been selected and my proposal of a GNOME/GTK Printing BoF has been accepted! It seems that they got an extra room in the venue for the workshops and BoFs on Saturday and Sunday. So there are 3 extra 2-hour sessions on Saturday and 2 extra 2-hour sessions on Sunday. See the updated, final schedules. Please also keep an eye on Mastodon for updates: #GUADEC2023, #GUADEC So I will be speaker/host of the following sessions: The New Printing GUIs: GNOME Control Center and Common Print Dialog Backends Wed, July 26, 10:00 EEST, room 2 Right on the first day I will talk about the state of the art of the printing GUIs for the New Architecture, the \"Printers\" part of the GNOME Control Center and the Common Print Dialog Backends (CPDB) support in the print dialogs and will also demo the GUIs. I will also announce my BoF then. Your app everywhere, just in a Snap! (Workshop) Update: Sat, July 29, 14:15 EEST, room 1 This GUADEC will get snappy! In this 2-hour interactive workshop you will learn how to snap (= package as a Snap) your favourite applications! You will snap a simple GNOME application on your own laptop and after that we (me and Jesús Soto) will also help you to snap your applications. Update: The workshop got moved to two hours later to not run in parallel with the only other workshop on the GUADEC, \"Discover GNOME development with Workbench\" at 12:00 in room 2. And if you want to attend, please prepare your laptop for the hands-on exercises, by installing the needed software or downloading our virtual machine image. Instructions are in the \"Setup\" section of the slides and here is the Ubuntu 23.04 virtual machine image with everything needed already installed. Note that the *.qcow2 image is 5.7GB large, so please download it as soon as possible and especially not during the workshop. GNOME/GTK Printing BoF Sun, July 30, 12:30 EEST, room 3 During my work on the New Architecture for printing and a recent discussion with GNOME developers and designers, I have 2 subjects I want to discuss in-person: UI Design for the GNOME Control Center \"Printers\" module with support for the New Architecture Separation of GTK printing API into its own project Main participants of the discussion are me, Matthias Clasen, and Jakub Steiner. Anyone is invited to participate. Remote participation is possible and I expect that Mohit Verma, GSoC contributor on the \"Printers\" module of G-C-C, and Gourav Guleria, GSoC contributor (2022) and mentor (2023) on CPDB support in print dialogs will connect. Canonical/Ubuntu Booth Wed-Fri I will also be at the booth for some time and will be able to demo recent work on printing and scanning, and also help you preparing your laptop for the Snap workshop. Preparations for another great Ubuntu Summit are running. Weekly organization team video meetings have started again and the Call for Proposals is open. We got more than 70 submissions already! And we are still waiting for your amazing contribution to the conference. We have extended the Call for Proposals, so take your time to create something awesome. The deadline is now on July 21, 20:59 UTC (23:59 in Riga). Our 6 contributors (plus 1 volunteer) are continuing on their projects and doing awesome work! All of them have posted a little summary in our OpenPrinting team channel on Telegram: OpenPrinting: CPDB support for application's print dialogs: Firefox, Chromium, LibreOffice
Contributor: Kushagra Sharma
Mentors: Till Kamppeter, Gaurav Guleria, Shivam Mishra, Rithvik Patibandla, Ira McDonald Started progressing for adding cpdb support for chromium. Connected with chromium team for assistance in building chromium from source. Faced several challenges as chromium has a very large repository with a lot of dependencies. At last build is successful and print dialog is also working fine thanks to chromium dev team and my mentors. Next step is to use cpdb api for print backend and edit build config file so that ninja can build cpdb api. I am excited to be able to work with chromium dev team. Sand-Boxed Scanner Application Framework
Contributor: Akarshan Kapoor
Mentors: Till Kamppeter, Rishabh Maheshwari, Deepak Patankar, Ira McDonald After successfully implementing the regex parser, it was time to delve deeper into the architecture framework of client and server connections. The process began with the implementation of a file named \"escl-ops.c,\" which was the first file that required a separate header file implementation. My mentor, Till Kamppeter, guided me in introducing a file-header system into the existing PAPPL architecture. Little did I know that this was just the beginning of a long implementation journey. The client-server architecture of PAPPL is primarily designed for printers, so I had to consider the requirements of scanners when processing these requests. I was able to develop a basic architecture for handling these requests and then proceeded to create a baseline for implementing scan job creation. These scan jobs needed to align with the MOPRIA scan documents and required a separate implementation that took into account various scan properties. Currently, I am working on resolving the baseline implementation for these scan jobs. Once the baseline implementation of the scan job architecture is complete, we will be able to generate scan job tickets. This will pave the way, after the midterm, for scanner advertising and SANE implementation in PAPPL-retrofit. GNOME Control Center: List and handle IPP print services for the New Architecture
Contributor: Mohit Verma
Mentors: Till Kamppeter, Marek Kašík, Zdenek Dohnal, Rithvik Patibandla, Ira McDonald I am currently working on making the discovery of devices in G-C-C asynchronous. Along with it, I am also working on sorting the device entries. I am currently trying to understand how to make these features possible by understanding the existing methodology of asynchronous discovery of devices. I am trying to get this done as soon as possible. Continuous Integration: Test Programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, CPDB Libs
Contributor: Pratyush Ranjan
Mentors: Till Kamppeter, Deepak Patankar, Zdenek Dohnal, Ira McDonald Test Suite for Libcupsfilters: Implemented tests for filter functions in libcupsfilter. The test program accepts the input in the form of printer properties, formats and options. Each test case also specifies the input and output MIME type of the file. The tester function then emulates an IPP printer with same properties and attempts to test it by calling cfFilterUniversal(). Tester than summarises all the tests based on the return value of the function call. The test cases are determined by the bug reports on various openprinting projects. Adding support for the new functionality of IPP Everywhere 2.x to libcupsfilters and CPDB
Contributor: Gayatri Kapse
Mentors: Till Kamppeter, Rishabh Maheshwari, Zdenek Dohnal, Ira McDonald During the analysis of the codebase, I identified a specific structure responsible for declaring the character set of a text file. In order to fulfill the requirements of printing a PDF document, I made an enhancement to this structure by introducing an enumeration that allows for the specification of various character sets beyond the existing utf8 variable. Additionally, further exploration revealed the presence of numerous attributes that necessitate inclusion. The focus is currently directed towards understanding the definition and utilization of these attributes, aiming to ensure their appropriate implementation within the project. Native Gutenprint Printer Application
Contributor: Yuvraj Aseri
Mentors: Till Kamppeter, Solomon Peachy, Rishabh Maheshwari, Chandresh Soni, Ira McDonald After completing the printer application's basic structure and looking at the codebase of pappl-retrofit, I developed a plan for integrating libgutenprint into the application. I am composing some wrapper functions that will call and list all printers supported by gutenprint. I will test and compile the code as soon as this function is complete. If everything goes according to plan, I will add all other functionalities in a similar fashion. I will periodically compile and debug the code to avoid encountering problems in the future. Preset management web interface for PAPPL-based Printer Applications
Volunteer contributor: Ankit Pal Singh I have successfully developed APIs that allow for the addition and updating of presets in the state file. Additionally, I have created a web interface that enables the creation, editing, and modification of presets. Currently, I am in the process of identifying the appropriate location to implement the necessary code that will ensure the client listeners receive the presets in the 'job-presets-supported' attribute. Looong, looong ago ... we had the release of CUPS 2.4.2, around one year ago now! But finally, we have a new release. One? No, even 4 in quick sequence, as probably during the enthusiasm of releasing again, some glitches got overlooked and in addition, another security bug got reported. So we are at CUPS 2.4.6 now, providing us with tons of bug fixes and among them also two security fixes, and both handled with GitHubs security vulnerability report functionality. Highlights of release 2.4.3 were my pull request for polling the media-col-database IPP attribute separately if needed when doing a get-printer-attributes IPP request to get the printer's capabilities, and the fix for security vulnerability CVE-2023-32324, a possible heap buffer overflow in _cups_strlcpy(). In addition, there is a year of bug fixes, especially identification of fax queues in the get-printer-attributes IPP response (Issue #459), not dropping media types from the PPD due to not having unique IPP names (Issue #688), and color printers not defaulting to color output (Issues #451 and #500). 2.4.4 and 2.4.5 fix regressions discovered soon after the 2.4.3 release, the former a chrasher bug introduced when fixing a bug of not being able to see a remote printer as default (Issue #719 and the latter certificates downloaded from printers not being correctly saved and reloaded, making all jobs after the first job being denied (Pull request #727, discovered during tests of the CUPS Snap by my colleagues). And shortly after 2.4.5 the fix for security vulnerability CVE-2023-34241, a use-after-free in the cupsdAcceptClient() function, got published, leading us to the third hotfix release, 2.4.6. And this one also fixes printing multiple files to IPP printers, which did not work on some printers Issue #643. Thanks, Zdenek Dohnal, for your excellent work as release manager for the CUPS 2.4.x series! I hope we will be able to return to more healthy bug fix release intervals now. Good News! All the bugs I mentioned here last month are fixed now and appropriate Stable Release Updates (SRUs) are released to Ubuntu 23.04 Lunar Lobster. Also a fix resulting from testing the fully updated CUPS Snap are included, and the fix for our first security vulnerability report. But I did not yet do the final release and did a second release candidate first, as I have synced the libppd code with the PPD file support code of current CUPS. The PPD support code of CUPS got spun out for starting libppd three years ago and after that there happened many changes not being synced during all this time, and therefore there should be a little more time for testing. Here are some highlights of the work on our second release candidate: cups-browsed 100% CPU! The Unsupported Resolution Attack!! All-Snap Ubuntu Desktop libppd sync-up with CUPS First Vulnerability Report If nothing severe happens, I will release cups-filters 2.0.0 final in a few weeks, so that perhaps we can celebrate it on the GUADEC ... Ubuntu 23.10 with the CUPS Snap as its printing system approaching, everyone talking about immutable distros, not having given much love to our Snaps in the last months concentrating on landing cups-filters 2.0.0 ... Now we really need to look after our 6 Snaps again ... First, I have updated the upstream versions of all the Snap's components: CUPS 2.4.6 (in Printer Applications from GIT Master) cups-filters (libcupsfilters, libppd, cups-filters, cups-browsed) 2.0rc2 (from GIT Master) PAPPL 1.3.2 + Avahi registration fix (from GIT Master) pappl-retrofit 1.0b1 (from GIT Master) Ghostscript 10.01.1 QPDF 11.4.0 HPLIP 3.22.10 foomatic-db 20230701 (from GIT Master) I have also fixed several build failures, switched to the cmake plugin for QPDF, and added source-depth: 1 for all parts taken from GIT repositories (loads faster, needed for automation scripting, thanks Heather Ellsworth!). But most importantly, I have migrated the Snaps from core20 to core22, to get to the newest core Snap and so reduce the number of different core Snaps to install in a distribution, independent whether it is a classic one with some Snaps or an all-Snap immutable one. For this I simply needed to follow the instructions of the documentation for general core Snap migration and for migration to core22. Now you should read on in the next section to try it all out! Update: I have investigated the behavior of the cups-control interface in different situations. Needs fixing in snapd for auto-connection if the CUPS Snap is used. See this thread on snapcraft.io. Nice shiny, newly updated Snaps! To get also nice, shiny, both classic and immutable distros with them, they need to get tested, so that in the end everything just works ... Please follow the instructions below and if something goes wrong, please tell us. Best is to report an issue for the CUPS Snap. You can also use the discussion facility or alternatively discuss in the snapcraft.io forums. Some discussion with a Ubuntu Core (immutable distro) user we have already in this snapcraft.io thread. So let us first look at classic distros, most importantly Ubuntu Desktop, as we plan to switch to the CUPS Snap as the print environment of Ubuntu 23.10 Mantic Minotaur. You do not need to upgrade to the development branch for Mantic now and most probably run into other bugs and oddities. I recommend that you do the testing under Ubuntu 23.04 Lunar Lobster, especially if you want to test printing and printer management with desktop applications, you will need my New Architecture PPA which is currently only available for Lunar. Having your Lunar machine ready, does not matter whether on real iron or on a virtual machine, you first need to switch from the Debian packages of CUPS to the CUPS Snap. We go the minimum-invasive way and avoid uninstalling packages, but instead we disable the daemons of the Debian packages via systemd. This way you can more easily return to you habitual configuration (by disabling the daemons of the Snaps and re-enabling the classically installed ones). So first disable the printing-related daemons which are available as Snaps: Now check whether the Snaps \"cups\" and \"ipp-usb\" are already installed: Those which are not installed, install via If you have the CUPS Snap already installed, assure you have the very newest one by switching it to the --edge channel: The CUPS Snap is running in the so-called \"proxy\" mode now, operating as firewall for the classically installed CUPS. This is triggered by the presence of an /etc/cups/cupsd.conf file, not by a running CUPS, to avoid race conditions during boot. But do not delete your /etc/cups/cupsd.conf to make the CUPS Snap running in its \"standalone\" mode. Instead, force the Snap to not go into \"proxy\" mode via Now restart the CUPS Snap to switch the mode: Check whether it has actually switched. Run and see whether the printer URIs (last word in each line) DO NOT start with proxy:. If there is no output (but also no error) it is also OK. If you already have a driverless IPP printer (supporting at least one of the following: AirPrint, Mopria, IPP Everywhere, Wi-Fi Direct Print), lpstat -v should contain at least one line, with an URI starting with implicitclass:. It does not matter whether your printer is connected via Ethernet cable, Wi-Fi, or USB. If your printer is not driverless, which is usually the case only for printers which are several years old, you need a driver. But note that the ones already installed on your system (dpkg -l | grep printer-driver-) are not supported by the CUPS Snap. The new format for printer drivers are Printer Applications. Depending on the type of your printer install the needed one: PostScript printers HP printers (at least most of them) Epson or Canon inkjets, dye-sublimation printers of any manufacturer Label printers None of the above works, especially if your printer is VERY old, also PDF and PCL printers from RICOH and OEM Activating classically installed drivers
Only if none of the above-mentioned Printer Applications makes your printer working, especially if you have a proprietary printer driver installed, install the Legacy Printer Application which makes the classic CUPS drivers available to the CUPS Snap: Note that this package is in Universe, so you need to have the Universe package repository activated. Now open the web interface of the Printer Application, via http://localhost:8000/, if you were in doubt which is the right Printer Application or you have more than one non-driverless printer, you have perhaps installed more than one Printer Applicatio now. Open the web interface of the other ones via http://localhost:8001/ and so forth. On the upper left you see in which Printer Application you currently are. Add your printer via the \"Add Printer\" button at the upper right, the next screen will take some time to show completely, because it is searched for supported printers. Your printer should get discovered and shown under the discovered devices. Select it. You can usually keep the choice of the printer model on automatic. Once done and back on the main page you can get to a printer settings/jobs page for each printer you have set up, or directly use the buttons in the printer entries on the main page. Under \"Device Settings\" you can configure installable accessories (usually only on PostScript printers). On some printers you can poll this information right from the printer via the appropriate button. It is important to configure this correctly, so that you can choose and configure any added tray on the \"Media\" page and use other accessories, like finishers, via the settings on the \"Printing Defaults\" page. Set loaded paper sizes and types via \"Media\" and desired default settings via \"Printing Defaults\", A4/Letter should already be set automatically. Print a test page. DO NOT try to create print queues directly with CUPS the \"classic\" way (lpadmin, system-config-printer, http://localhost:631/, ...). This will not work! Now lpstat -v should show a line for your printer. The third word of each line, after the device for and before the colon (:) is the print queue name. This name you use to select a printer when using a command line tool of CUPS. Run replacing QUEUE by the desired print queue name. The output shows you the user-settable options, to select paper sizes, trays, finishers, print quality, ... The first word (up to the slash (/), but without the slash) of each entry is the option name and the words after the colon are the possible choice names. Print a file via FILE is the name of a PDF file or an image file. Print with custom option settings via You can supply any number of options. Run to see which jobs are currently in the queue. Now you have done basic tests of the CUPS Snap, you can try all of CUPS' command line utilities. If you want to try the utilities which are provided by the Snap, call them via cups. followed by the command name, like cups.lpstat -v. Use these command line utilities also if the \"normal\" ones fail in some way. Next step is the desktop. Follow my first call for testing, for the desktop libraries and applications which are already updated for the New Architecture, from my PPA. Simply go to my call for testing for the GUI changes in the May News and follow the instructions there, but do it on your system where you are using the CUPS Snap instead of the standard Debian/Ubuntu CUPS packages. Another test case is Ubuntu Core, an immutable distribution for IoT and servers. This one is Snap-only. Any change or application installation can only be done by means of Snaps. As the immutable core does not contain CUPS or any other parts of the printing stack, you have to install the CUPS Snap, and the Snaps of ipp-usb and also of any needed Printer Application, as shown above for classic Ubuntu, but you do not need to stop or disable any already existing daemons for it. You also do not need to create a no-proxy file to stop the CUPS Snap from going into \"proxy\" mode. But what you also have to do is to install the \"avahi\" Snap in addition. The CUPS Snap needs the Avahi daemon to be able to discover IPP printers. With that done you can test the command line tools as shown above for classic Ubuntu (call them with cups., like cups.lpstat -v), but not any desktop experience, mainly due to not having a desktop, but also you cannot install the Debian packages from my New Architecture PPA into the immutable, Snap-only distro. Also due to the fact that Core is Snap-only you will not be able to install classic CUPS drivers and import them with the Legacy Printer Application. By the way, Ubuntu Core, with only the \"avahi\" Snap and one or more Printer Application Snaps installed (no CUPS) could also be used as a print server/adapter to turn old printers (everything which works under Linux) into a modern IPP printer which can be used from any operating system, especially also smartphones and Windows and Mac systems for which appropriate printer drivers are not available any more. On some hardware (Raspberry Pi?) the adapter can even be connected to a computer via its USB power port (Micro-USB or USB-C) and the computer sees an IPP-over-USB printer (PAPPL's gadget mode). Also tests of such setups are highly appreciated."
+ },
+ {
+ "id": "post:OpenPrinting-News-June-2024",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - June 2024",
+ "url": "/OpenPrinting-News-June-2024",
+ "headings": [
+ "Most hated gets loved under Linux",
+ "Raspberry Pi saves old printers",
+ "Opportunity Open Source in IIT Kanpur",
+ "UbuCon Asia 2024 in India",
+ "Open Source Summit in Vienna",
+ "Ubuntu Summit 2024 in The Hague",
+ "Google Summer of Code 2024",
+ "KDE Print Manager",
+ "Quo vadis, Gutenprint?",
+ "CPDB 2.0b6",
+ "CUPS 2.4.10"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/OmzCvb-QBak/hqdefault.jpg",
+ "snippet": "Opportunity Open Source in IIT Kanpur, UbuCon Asia 2024, Open Source Summit Europe, Ubuntu Summit 2024, GSoC 2024, KDE Print Manager, Gutenprint, CPDB 2.0b6, CUPS 2.4.10",
+ "content": "This month we have again a lot of great News! First, as usual, we have a lot of conference news. We now know the location and date for the third Ubuntu Summit and the second Opportunity Open Source. And I am featured speaker on the UbuCon Asia and will also give a talk on the Open Source Summit Europe. Also we got 8 reports from our 11 GSoC contributors. They are all doing great work! But 11 contributors? There is more work, and so we have also a volunteer now, working on CUPS 3.x support in the KDE Print Manager. The most sophisticated non-manufacturer free software printer driver project is Gutenprint. But what is on with this project now? Have a look into my interview with Solomon Peachy, current maintainer of it and contributor of the dye-sublimation printer support. I have tested one of the most hated cheapo HP printers and it is working perfectly under Linux, when one sets it up correctly. There are many people making use of Linux to conserve old printers under Windows, when there are no Windows drivers any more, and have caused a longer thread on Hackaday. And it is always nice to get praised by users for the OpenPrinting work, this time by Aaron Prisk from Canonical's Community Team. He writes on Mastodon: I love that I can just plug in my printer and scanner and they just work. No extra bloatware, no funky drivers, they just pick up and go. We're super lucky to have wizards like @till in the open source world. and also got a nice thread of answers. To complete our intro, on Matrix I told to a person that I am leading OpenPrinting, and they told something about their skills and in the end: \"Though I am hesitant to approach devices that often seem to personify God's punishment upon prideful IT workers. 😅\" So let us see what happened at OpenPrinting in June ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat Remember when I wrote earlier here about HP's madnesses related to there razor-and-blades business model and how they try to enforce it? I got hold on one of these cheapo inkjets from HP now, the HP Envy 6000. I did not buy it, I would never do, I got it as a gift from a person who is moving to overseas. It is one of the Wi-Fi-only species with a sticker put over its USB port, saying Wi-Fi-only. They want the user to install their software to set it up for the user's Wi-Fi SSID and password (it has also no front panel menus and no WPS support). And this software is pitching the ink subscriptions and trying to update the firmware so that the printer rejects 3rd-party cartridges. I tested the printer and found out that you do not need all this, just a USB printer cable. Remove the stupid Wi-Fi sticker and see the shiny USB port. Connect the printer to your computer and in a browser, go to http://localhost:60000/ (if this does not work, install ipp-usb). You will see the printer's web admin interface, and on the \"Network\" tab you can do your Wi-Fi setup. Once done, you can remove the USB cable and use the printer from all devices in your network. Note that when you use the printer just USB-only it will print only 20 pages. If you set up Wi-Fi you can continue printing, both via network and via USB. And you do not need any driver for printing and scanning, it is just a driverless IPP printer, as most modern printers. Well known for us Linux users is that a big problem on Windows is that hardware support for a certain device gets discontinued after a few years, so many printers go to the trash because there is no driver in the new Windows version and the manufacturer has also discontinued support for it. But under Linux, in free software, hardware drivers are conserved for many years, ideally eternally, so if a printer gets once supported under Linux, by a free software printer driver, it stays supported. So a Linux print server, for example on a Raspberry Pi is a solution for Windows users to conserve an old printer, at least if it works with a free software driver under Linux. This idea was presented on Hackaday: A Canon PIXMA MP250 (released 2009) got the death sentence for Windows 11 by Microsoft or Canon but can be used under Linux with the Gutenprint driver. So a Raspberry Pi was used to run CUPS with Gutenprint and the printer shared to the network, appearing as modern, driverless IPP printer under Windows ... The original author wrote a HOWTO. But we have already shown here that this also works without any additional print server hardware, at least for Windows 10 and newer, just running Linux under WSL. And also, with or without extra hardware, one does not even need CUPS but can simply use Printer Applications instead, as shown in our HOWTO, and also on the Ubuntu Summit 2022, which got well accepted. There is a long list of comments on Hackaday and I have commented, too, telling about the WSL-based solution and also that a Pi cannot only mimick a driverless network printer but also a driverless USB (USB-over-IPP), thanks to PAPPL. So OpenPrinting is sustainable! I have posted the link to our HOWTO for saving old printers with the help of WSL also at another place. Zygmunt Krynicki has asked in a Mastodon Thread who is using WSL and for what. He got several answers, including one by me ... Now we have confirmed it! The second Opportunity Open Source will be held in the Indian Institute of Technology Kanpur, on August 24-26, the weekend before UbuCon Asia in Jaipur! We already had some contributors from there, like Shivam Mishra, Mohit Mohan, Pratyush Ranjan, Vikrant Malik, Tanmay Anand, ... We also got a lot of support. Shivam Mishra, former GSoC contributor for us, made the suggestion to do it in Kanpur and already told us that IIT Kanpur is larger than Mandi and has more ease to travel to from other cities, like Delhi, as alredy told here earlier. And as we started working it out, Pratham Sahu has taken the lead in the on-location organization and built up a nice volunteer team. He even interviewed several candidates to fill volunteer roles. In contrary to Mandi, the local organizers are also looking for (local) sponsors, to support us financially for things like speaker accommodation and meals, banners, backdrops, conference-specific swag, ... We also do not need to worry about A/V, as this will all get managed for us by the local organizers. Our responisbility will be to fill the Saturday and the Sunday (August 24 and 25) with talks, demos, and workshops, which we are currently working on. Once we are talking to potential speakers, and second, we have put up a Call for Proposals. So if you want to come and contribute, please submit your proposal until July 22. As on Monday, August 26, there are no classes in the IIT Kanpur, we include this day in our event, as a Hackathon day. So attendees can participate in several Hackathons. Also Hackathon ideas are accepted via our call for proposals. Canonical's Community Team has, as last year made available their Indico for us, so that we have an event site for handling proposals and schedules, some practical info, and later on also registrations. The event is annouced on both Mastodon and the Ubuntu Discourse. Any further spreading is more than welcome. I plan to give talks about OpenPrinting, Snap/Ubuntu Core Desktop and workshops about Snap. We will also host panels about GSoC and about working at Canonical. We also invited Michael Sweet who will give a talk (online) about the state of the art of CUPS and PAPPL and we will run a Q&A session afterwards. Jiongchi Yu, GSoC contributor for OSS Fuzz testing of OpenPrinting components, also wants to give a talk. He also will give it online as he lives in Singapore. I will also try to get further GSoC contributors giving a talk. As I already told last month I will be in Jaipur the weekend after the Opportunity Open Source, Aug 31 - Sep 2 (Sat - Mon), and give a talk and a workshop about Snap. On the front page of the event there are 6 featured speakers, the keynote speakers Bhavanishankar Ravindra, Khairul Aizat Kamarudzzaman, and Varshi Gupta, and also Rudra Saraswat (Ubuntu Unity, blendOS, Iona), Buo-Ren Lin (Snap, L10n), and ... ... me! The featured session is my workshop, \"Your app everywhere - Just in a Snap!\", the one where the audience will learn snapping. As I already mentioned here in February this year's Open Source Summit Europe will take place in Vienna (on Sep 16-18). And I will not just attend because it is around the corner for me, I will also give a talk: OpenPrinting - We Make Printing Just Work! Wed, September 18, 15:10 - 15:50 CEST, Room 1.61 & 1.62 (Level 1) Track: LinuxCon I will give an overview of our work. Going through OpenPrinting's history the components of the printing infrastructure of modern Linux (and other Posix-style) operating systems will get shown. - How did the Internet Printing Protocol (IPP) with the printing system CUPS being an implementation of it simplify printing a lot? - The printer driver challenge, good and bad cooperation with manufacturers, packaging and distributing ... - Desktop integration, GUI toolkits, print dialogs, setup tools, portals, ... Especially also the New Architecture of all-IPP printing and scanning and also the integration in immutable OS distributions will be treated ... There will also be a Canonical/Ubuntu booth with several people from Canonical, especially also Mauro Gaspari, organization lead of the Ubuntu Summits, from Canonical's Community Team. After 2 amazing Ubuntu Summit events in 2022 and 2023, there is only one solution: Celebrate a third one. And this we are doing this year in the Hague in the Netherlands, on October 25-27. Our Call for Proposals is open, until July 15! And this time we do not only ask for awesome talks and workshops, but ... ... also for your free software organization's booths, for our new exhibition which will make up the center of the event. I am in the organization team again, as in the first 2 years, and having run community booths already in the early 2000s I will be able to help with booth-related questions. After more than one month into the coding period of the GSoC we have seen a lot of enthusiasm by our 11 contributors. As last month many of them have provided a write-up again to tell what they have done. And one of them, Rudra Pratap Singh (OCI-containerization of CUPS and Printer Applications) got interviewed in a video by Harkirat Singh, telling about his experience. Packaging CUPS and Printer Apps into OCI images
Contributor: Rudra Pratap Singh This month, I've made significant progress on containerizing a working CUPS instance using Rockcraft: Implemented a GitHub Action to automate building the Rockcraft project, compiling it into a Docker image, and pushing the image to a Docker registry. Checkout at DockerHub Raised and merged a PR to extend update-automation for rockcraft.yaml in the ubuntu/desktop-snaps repository, now part of the cups-rock project: GitHub PR 635 Started dbus-daemon within the container for printer discovery, avoiding interaction with the Docker host. Verified printer discovery using the ippeveprinter tool from cups-ipp-utils. Successfully printed files from the Docker host to CUPS running inside the container. Raised another PR for extending version-automation to rockcraft.yaml in the ubuntu/desktop-snaps repository: GitHub PR 636 CPDB support for the LibreOffice print dialog
Contributor: Biswadeep Purkayastha This month I worked on rewriting all the necessary older code to include CPDB frontend API functions and fix the printing process so that now printing with CPDB works on the LibreOffice print dialog. While working on that I discovered that the names of printers on the LibreOffice dialog are static, evaluated on LibreOffice startup and not refreshed while the dialog is open unlike CPDB where periodic refreshing of the printer lists take place. This meant that the print dialog needed to be able to cope with that a printer can already have gone away even though it is still displayed in the dialog. So, I made changes to include appropriate error handling so that while using CPDB, the issue of stale printers do not occur. Moreover, I also made modifications so that for CPDB the \"Print Directly\" button of LibreOffice now prints on the default printer initially and not on the first available printer as was the case before. Integrating C-based OpenPrinting Projects in OSS-Fuzz Testing
Contributor: Jiongchi Yu OpenPrinting has successfully integrated two main projects into the OSS-Fuzz framework in June, which includes the migration of the ownership for existing OSS-Fuzz CUPS integration and fixing building issues. We have integrated all harnesses into a new GitHub repo, fuzzing, and are continuously updating and maintain the fuzzers. So far, OSS-Fuzz has identified a total of 34 potential issues and has contributed to one fixed bug in libcups and CUPS. We are pleased that Oliver Chang and Dongge Liu from Google have joined to mentor the integration process and we plan to add more fuzz harnesses in future developments to improve test coverage and will push forward the continuous fuzzing integration of more OpenPrinting projects such as cups-filters. PAPPL API Bridging for Scanner Applications
Contributor: Akarshan Kapoor Akarshan has moved from India to Germany for studying for a semester there. Therefore he had a lot to do with this move in the last month and so he did less on his GSoC project, so he did not provide the usual write-up. For onboarding Alexander Pevzner (author of ipp-usb and sane-airscan) as a mentor, he wrote a short introduction to his project, which is also interesting for anybody not having followed his work in previous news posts: For non-driverless legacy or specialty printers, we have introduced Printer Applications, which emulate driverless IPP printers. To create these Printer Applications, there is a standard library called PAPPL (Printer Application Library), written by Michael Sweet. It contains everything a Printer Application needs, including a daemon, handlers for DNS-SD and IPP, a web admin interface, and more. Michael has also written two native Printer Applications: hp-printer-app (for legacy PCL lasers) and LPrint (for label printers). Till Kamppeter has written pappl-retrofit, an additional library for PAPPL that allows one to easily wrap classic CUPS printer drivers and PostScript PPD files into Printer Applications - retro-fitting. Currently, I am adding scanner support to PAPPL so that it can be used to create both Printer and Scanner Applications, even supporting multi-function printers with a single application. I am adding eSCL support to PAPPL (which previously only supported IPP printing) and SANE support to pappl-retrofit. This approach provides a universal Printer/Scanner driver format that allows for distribution-independent binary packages and the addition of drivers not only to classically installed but also to immutable operating systems. Akarshan's ongoing work you find in this work-in-progress pull request on PAPPL and in his GIT clone of PAPPL 1.4.x. CPDB support for the print dialog of Mozilla
Contributor: Kushagra Sharma I have resolved all the comments on the merge request for adding CPDB support to chromium, the updated code is under review and in this coming week I am planning to have a virtual meeting with chromium team to speed up the merge request. I have also started working on adding CPDB to mozilla which includes both Firefox and thunderbird. Kushagra created a good collaboration with the Mozilla developers now, via my original feature request. Desktop Integration: Update system-config-printer for the New Architecture of printing
Contributor: Shivam Jaiswal With help of ideas discussed with Mohit Verma in meetings, I was clear on what I have to do and how I'm going to test it. Developed Functions for Listing IPP Services: Used Avahi and D-Bus libraries in Python. Implemented functions to list available IPP services. Service Discovery: Program runs DBusGMainLoop() to continuously discover new services. Prints service details whenever a new service is resolved. Next Objective: Deliver the discovered services to the UI part of the system configuration printer. User interfaces for using OAuth2 with printers and scanners
Contributor: Shivam Sharma First I have build a dummy printer for testing the code and after that I started working on an authentication server. It is important to know the flow of access tokens, so I learned about it and implemented the code of it. Then I started working on handling HTTPS requests which will be done by libcurl. Currently I am working on the user interface and in coming weeks I will implement the code written so far and will try to make it secure and to make it secure I am using HTTPS. Replace QPDF by PDFio as PDF manipulation library in libcupsfilters
Contributor: Uddhav Phatak I have migrated following files from QPDF to PDFIO, also I have changed the code for these files from C++ to C qpdf-tools.cxx, qpdf-cm.cxx, qpdf-xobject.cxx, qpdf-pdftopdf.cxx, qpdf-pdftopdf-processor.cxx As there was a \"pptypes.cxx\" file dependancy while migrating \"qpdf-pdftopdf.cxx\". So that I have changed pptypes.cxx extenion to .c extension. Currently, I am validating the changed qpdf-pdftopdf-processor.cxx functions. Here is Uddhav's work on GitHub. Gaurav Guleria is now finishing the merge requests for CPDB support in the Qt print dialog, actively working out the remaining rough edges with the Qt developers (#556476, #437301, #471258, #116726). Good News! We found a volunteer who will work on the CUPS 3.x support in the KDE Print Manager together with KDE developer Mike Noe! As I told in April Mike Noe from KDE is working on CUPS 3.x support for KDE's printer setup tool. Now, well after the contributor application deadline for this year's GSoC, Tarun Srivastava, student at the Indian institute of Technology Mandi in India, showed interest in participating in OpenPrinting. He started working on a CUPS issue and after some conversation with Michael Sweet, the problem got solved. He showed more interest in OpenPrinting, reached out also to me, and then I offered him three areas for contribution: Working on further issues, working on library documentation, and doing the CUPS 3.x support for KDE. He picked the latter. Now Tarun is enthsiastically on it, talking with Mike Noe by e-mail and also discussing on our Telegram channel for the CUPS 3.x support in the GNOME Control Center, as he will have to resemble this functionality in KDE. So seems that the first Opportunity Open Source in Mandi was really successful ... The Gutenprint project (formerly GIMP-Print as it provided also GUI for printing out of GIMP), created by Michael Sweet, overtaken by Robert Krawitz, and currently taken care of by Solomon Peachy, was an approach to get high quality, free software inkjet printer drivers, especially for photo printing, also with specialty inkjets (like 6 gray-level monochrome) from third parties. Mainly covered were Epson and Canon inkjets, including large formats, and also dye-sublimation photo printers. Also some HP inkjet and laser printers were supported. Robert Krawitz was working on the project with a lot of enthusiasm for many years, making it the most sophisticated and most active non-manufacturer free software printer driver project, and while he was on it, most Epson inkjets got quickly supported. Unfortunately, Robert stopped working on Gutenprint some years ago due to lack of time. Maintenance got continued by Solomon Peachy, but as he joined originally for the dye-sublimation printers, development of Epson and Canon printer support practically died. As Solomon is now mentoring Ankit Pal Singh on his GSoC project about creating a native Printer Application of Gutenprint I got to have a conversation with Solomon which turned out to also be interesting for our readers here and so I published it (with his consent) as an interview here: Solomon: Gutenprint is effectively dead upstream, other than my work. I keep hoping that these GSoC efforts will supr other interest, but none of this is cool sexy work.. :( Till: Are there really new printer models coming up needing Gutenprint and somebody implementing the support for these models? Solomon: Yes, unfortunately. :) Well, that someone is me, but yeah. The commercial/industrial dyesub space is still quite resistant to IPP Till: As label printers ... Solomon: Label printers are another vertical that is largely sdk driven instead of generic raster. Till: So the only new models in need of Gutenprint support are dyesubs? Or are Epson and Canon still producing proprietary-only inkjets? Solomon: I can't speak about canon but Epson is still producing non IPP models, especially on the very high end They still see IPP as something that iterates too rapidly and drives up the cost/complexity/support burdens given the decade-long lifecycle for a given model Several times now I've actually been hired by US/EU branches of printer makers to reverse engineer things because it was easier than working with their corporate head office. Corporate politics are really screwed up sometimes... Till: That's great ... Solomon: Its been a long time since I've been able to talk anyone into funding improvements to the low level infrastructure though. Most of my work on gutenprint has been self funded. I prefer to focus on the hardware support side, but... I'm the only one keeping gutenprint alive now. I have some contract work coming probably next month for a new router. And I'm still slowly backfilling in some other models as time and access to hardware permits. Er, a new printer. Not router. Till: So there is somebody contracting you to add support for their printer in Gutenprint? Solomon: Yep. Though not the actual manufacturers Till: OS vendors? Solomon: ISVs producing things like kiosks and specialized print servers, mainly. Till: So these drugstore photo kiosks which have a dyesub printer inside? Solomon: That's one of the major markets, yes. The other major one I deal with is for folks wanting an on premise printing solution for event photography or selfie booths at weddings. Till: These thingies which also often make it to closing parties of conferences, like the Ubuntu Summits. Solomon: They are incredibly popular still. Till: And these high-end Epsons, these seem to show shortcomings of IPP. Are there problems to map the high-end imaging into IPP? Or is it this vast amount of adjustable parameters? Solomon: I think it's the latter, and the fact that the normal use cases require actively tweaking things until you are happy with the output Printing on custom media, using custom inks, and more. These things are typically driven by a dedicated RIP built on a mfg sdk instead of via OS drivers. Till: And is it straightforward to add the new Epson models into the existing Epson driver of Gutenprint? Or are they inventing all the time new communication protocols? Or is the problem more the always new and different ink sets? Solomon: It's not hard to add basic support for new Epson models, but tuning the output to be \"good enough\" for standard use case is time consuming especially if it involves a new ink set. I only did it once. Till: And probably requires from you to have the actual printer (which you would have to buy if you do not get some form of external support for this work)? Solomon: But yes, either someone sends me a printer or I buy one myself. I have quite a collection now, thanks to eBay and being able to repair broken stuff. Epson has a newer communication language and they even provide a cups driver... but it uses a proprietary library. But all of their high end stuff still provides esc/p2 because that provides the low level knobs you need for all the custom stuff. Dyesubs are comparatively simple, so I've often got things working with someone else sending me USB sniffs, spool files, and running tests. But it's a lot faster to have the printer on hand. Usually results in more features too as I can experiment more Till: So Epson's proprietary driver with its new proprietary language is more for the \"consumer\" users who want everything ready-made, like what is IPP supposed to be good for, and there is ESC/P2 for the \"power users\" to have access to everything? Solomon: I think that's fair, yes. But afaik all of the relatively recent esc/p-r models also support IPP directly Till: So the ESC/P-R driver is actually only needed for non-IPP legacy models? Solomon: ...maybe? I honestly haven't looked into it. Epson also doesn't publish any esc/p-r specifications I don't have any contacts with them. When I added the surecolor D700 [Epson SureLab D700, see below] to gutenprint I produced over 100 printed before the quality was acceptable in my eyes. If that hasn't been paid work I would have never have done it. Till: This is a lot, you run through a lot of cartridges, this is impossible if you have to do this on your own dime ... Solomon: Exactly. This sort of tuning needs mfg support. Or better yet they do it themselves. Till: I only have seen by the options in Epson's ESC/P-R PPDs that this driver is rather low-end. It often had only 300 or 360 dpi as resolution, not these crazily high ones directly accessible with Gutenprint. Did they already reach the 10000 dpi? Solomon: That esc/p-r 300dpi is the software exposed resolution. The hardware is much higher, and generates the high res dot/dotjer patterns internally. Till: Does it not make sense to feed at least 600 dpi from the software side into the driver? Solomon: Those crazy high resolutions refer only to individual ink drops. You might get 2-3 drop sizes only so you have to use dithering to get smooth tones. So in practice a 3840dpi printer is still only 360 from a sw perspective Iirc the models that use /300 dpi are all esc-pr, but /360 can use escp2 as well Till: So there are 300-dpi Epsons? And these are ESC-P/R only (perhaps also IPP)? And the 360-dpi models are both ESC/P-R and ESC/P2? Are the high-end ones all 360-dpi then? Solomon: I think so? Like I said, I have only mucked with two models personally. Till: So you are more the master of the dye-subs? Solomon: Yes, that was how I got involved in this space. And then everyone else sorta left. Till: Meaning that we probably will not see support for new Epson and Canon models? Solomon: The short answer is... Probably not. The canon maintainer hasn't been heard from for several years. I could probably take over that stuff completely but.. not on a purely volunteer basis. Till: But this will cost a lot of time and money (printers, lots of cartridges, ...). Solomon: Exactly. Fwiw I think it wouldn't be a lot of work to write a native esc/p-r driver for gutenprint and make the Epson drivers irrelevant. But that goes back to time and money. ...I have not had a lot of spare time these days, and prefer to spend what I do have outside instead of staring at screens. Till: Yes, and such a high-impact driver change requires testing on actual hardware. Solomon: For several of the dyesub models I've reverse engineered driver binaries to work out algorithms. And often it's not the algorithms themselves that matter, but instead it's embedded data tables. Meanwhile gutenprint needs updates for the gimp plugin too. Gimp 3 and newer versions of gtk. The work adds up. I'm hoping to at least get a new gutenprint release out soon. Till: Yes, this would be great. The Debian (and so also our Ubuntu) package has a crazy version number, due to lack of releases. 5.3.4.20220624T01008808d602-1build4 Solomon: The CI system that Robert set up has gone MIA too. There is a lot of stuff I don't know about that needs to get done for a proper release. Till: So with the background of that most modern consumer or office printers are IPP, including Epson and Canon models, Gutenprint's Epson and Canon support is to be considered rather a way to keep legacy printers alive and for you to do great, useful, and impactful things with Gutenprint is to concentrate on dye-sub, as here IPP support is lacking and in this area you get more easily somebody contracting you. Solomon: I think that is a good summation The ultra high end and commercial gear also benefits from gutenprint due to the extreme tunability required by the target market. But everything else is legacy. Till: But this one only if somebody maintains Gutenprint and adds the new models. Solomon: Current models too, yes. But for any new model to be added someone has to do the work.. Till: And therefore it makes the impression for me that this high-end printing support via Gutenprint is dying. Solomon: That's probably been true of gutenprint as a whole for a decade. I sometimes think it might be simpler to fork gutenprint and strip out everything that isn't for dyesubs A pure dyesub subset would be a lot simpler to bolt onto PAPPL too. Till: This would be a good idea ... The inkjet part would go into OpenPrinting's driver museum for legacy printer support via the (retro-fitting, nobody is willing to make a native one) Gutenprint Printer Application and the dye-sub part goes on actively maintained by you including a native Printer Application. WDYT? Or would this lead to a lot of independently maintained duplicate code? Solomon: I don't know. The main complication/duplication has to do with the backend. And that happens whether or not gutenprint itself is forked. Figuring out how to merge the backend stuff into the application is a task I've been putting off until after the rest of it is at least demonstrable. Till: OK, looks like that will still need some effort ... Solomon: Yep. Pappl also gives us a lot more options for dynamic settings (Eg restricting available print sizes or other options based on printer state) so that will factor into how things get restructured. And much better status reporting options. And being able to seamlessly combine print jobs to save paper or time. Till: So with PAPPL we get much better printer drivers and for the client it is all IPP? Solomon: Since PAPPL is a running daemon it is a lot easier to carry state versus the old cups every job is completely standalone model? Till: It even saves state files so that it carries on where it left off after a reboot. Do you have something which you want to tell to our readers? Solomon: The main thing... see Xkcd #2347 I got into this printer hacking world so I could actually use my own printer without using proprietary software/drivers that were ... Quite awful Even in an IPP world, that still matters. Till: XKCD #2347 ... The usual one ... It is referred to a lot ... Solomon: Every IPP printer I have owned has had serious bugs that only occasionally get fixed. My brother laser printer is more reliable using cups+gutenprint talking to the jetdirect port than via IPP. And faster too? Free software still matters. Anyway I need to go help with dinner, but thanks for the chat. :) Till: Dinner?! For what that? You should better use the time for coding ... Solomon: Plus my phone is at 2%. Till: And thanks for the patience with me, have a nice dinner! After proofreading this interview in the form how I have posted it here, Solomon has provided me with some corrections and additional information: Solomon: Corrections: The Epson printer I mentioned is the SureLab, not SureColor. And Epson is actively maintaining two esc/p-r drivers, one fully open source but the other partially proprietary. But they support different sets of printers. I think the standard office types are handled by the open one but high end+prosumer stuff is by the proprietary one. The latter being Gutenprint's general niche these days. Till: So the \"newer communication language\" you meant originally, which uses a proprietary library, is actually also ESC/P-R? Solomon: Yes. The proprietary library is most likely dealing with the fancy multicolor ink sets. But it's not something I've looked into. Or wanted to look into. :) After 10 months, and working currently on snapping the CPDB backend for CUPS, we are now releasing the sixth beta of the second generation of the Common Print Dialog Backends (CPDB). Changes on the CPDB libraries Changes are Streaming print job content Simplifying list filter control Allow permanently running backends Print dialog update on addition or removal of backends Dropped job control functionality Discontinued the FILE backend Bug fixes This caused some API and D-Bus communication protocol changes. See the announcement post. Changes on the CUPS Backend Changes are Updated names of some CUPS constants to CUPS 2.5.x and newer Removed tryPPD(), a useless, PPD-related function Unified logging. We always use the log...() functions now. Build test ( make check) fixes Bug fixes The new versions of the CPDB components cpdb-libs: More Details and Download, Discussion cpdb-backend-cups: More Details and Download, Discussion There were two new CUPS 2.4.x releases in June, one containing the bug fixes which happened so far plus a security fix and the second quickly done to fix a regression caused by the security fix: 2.4.9: CUPS 2.4.9 brings a security fix for CVE-2024-35235 and several bug fixes regarding CUPS Web User Interface, PPD generation and HTTP protocol implementation. 2.4.10: CUPS 2.4.10 brings two fixes: Fixed error handling when reading a mixed 1setOf attribute. Fixed scheduler start if there is only a domain socket to listen on (Issue #985) with the latter being a fix for a regression caused by the fix for CVE-2024-35235 in scenarios where there are no other listeners in cupsd.conf than the domain socket created on demand by systemd, launchd or upstart. More Details and Download"
+ },
+ {
+ "id": "post:OpenPrinting-News-March-2020",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - March 2020",
+ "url": "/OpenPrinting-News-March-2020",
+ "headings": [
+ "OpenPrinting Summit/PWG Meeting Virtual",
+ "Linux Foundation Member Summit 2020 has been cancelled",
+ "Google Summer of Code 2020",
+ "Avahi local service support",
+ "Printer Application Framework/SDK -> PAPPL",
+ "Driverless scanning",
+ "Printing Stack Snap",
+ "CUPS",
+ "cups-filters",
+ "IPP-over-USB: ippusbxd and ipp-usb"
+ ],
+ "tags": [],
+ "snippet": "Virtual OpenPrinting Summit/PWG Meeting, LF Member Summit 2020 cancelled, Linux Foundation accepted as GSoC mentoring organization, PAPPL Printer Application Framework, Avahi 0.8.0 released with localhost support, AirScan in Ubuntu 20.04, cups-filters 1.27.3, ippusbxd 1.34",
+ "content": "On May 5-7 we will have our annual meeting again, the OpenPrinting Summit/PWG Meeting. Because of the Corona virus situation we have turned it into a virtual meeting using WebEx instead of actually coming together in Lexington, KY. The originally planned schedules are slightly changed to get shorter meeting days. Unfortunately, the Linux Foundation Member Summit 2020 in Lake Tahoe, California, has been cancelled due to the Corona virus as many other events got cancelled. The Linux Foundation got accepted as a mentoring organization on February 20. So we have continued looking for students and let them do assignments to introduce them into OpenPrinting. The application period for students has started on March 16 and currently we are working with our student candidates on their proposals. We are giving them more background information about the project ideas so that they can plan how to work on the projects. The students who have reached this stage of our selection process have successfully fixed 9 issues on the OpenPrinting GitHub which we have given to them as assignments. Some additional issues we have closed as invalid after investigations done by out students. The number of open issues of cups-filters is down to 8 now. We have also 13 mentors registered already for OpenPrinting, so mentoring for all students will be assured. The application period for students ends on March 31, so we are still accepting student applications. The accepted student projects will get announced on April 27. See the GSoC 2020 timeline. As I told last month Trent Lloyd has added support for localhost to Avahi. Now he has released version 0.8.0 with the localhost support included and my name is listed in the \"Thank you\" section of the release notes. Now all the requirements for Printer (and Scanner) Applications to work are fulfilled. Michael Sweet has started his PAPPL, a framework/SDK for creating standards-conforming Printer Applications. Especially allows configuration and administration with a web interface, a command line interface, and a basic IPP System Service interface and it opens only one socket for all configuration interfaces and IPP device emulations. Note that PAPPL is still under development and not in a working state yet. The printer-application-framework project from GSoC 2019, which I had moved into OpenPrinting last month and also started improving it for actual use is now deprecated by PAPPL, as it is missing configuration interfaces and runs IPP printer emulations with independent sub daemons on different ports. Some part of the code could perhaps still be used in future Printer Applications. I want to than Dheeraj Yadav for his work anyway, as it was an important study to try out and understand the new architecture. After having a deeper look into PAPPL and also LPrint, the very first working Printer Application, a driver for label printers, also from Michael Sweet, which also has a good documentation I have written up how a Printer Application should work, especially also with user experience in mind, and Michael has agreed with that, and he wants to add that to the documentation of PAPPL. What I had written up is the following: A Printer Application should work like this: Fire up the daemon after installation of the Snap and after each subsequent boot (declare as \"daemon: simple\" in snapcraft.yaml). Check whether there is an \"lp\" system user available. If yes, let daemon drop privileges fully or partially, depending whether root is needed to access the hardware device. Opening the socket and filtering can always be done as \"lp\". Open the socket, at least localhost:PORT, only one single socket on one single port. Depending on configuration settings the socket is also opened on the network: HOST:PORT. For simplicity I will only mention localhost in the next steps, also only http and ipp and not https and ipps. Fire up the web admin interface: It should always be there, even if no supported printer or scanner gets discovered or manually set up. Make also a command line interface and optionally an IPP System Service interface available. Observe devices appearing and disappearing through the whole life of the daemon process. Auto-setup USB- and DNS-SD-discovered devices when they are not already set up and when configuration does not suppress auto setup of a certain device or generally. Do not wake up hardware devices during auto-setup. Use only the information of device IDs and DNS-SD records plus the knowledge of the Printer Application itself (driver) for the initial configuration of the device. Do not use SNMP for auto-setup, it causes more problems than benefits. Mark queues online and offline on devices appearing and disappearing. For each hardware device create an IPP device emulation with an URI as follows: Here the OfficeJet 5000 is a multi-function device which also does Scan and Fax and the Printer Application supports this (HPLIP for example). My suggestion is to have the same queue name for the printer, scanner, and fax which belong to the same hardware device. Only query a hardware device (possibly waking it up) if A client sends a get-printer-attributes IPP request A client sends a job The user configures the device using the Printer Application's web interface. A new Printer Application should be done natively whenever possible, not simply wrapping PPD files and filters. Printer Applications retro-fitting PPD files and filters should only be used for older, now unmaintained drivers, proprietary drivers where the manufacturer does not care, or as a quick interim solution if a Linux distribution should be turned all-Snap, especially with CUPS in a Snap. All PPD options which can get translated to IPP attributes should be made available as IPP attributes, all options of the PPD including the ones which cannot get converted to IPP attributes should be configurable by the web interface, so that a user can at least access them by setting queue default values for them. The Printer Application is not restricted to only provide functionality for the printing and scanning itself and preparing it but can contain all printer-specific software, like the GUI tools which come with HPLIP. (I do not know whether this is required by standards, but in my opinion it should work) Make use of GUI tools contained in a Printer Applications Snap optional, always also allow installation of the Snap and using it on a GUI-less, headless server. This especially requires that all configuration should also be available through the web admin interface. Michael Sweet has also updated our GSoC project ideas appropriately and the mentors are also informed about the new requirements. While preparing our students for writing their proposals, Michael has discovered that IPP System Service is missing a standard DNS-SD record. So he has quickly defined one and already put it onto its way into the IPP System Service standard of the PWG. SANE 1.0.29 with the \"escl\" (AirScan) backend made it into Ubuntu 20.04 LTS (Focal Fossa), so we have AirScan support, meaning that hundreds of scanners in multi-function devices will work now. Alexander Pevzner has expanded his \"airscan\" SANE backend to be a general backend for manufacturer-independent high-level scanning protocols. He already has added the WSD (Microsoft, W3) scanning standard and plans to add IPP Scan support soon. Here is his work so far on GitHub. He will also mentor a student on the IPP Scan server/Scanner Application project in this year's GSoC. I have been on a Canonical Engineering Sprint in Frankfurt as my last trip right before the Corona virus shutdown and talked with the developers of the Snap infrastructure about the CUPS Snap integration. For the Printing Stack Snap I have posted the following requests on the Snapcraft Forum: Interface request: “cups-control” on CUPS snap and including D-Bus: Snaps are a form of sandboxed software packages. The packaged software is inside an enclosure to allow detailed control of the interaction between this software and the outside world. To define the allowed communication Snaps use interfaces which describe what is allowed. These interfaces are defined in snapd, the central control entity for the Snaps on a system. For the CUPS printing Snap we need a specialized interface allowing the communication channels of CUPS. its TCP socket, its domain socket, and its D-Bus services. This is a request to the snapd developers to add an appropriate interface. Hardware-associated snaps - Snap Store search by hardware signature: The main reason for which we are developing Printer Applications is to provide printer drivers in a way that we can used sandboxed packaging for security and for making the driver packages working on any Linux distribution, not needing to build them for each distribution individually. But when the Printer Applications are put up as Snaps in the Snap Store, users would need to find the corrct Snap for their device to install it. Adding a hardware signature list could make the finding of the correct driver automatic, by hardware info being sent to the Snap Store as search term. This is the appropriate feature request for snapcraft and the Snap Store. No further releases. Still no commits on the CUPS GitHub since Dec 18, 2019. But now I got the first sign of life from Apple after Michael Sweet has left. I got answers on my two bug reports, one about mangling IPP attribute names, and one about cupsctl corrupting the cupsd.conf file. Currently released is 1.27.3. Next development steps of cups-filters are to go towards a PPD-less world and Printer applications: Make all filters working without PPD, with IPP options. Exceptions are filters especially made for PPDs, as foomatic-rip. Add build options for no-PPD-supporting CUPS, raster-only Printer Applications, no cups-browsed. Snaps will often have their own cups-filters and then a very limited part of it. Move more functionality into the libcupsfilters library, so in Printer Applications filter chains could be implemented as library function calls instead of external executable calls 1.27.3: Bug fix release, fixing Ghostscript-based PDF page counting in foomatic-rip to work with all Ghostscript versions, building libfontembed tests with correct path to test font, re-sharing of remote CUPS queues with cups-browsed and others 1.27.2: Bug fix release, mainly to fix regressions cause by the zero-page-job-support implementation in foomatic-rip, also some code improvements in foomatic-rip and some crasher fixes in cups-browsed Released ippusbxd 1.34 This release is mainly to improve the DNS-SD advertising to equal the one of the network mode of the device and also to advertise its AirScan scanning capabilities, but we also have some communication and code base improvements. DNS-SD-advertise the device's capabilities based on polling the device via IPP (printing and send-fax part) and via HTTP (eSCL scanning part, if available), the records now contain the same information as the DNS-SD records which the printer broadcasts through its network connection Improved code base by formatting, header files, comments in the header files, and improving debug output Added exponential backoff for print read requests when printer’s responses are empty for saving resources and reducing log file spam Apparmor: Matched path when bin and sbin directories are merged"
+ },
+ {
+ "id": "post:OpenPrinting-News-March-2021",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - March 2021",
+ "url": "/OpenPrinting-News-March-2021",
+ "headings": [
+ "CUPS has new home at OpenPrinting!",
+ "Google Summer of Code 2021",
+ "CUPS Snap",
+ "PostScript Printer Application",
+ "User experience: Automatic printer setup, printer setup tools",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "New CUPS home is OpenPrinting, CUPS Snap and PostScript Printer App in Snap Store, Printer setup tools/user experience",
+ "content": "Due to the fact that CUPS development at Apple has stopped since the beginning of 2020 we had forked CUPS some months ago to incorporate patches and fixes from the distributions. As Apple did not resume the upstream work on CUPS, we have made OpenPrinting now the official upstream home for CUPS. This especially means that we can now continue developing CUPS, independent of Apple. So we can add features and lead CUPS into the new architecture without PPD files and with Printer Applications. CUPS has a new home page now and what was formerly our fork is now the official CUPS repository. Upcoming releases will be of the new 2.4.x series, now without \"opX\" suffix now. Also all documentation files which come with it are updated to point to the OpenPrinting resources. Mailing list for development discussions is our printing-architecture list. First feature additions have already happened, all Snap support which the CUPS Snap and the Ubuntu package of CUPS received as package-specific patches is now upstream in CUPS. Update: The Linux Foundation got accepted as mentoring organization by Google! We have applied again for the Linux Foundation as mentoring organization, as in the previous years, for the Google Summer of Code. The accepted organizations will be announced by Google on Tue, March 9, 2021 (Timeline). OpenPrinting's project ideas are posted, but further ideas are still welcome. Note that the projects are half-length this year, 175 hours instead of 350 hours (see our October news. Larger projects we should run in the Linux Foundation Mentoring Program instead of in the GSoC. The CUPS Snap is in the Snap Store now! After several months of waiting, the snapd developers have finally accepted and merged the needed changes for CUPS to receive both printing and administrative (create/modify queues, delete anyone's jobs, ...) through secure interfaces and to easily upload applications with print functionality (like LibreOffice) to the Snap Store without them being able to do administrative CUPS tasks and this without the CUPS Snap needing full access to the snapd core. So we have a secure and easy-to-use printing infrastructure also in all-Snap operating systems. But note that access from non-Snap software gets always granted, so it is recommended to only install such software as package of your OS distribution. Please see the README.md file of the CUPS Snap for installation instructions. Update: All needed interface connections are now approved for automatic setup, so you simply install the Snap and it is ready to use. To make the CUPS Snap your standard printing environment you have to disable or remove your system's CUPS (usually installed as RPM or DEB packages) first. Note also that one cannot install classic CUPS printer drivers into a snapped CUPS system. You need to use driverless IPP printers (AirPrint, IPP Everywhere, Mopria, Wi-Fi Direct Print, those on which you can print from a phone without dedicated app), remote CUPS printers, or PostScript printers (using the PostScript Printer Application, Snap Store). More Printer Applications to provide additional drivers are on the way. Automatic migration to the CUPS Snap by OS distributions will only happen if enough drivers are available as Printer Applications. Update Call for Testing I have now posted a \"Call for Testing\" for both the CUPS Snap and the PostScript Printer Application on Discourse. Please try everything out, following the instructions and post your experience there. Features and fixes in the past month: As already told, the correct implementation of the slots for the \"cups\" and \"cups-control\" plugs of client Snaps, so that the CUPS Snap does not need to plug \"dangerous\" interfaces to the system, like \"snapd-control\". Applied all code changes needed on CUPS to support Snap, both for cupsd being in the CUPS Snap and for access control of client Snaps to CUPS upstream, so with the next CUPS release, we do not need to apply patches to CUPS for its snappability any more. Currently, we are applying one single patch with all these changes. Do not modify the CUPS code with sed any more. Updated the plugs of the included command line tools, depending whether they are administrative or not. Silenced warnings during build due to missing paths for the included command line tools. Get up-to-date with the upstream sources: CUPS 2.3.3op2, QPDF 10.3.0, 1.28.7 Main TODOs are: Testing Make sure CUPS backends have correct permissions (USB currently not working). Turn classic CUPS drivers into Printer Application Add a migration script so that OS distributions can easily switch over from classic packages to the CUPS Snap. The PostScript Printer Application is also in the Snap Store now! You can simply install it now and it is immediately ready to use, no manual connection of any interfaces is required as everything got approved. After installation you only need to set up your printers via the web interface or command line interface. If needed you can also upload your own PPD file into the Application. See the README.md for detailed instructions. Update Call for Testing I have now posted a \"Call for Testing\" for both the CUPS Snap and the PostScript Printer Application on Discourse. Please try everything out, following the instructions and post your experience there. The only new feature added after the February news post is: In the Snap use pyppd to compress the included PPD files from 60 MB in tarballs (.tar.gz) to 5 MB in pyppd'd self-extracting archives. Otherwise a lot of testing of the Snap was done and a lot of things got fixed: A patch on PAPPL allows the command line control of the server as normal user while the server is running as root (daemons auto-started by a Snap run as root). This change was also submitted upstream. Removed unneeded plugs \"network-manager\" and \"log-observe\" In the Snap make the temporary directory available for non-root users Set a default spool directory and allow changing via environment variable to not create a new directory in the $TMPDIR with every instance and leave them dandling around. Silenced warning in Snap build. Correction for build failure in Snap Store Updates to keep working after PAPPL API changes Unfortunately, some things in the PostScript Printer Application are not working as expected due to bugs in PAPP: USB connection only uni-directional (This especially leads to polling option defaults and installable accessory configuration not working) When creating a print queue via command line, I cannot auto-select the driver (You cannot use -m auto when creating a print queue via command line) Web interface: After adding a queue via command line the frontend does not show all queues (Display glitch of the web interface) \"autoadd\" via command line works but gives 3 times \"ps-printer-app: Unable to get IEEE-1284 device ID: Pipe error\" (Principally it works, but ugly messages appear on the screen) With appropriate features added to PAPPL we will be able to also add the following: Human-readable strings for vendor options. Needs support in PAPPL. Ink level check via ps_status() function. Needs support in PAPPL. Once having these features implemented, the PostScript Printer Application is complete so far. I have also looked into how to solve the printer auto-setup problem in PAPPL and this way in the Printer Applications. Therefore I have started a discussion on the OpenPrinting printing-architecture list. First problem is if there is more than one Printer Application (with each having its individual auto-setup) installed (for example by the OS distribution) each one wants to poll the device ID from the newly plugged Printer Application at the same time, making perhaps the \"best\" Printer Application not getting it ... We discussed also having a central utility doing the auto-setup and ran into the problem that if more than one installed Printer Application supports the printer in question which Printer Application to select for creating the queue. so we concluded that as driverless IPP printers will be the standard and non-driverless printers which need a Printer Application are either legacy or specialty auto-setup is not that important. We only need some way to guide the user on which Printer Applications are available locally and in the Snap Store. So to not let the users with non-driverless-IPP printers alone and lost I think the desktop should continue to have a printer tool to guide users to find the correct Printer Application, and so started a second thread \"Future of Printer Setup Tools\" suggesting how a printer setup tool could look like in the future: Main window: Instead of having a list of our local CUPS queues we have a list of installed Printer Applications, which printers are set up with them and buttons leading to web interface, IPP System Service panel, printer options, ... All information obtained through Avahi/DNS-SD, could be expanded to a general network service lister (think about also having a button leading to the web interface of your router). Add-printer wizard: Replaced by a list of discovered non-driverless printers (USB, network) and after selecting one you get a list with installed Printer Applications supporting it with button to open the web interface and also a button to do a fuzzy search of make/model in the Snap Store. Johannes Meixner from SUSE suggested to reach this also by a button in the print dialog. We need people to do GUI work for the new printing/scanning architecture. Related to this I posted two feature requests on PAPPL: Extend \"ps-printer-app drivers\" to also show supported device IDs Add subcommand to simply ask whether a given printer is supported Also, having hardware-signature-based Snap Store search would be great here. Currently released is 2.3.3op2. 2.3.3op2 is the last release of the 2.3.x series. To mark that CUPS upstream development is now under OpenPrinting, we start 2.4.x. Ubuntu Hirsute Hippo (21.04) will ship with CUPS 2.3.3op2, also the CUPS Snap currently uses this version. Currently released is 1.28.7. Many things were going on in the other projects, so here we have only one bug fix, raising the timeout of cups-browsed's implicitclass backend from 20s to 60s, to make printing more reliable if cups-browsed is very busy. Currently released is 1.0.2. The release fixes many bugs. PAPPL development has continued, approaching 1.0.3. See also the currently open and closed issues of PAPPL."
+ },
+ {
+ "id": "post:OpenPrinting-News-March-2022",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - March 2022",
+ "url": "/OpenPrinting-News-March-2022",
+ "headings": [
+ "Google Summer of Code 2022",
+ "OpenPrinting web site",
+ "CUPS Snap and snapd printing interface",
+ "How it works",
+ "How to snap an application",
+ "Thanks",
+ "Flatpak and printing",
+ "Approaching cups-filters 2.0",
+ "Ghostscript supports driverless IPP data formats",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "Linux Foundation accepted as GSoC 2022 org, \"cups\" Snap interface for applications ready, Snap vs. Flatpak for printing, approaching cups-filters 2.x, Ghostscript and driverless IPP",
+ "content": "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, ... We have posted everything you need to know for participating and our project ideas for you to have a look. We also appreciate any new project ideas brought up to us and narurally also contributors suggesting their ow idea. And we already have one extra project idea since last month: Make a native Printer Application from Gutenprint 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 this 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. CUPS Snap in the Snap Store 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, I will describe here how the final concept works and how to snap an application with print functionality: 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, ... 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 he can have maximum security without losing functionality of the application. He uploads the Snap to the Snap Store and when a user installs it on his 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, ...) on the system's classically installed (RPM, DEB, ...) 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 het improved. Now when I started to get printing into the Snap world several years ago, snapping CUPS but also looking into how snapped applications can print, I 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 I 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 I started exactly one year ago, on March 18, 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 February 7, 2022, I 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, ...) 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, ...) 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 configures and automatically starts in its proxy mode. This means the CUPS Snap's 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 told 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 I have 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 I 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 packages can be different. Therefore wen 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\". Snapping an application with print functionality is easy, do not get turned away by these 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: or Third, add the placeholder content interface to trigger the auto-installation of the CUPS Snap. Simply add the following lines to snapcraft.yaml: 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 as you see it here. 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 what is needed to use the cups interface is plugging cups as described in the second step here. Forth, 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. See a complete example here. Thanks a lot to my 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 iontegration of the Snap mediation into the CUPS code. I have 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 (comimg freedesktop.org, popular in the RedHat-ish world) is also common. I asked Zdenek Dohnal from Red Hat and he and Felipe Borges, a colleague of him at Red Hat told me 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, ..., 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 deniers, 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 contrary 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, ...), 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 under you who have followed the activity of the OpenPrinting project already for longer 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 shouting into 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 (Here is the one of GTK) 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 if 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 at least for me 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 and links about Flatpak. I am 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 I worked on the imageto...() filter functions again and corrected the centering of the image with print-scaling=none (commit) and the switching between fit-to-page abd no sacling with print-scaling=auto (commit). I also added support for grayscale (sGray 8-bit) PCLm printing support (commit, commit, commit, commit) and added PCLm output support to the gstoraster CUPS filter executable (commit). By the way, I got motivated to do this by discovering a driverless printer which supports only PCLm, the HP LaserJet M15. Usually, driverless IPP printers also support Apple Raster to allow printing from iOS devices via AirPrint. And finally I 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. Npow the filter checks for *cupsFilter2: \"...\" lines and corrects from the given format to the input format of the corresponding line as destination format (commit). 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 (commit). 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. I have 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 I have added new appleraster and urf output devices to let Ghostscript generate the Apple Raster (URF) format for driverless IPP printing (commit). The chabge 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, I have 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). From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|4141| |ipp-usb|ipp-usb|1729| |ps-printer-app|PostScript Printer Application|2257| |ghostscript-printer-app|Ghostscript Printer Application|1143| |hplip-printer-app|HPLIP Printer Application|3847| |gutenprint-printer-app|Gutenprint Printer Application|3169| Currently released is 2.4.1. There will be further bug fix releases in the 2.4.x series. An important bug fixed recently is that with 2.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. I 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. I have 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 ofg using the convenience API's 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 I 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. Currently released is 1.28.12. We are continuing to polish and to fix bugs for the 2.0.0 release. I have 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. I have also backported the fixes on the imageto... filters to cups-filters 1.x, included in the 1.28.12 release. Ubuntu Jammy Jellyfish (22.04 LTS) will ome with cups-filters 1.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. Currently released is 1.1.0. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-March-2023",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - March 2023",
+ "url": "/OpenPrinting-News-March-2023",
+ "headings": [
+ "Linux App Summit 2023",
+ "GUADEC 2023",
+ "Google Summer of Code 2023",
+ "cups-filters 2.0b4 in Ubuntu 23.04",
+ "libcupsfilters and libcups 3.x",
+ "cups-browsed",
+ "Common Print Dialog Backends"
+ ],
+ "tags": [],
+ "snippet": "LAS 2023 in Brno, GUADEC 2023 in Riga, GSoC 2023, cups-filters 2.x in Ubuntu 23.04, libcupsfilters with libcups 3.x, CPDB 2.0b4, cups-browsed 2.0b4",
+ "content": "I am again late with this month's news, but now a very important step is done: The second generation of cups-filters has made it into Ubuntu, version 23.04, the Lunar Lobster! After a lot of hard work adding missing requirements, especially programs and scripts for automatic testing of each build and each upload, and after getting the all the code security-audited, the new packages landed in time on last Friday, 3 days before Beta Freeze yesterday (March 27). And between all of this I keep our Google Summer of Code contributor candidates ~~entertained~~ doing their assignments and familiarizing with the projects and now I am lining up our 2023 team of contributors and guiding them through their proposals. With the first beta of libcups 3.x out I have investigated the migration of libcupsfilters to the new API, and we are well prepared ... And, as last year, you will see me on several conferences: For sure on the Linux App Summit in Brno, Czech Republic, the GUADEC in Riga, Latvia, and the Ubuntu Summit, ... perhaps also on the Open Source Summit Europe in Bilbao, Spain or the Linux Plumbers Conference in Richmond, VA in the US ... For the Linux App Summit 2023 in Brno in the Czech Republic the schedules are published! My talk with demos of the state of the art of the Common Print Dialog Backends (CPDB) support in print dialogs and the \"Printers\" module of the GNOME Control Center, and discussion with the audience, will take place on Saturday, April 22, at 16:35 CEST. Unfortunately, due to the huge amount of great submissions and the limited time slots in only 2 rooms on 2 days, my Snap workshop and my OpenPrinting BoF did not get accepted. But it is not such a big problem of the BoF not being accepted, we will have our own one. To have more time to discuss with my colleagues and contributors on the printing area, Zdenek Dohnal (Red Hat), Marek Kasik (GNOME/GTK), Albert Astals Sid (KDE/Qt), Harald Sitter (KDE/Qt), I will have a meeting with them on (Update) Saturday, April 22, at 15:00 CEST (room/place TBD). Everyone who likes can join. I will announce any updates, changes, details on it in my next news post or a news flash here and on Mastodon, #LinuxAppSummit and #OpenPrinting. After a great first GUADEC for me in Mexico last year I will continue attending GUADECs. This year I do not need to cross the ocean, GUADEC takes place in Riga, in Latvia on July 26-31, as last year 3 days of talks, 2 days of BoFs and workshops, and 1 day of touristing. Yesterday the Call for Proposals had its original deadline, but as there were not enough proposals to comfortably fill all the time slots the submissions got re-opened, this time without showing any deadline, but their Tweet reveals that the extension is for a week, meaning that the deadline is April 4 now. So think in the next days about what you like to tell to the GNOME folks in Riga, what you want to teach in a workshop, what you want to discuss in a BoF, ... It is your chance now ... Also here I have submitted a talk to demo the printing-related GUI changes in GNOME/GTK and to discuss them with the audience. And if all works fine it will get snappy on the GUADEC ... The time window for GSoC contributor candidates to submit proposals has opened and the deadline is April 4. This means for our candidates to write their proposals and mentors to review them. Also mentors have to register and mark in the already submitted proposals whether they want to step up as a mentor for the respective project. Now all our candidates have decided on the project they want to do and are familiarizing with them and also have written drafts of their proposals. The most enthusiastic of them have already started on their projects weeks ago and worked with me and other mentors, often contributors of the previous years, on investigating of what has to be done and planning how to do it. Especially Akarshan Kapoor who is doing the scanning support in PAPPL has started off very well with his mentors Rishabh Maheshwari (Last year's contributor on eSCL support), Deepak Patankar (Mentor on PAPPL scanning also last year), and me. First, he updated PAPPL's documentation with the scanning API Bhavna Kosta had added in GSoC 2021. As the next step he created a list of all the printing-related functions of PAPPL and the ones of Bhavna's scanning-related API functions and added for all printing functions which had no scanning counterpart the appropriate scanning function. All this is now posted as a pull request on PAPPL. Now Arkashan is working on integrating Rishabh's eSCL parser and make incoming requests being distinguished between IPP for printing, eSCL for scanning, and general HTTP for the web admin interface. For this news post he writes: While working on the initial prototyping of a Sandboxed Scanner Application Framework, I encountered a task that required processing and segregating client requests. The way it works is that the client sends a request to the Application Framework, and the API must segregate the request into HTTP/eSCL requests. After creating an initial pathway for implementing this, I realized that I didn't fully understand the format in which the eSCL requests were received. Further exploration revealed that these requests were essentially XML requests and required an XML parser to extract information from them. The parser can be implemented through string matching and is currently being developed. Implementing this and combining it with the current Application Framework will be a checkpoint that leads to integrating it with another parser that parses various scanning capabilities. As reported last month all new packeges which are put into the Canonical-supported core part of Ubuntu (\"Main\") need a build test and an autopkgtest which are run on 6 architectures everytime when a new release of the package itself or any package depending on it gets uploaded. cups-browsed was still lacking both tests and the Common Print Dialog Backends (CPDB) packages were missing a build test. So I have created appropriate scripts and added them to cups-browsed and to the three CPDB packages. All these tests are run by make check called after building the repective package. The challenge for the build test for cups-browsed was to exercise cups-browsed in the way it is actually used without needing root access and ideally independent of the configuration of the system, so that make check also works on build servers for example and not only on fully equipped desktop machines. cups-browsed needs 4 further daemons around itself: CUPS to create print queues on, avahi-daemon to collect DNS-SD broadcasts of printers, dbus-daemon to receive notifications about new jobs from CUPS so that it can dispatch them to their destination printers, and ippeveprinter to emulate IPP printers. I have taken the (very sophisticated) build test script of CUPS (test/run-stp-tests.sh) as example for my test script. There I copy/link the system's CUPS files into separate directories out of which I am running my own CUPS instance on port 8631, as normal user. I especially have to copy the CUPS daemon executable (/usr/sbin/cupsd) into the separate directory so that AppArmor does not act on it. cups-browsed does not need to run as root, it only needs to have admin access to CUPS, so it is easy to run it attached to our separate CUPS instance. And for a private D-Bus there us the dbus-run-session utility. I was not able to create a private instance of avahi-daemon though, ending up with the need of a system's avahi-daemon. This works in most situations, especially as one can register services without being root, but on Canonical's build servers there is no avahi-daemon running and so I had to skip make check in the Debian/Ubuntu package of cups-browsed. Due to this special nature of cups-browsed and the fact that I run the same test script as autopkgtest (run on virtual machine with all needed packages installed), the Ubuntu MIR (Main Inclusion Request) approval team accepted the package into Main. And the tests also showed already what they are good for, they made me finding some bugs in cups-browsed, including even some crashers, which I have fixed now. I got also asked to try to run cups-browsed as normal user, which the tests showed that this actually works. cups-browsed only needs to be allowed to do adminstrative requests on the CUPS daemon, meaning the system user running cups-browsed has to be in the \"lpadmin\" group. It also needs a cache directory writable by the system user. The current Ubuntu package is now running cups-browsed as a normal user. But not only tests are needed, the code of each package promoted from Universe into Main is thoroughly security-audited by Canonical's security team: Coverity runs, code reviews, have daemons to run as root, SETUID, ... (see report in the MIR) This takes several hours of work for each package and when many new packages arrive close to Feature Freeze (1 month before beta, 2 months before release) the queue gets long. Easily a package cannot make it into Main for the desired Ubuntu version and it stays for the next version 6 months later. And we got lucky with the security checks, they got finished last Friday night, in time for the Beta Freeze yesterday (Monday, March 27). Thanks, Sebastien Bacher, for nagging the security team, thanks, Seth Arnold and Alex Burrage from the security team for expediting these packages, and especially thanks, Mark Esler, for your patience with me on the last package, cups-browsed. So Ubuntu 23.04, the Lunar Lobster, will already contain a first piece of the software for the New Architecture. We will not be running in the New Architecture, still using Debian packages of CUPS (2.4.2) and classic CUPS drivers installed as Debian packages, but we use everything with the 2nd generation of cups-filters. So we will most probably have some more bug fixes, as not every fix got backported to cups-filters 1.x. But the most important is that we have 2 \"small\" (non-LTS) releases of Ubuntu in which the new cups-filters will get used and tested, this helps a lot for a safer transition into the New Architecture in 23.10 (based on the CUPS Snap) and to CUPS 3.x in 24.04 LTS. The packages for the Common Print dialog Backends, cpdb-libs, cpdb-backend-cups, and cpdb-backend-file, did not make it into Main yet. Therefore CPDB is not yet used in GTK's print dialog. This will happen together with the general swithcover into the New Architecture in Ubuntu 23.10, to be released in October. I will try to set up a Sneak Preview of the New Architecture (CUPS Snap, CPDB, GNOME Control Center) via a PPA (Personal Package Arquive) soon, though. With libcups 3.0b1 available I have investigated on how well the code of libcupsfilters 2.x is prepared for the new CUPS library, and it seems that we are in a good shape ... First, Michael Sweet has prepared the migration to the new library very well, by his always excellent documentation, here the MIGRATING.md file in the new library's source package. The file describes everything what changed, which functions and data types got renamed, which got removed, also what the new names are. The removal of features is no problem at all for us, as the 2 removed areas are PPD support and non-destination-based listing of queues or printing. For the former we are perfectly prepared, as all PPD support is removed from libcupsfilters and so none of the PPD-supporting functions of libcups get called. And functions of the latter area were never used by libcupsfilters. So the main part of the migration is the renaming, but one can, after converting the code of libcupsfilters completely to the new API, easily create something like a libcups2.h file containing: and let configure.ac set HAVE_LIBCUPS2 if the code is built with the old CUPS library. Another point are interface variants. The old library (cups/array.h) had the following API functions: So there are 3 interface variants for creating a CUPS array. This is because Michael Sweet has started with the first one and later on realised that one can make (sorted) CUPS arrays better if the user can, in addition to a function for comparing two items, also specify functions for copying and freeing items, and also a hash function. So he added the other two interface variants, giving them new names, with added small integer numbers, to keep the original variant to avoid breaking the API. In the new API Michael has cleaned up, doing away with the variants and only keeping the most sophisticated one, with the simplest, original name, without number. This serves everyone, simply set parameters for functionality you do not want to NULL. It looks like this then: Here we will have to define some wrapper functions, simply defined inline in our libcups2.h file (or an accompanying libcups2.c file). There is one oversight in MIGRATING.md though: Also the APIs in cups/backend.h and cups/sidechannel.h will go away. The latter is not used in libcupsfilters (I have removed an unnecessary inclusion here) and the former only by the function cfResolveURI() in cupsfilters/ipp.c, but this can be easily fixed by using the new libcups3 API function httpResolveURI() (cups/http-support.h). In this case we also will not have to unset the DEVICE_URI environment variable. Here one can create a wrapper function in libcups2.c/libcups2.h, named httpResolveURI() which unsets DEVICE_URI and calls httpBackendResolveURI(). With all this libcupsfilters should work perfectly well in the new CUPS 3.x world. cups-browsed got a forth beta release centered in getting test scripts. Here I have created a script which serves both as build test (make check) to be run as non-root, with its own CUPS instance, and as CI or autopkgtest running as root with installed packages. It runs emulations of IPP printers to be picked up by cups-browsed to auto-create CUPS queues on them. On these queues a test job is printed and cups-browsed has to dispatch the job to the printer. This naturally made me doing several test runs and they revealed several bugs which I have fixed in this release: implicitclass backend: If no destination got reported by cups-browsed, retry after one minute, not the standard 5 minutes of CUPS. debug_printf(): Check for need of log rotation only if log file is set and opened, to avoid a crash. on_printer_modified(): Added NULL check to avoid a crash. ipp_discoveries_add(): Ignore duplicate entries. These are most probably caused by a bug in Avahi, having certain discoveries of a printer reported twice and others not. When the printer disappears Avahi reports the disappearal of each discovery correctly, leaving the duplicate entry untreated (removing only one instance of it) and cups-browsed assumes that the printer is still there, keeping its CUPS queue. update_cups_queues(): Reset counter for pausing CUPS queue updates. Otherwise after having updated the number of queues supposed to be the maximum for one run of update_cups_queues(), cups-browsed will never update any queue again. resolve_callback()/resolver_wrapper(): New thread only when printer found We move the check which resolver event we have (found/failure) already in the main thread (resolver_wrapper()) and launch a new thread only if we have found a new printer and have to investigate whether to add a queue for it or not. resolve_callback() only initiates this investigation now. This way we do not need to pass the resolver data structure (of type AvahiServiceResolver*) into the new thread, which caused segfaults. create_remote_printer_entry(): Corrected some memory freeing when a printer data structure is deleted, but this has not caused a segfault in the recent tests. Fixed issues reported by Red Hat Coverity tool (Pull request #6) There are more issues resulting from a Coverity run by Canonical's security team. They will get checked and fixed soon. The 4th beta release towards 2.0.0 was all about getting build tests (make check) added to fulfill the requirements for getting into Ubuntu Main. The tests of the backends start the backend and also the text-based sample frontend of cpdb-libs to check whether printers appear in the frontend's list and whether one can print on them. The test of the CUPS backend even runs its own instance of cupsd (like the tests of CUPS and cups-browsed also do) to let the backend discover the CUPS queues. In addition, cpdb-libs facilitates creating test scripts by installing its text-based demo frontend as a developer utility, with the name cpdb-text-frontend and by allowing to search for backends in an aleternative directory, specified by an environment variable. And the work on test scripts revealed some crash bugs which are fixed now."
+ },
+ {
+ "id": "post:OpenPrinting-News-March-2024",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - March 2024",
+ "url": "/OpenPrinting-News-March-2024",
+ "headings": [
+ "Google Summer of Code 2024",
+ "Opportunity Open Source - 2nd edition!",
+ "CPDB CUPS backend Snap",
+ "Scanning support in PAPPL",
+ "Snap automation working well",
+ "SpliX 2.0.1"
+ ],
+ "tags": [],
+ "snippet": "Easter Egg in xz, GSoC 2024, Opportunity Open Source 2024?, CPDB Snap, PAPPL scanning, Snap automation, SpliX 2.0.1",
+ "content": "This Easter weekend was really eXZiting ... Mastodon is full of posts about the backdoor sneaked into xz/liblzma (CVE-2024-3094) by a co-maintainer who stepped in for the original maintainer suffering burnout. The compromised free software project is a widespread data compression library, performing better than the other libraries of this type, like bzip2 for example. This hobby project got a standard part of the operating system, used on practically any server on the world. Fortunately, the issue was discovered quickly, thanks to Andres Freund who discovered something going wrong when benchmarking Postgres changes. He investigated and finally reported his shocking discovery on OSS Security, and he posted on Mastodon causing a long thread where he also shortly explained how he came to xz as the culprit. Even Andres' report explaining the attack excellently, there were many articles, blogs, videos, ... giving more or less detailed explanations, like a video by Brodie Robertson, the Ubuntu Security Podcast (read also the text at the end of the page), a blog about the shell script-based obfuscation, FAQ as GitHub Gist with discussion, or summarizing it on a single page. Also articles about the strategies the attacker has probably used are there, for example a nice article about the social engineering by the attacker or explaining how the attacker tries to hide their location. It was really a sophisticated piece of engineering, hiding the binary-only (closed-source) backdoor code in a test *.xz file and hiding the code for the multi-stage decryption and extraction in the cryptic autotools build system and in a second *.xz file, and in the end making it only installed when the user/packager uses the release tarball and not a GIT snapshot, to make it not being discovered when auditing/testing the GIT. In addition, the components got added in several commits distributed over months. Thanks, Andres, for investigating and discovering this!! This shows one of the principal problems of free software: Some arbitrary hobby programmer creates something useful for them and thinks it is also useful for others, and so they publish it as free software. Now it gets picked up by other free software projects and ends up getting into all Linux distributions and the original contributor suddenly is maintaining an important part of the world's IT infrastructure. At OpenPrinting we are in a good situation, as nobody of us is about to give up, we only need to take care that there are no such \"Easter eggs\" hidden in any contributor's commits. Also, frequently attending conferences and meeting one's contributors there in-person helps to improve the relationships. But I have also good news: Anyone following us on Mastodon has perhaps seen that I am using the ubuntu.social server. The founder and maintainer of the server, Alan \"Popey\" Pope (thanks a lot), former employee of Canonical, active contributor to Ubuntu, and a Snap packager, has given up maintaining the instance and looked for somebody to overtake it, and Canonical has jumped in! Thanks a lot to Canonical and especially Philipp Kewisch, manager of the Community Team! So all my posts and threads I have linked in my news posts will stay available. So let us see what was exciting at OpenPrinting in March ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions The submission window for contributor proposals has closed yesterday and many proposals got done only close to the deadline, especially also of people who did not contact us before submitting. Those not contacting us usually have poor proposals and we do not consider them. We only select contributors with whom we have communicated before the submission, and the most important criterium is that they work well with us there, doing assignments well, having done vuluntary contributions, starting on their actual project early, ... All this raises them in our ranking for the selection, not the proposal. At OpenPrinting we had a good amount of candidates this year. ~15 have communicated with us in the weeks before the submission window and received assignments, building and modifying CUPS, issues, ..., some have even contributed valuable voluntary work starting last year. Here are especially to mention Rudra Pratap Singh who went above and beyond on Snap update and versioning automation, Biswadeep Purkayastha who made our libraries ready for libcups3 and currently makes CPDB backends snappable, Ankit Pal Singh who volunteered on preset support in Printer Applications and contributed comment preservation in cupsd.conf when it is modified by cupsctl. Rudra's and Biswadeep's work we have covered in more detail last month here. We have also Akarshan Kapoor and Kushagra Sharma returning to participate this year to continue their great work on scanning support for PAPPL and on CPDB support for print dialogs. If all works out fine, we will cover especially the desktop integration well, finishing and merging the CUPS 3.x support of the \"Printers\" module in GNOME Control Center (GSoC 2023 report), adding support for the New Architecture also to system-config-printer and getting CPDB support in LibreOffice (Mailing list thread) and Mozilla (Firefox, Thunderbird) (Feature request). Unfortunately, we have nobody to update KDE's Printer Manager (Issues #1, #2, #11). So we have many project proposals and naturally would like to have them all going, but for that we need mentors, many mentors, ideally 2 per project. So we need your help! If you are interested to help us mentoring, contact me (e-mail at the top left of this page) and I give you instructions on how to register. Please see our project idea list for what we are mentoring this summer. Please step up as soon as possible, as we do not need only your actual mentoring but also you being registered while the contributor slots are distributed, and if we do not have enough mentors on our list, we get less slots. Also note that you do not need to take full responsibility for a contributor's project but also can help mentoring, especially if you can contribute appropriate expertise. Thanks in advance to make this GSoC amazing! Many of you remember the Opportunity Open Source conference in the IIT Mandi in India which was grown out of the idea that Aveek Basu and me wanted to meet our GSoC contributors and motivate more people to join the free software community and GSoC. It was a great success and therefore we want to make it annual, meaning that we are now aiming for its second edition. Very first step is to find a place and a date for the event. It should be in India again, as most of our contributors come from there. So we started to brainstorm now on our \"Opportunity Open Source\" Telegram channel and currently the most promising candidates are the IIT Mandi, where we did it last year, and the IIT Kanpur. Most of our contributors are studying or have studied in Mandi, and even with Akarshan Kapoor, main on-site organizer last year, being on an exchange semester in Germany this summer, there are already others jumping in. Shivam Mishra, GSoC contributor and mentor in previous years, is studying at the IIT Kanpur and suggesting to run the conference there, expecting around 300-400 attendees (instead of the ~100 we had in Mandi). He tells that there \"has been a really active Open-Source community\". He also tells that the IIT Kanpur is larger than the IIT Mandi and closer to Delhi, and it is \"among the top 5 technical institutes in India\". Travel to Kanpur would also be easier than to Mandi, especially if it gets rainy. For the date we are aiming for the weekend after the UbuCon Asia 2024 which takes place in the JECRC University, Jaipur, India, on Aug 31 - Sep 2 (Sat - Mon), meaning that we will go somewhere inside Sep 6 - 8 (Fri-Sun). This way I (and also others, potential speakers) can attend both with one trip, and I can arrive in Kanpur already some days earlier for the preparation. Taking the weekend before UbuCon (Aug 23 - 25) would give me the opportunity to give a talk about this Opportunity Open Source in Jaipur and to attend aKademy 2024 in Würzburg, Germany, on Sep 7-12, but I also have to stay longer in India, and the risk of rain is higher. So these are our ideas for now. We appreciate a lot any suggestion or help. If you want to discuss and/contribute, please join our Telegram channel. End of last year I have investigated how to make a Snap of the backends of CPDB (Common Print Dialog Backends), especially the one for CUPS and ran into several problems, especially as we have to do with user daemons now and the frontend browses available D-Bus services to find all installed backends. So I started a discussion on the snapcraft.io forum and found out that several things need to be changed on CPDB. Biswadeep Purkayastha who was already volunteering for doing the Snap started doing these changes. We covered this here in the October News and in the November News. Biswadeep made good progress: 1. The printFile method of backends needs to pass the job data as stream (file descriptor or domain socket), not as file specified by a file path. Done. The data is now streamed through a domain socket. 2. The D-Bus methods getActiveJobsCount, getAllJobs, and cancelJob need to get removed from CPDB Done. 3. The file backend of CPDB cannot be used. We should discontinue its development and tell that it is for development and documentation only. Low-priority point, which does not stop us from snapping the CUPS backend, but we will do it before the final 2.0.0 release. 4. Filtering of the printer list in the dialog should be completely managed by the frontends, and not by sending signals to the backends, to allow different filtering on print dialogs which are open to the same time. This point is actually different, as we discovered later. The backend recognized from which frontend the signals came and so served different, individually filtered lists to each backend, so handling the filtering by the backend was not even the problem, and also has the advantage of sending less data to the frontemd. More a problem was that the frontend is also a D-Bus service, not only the backends. And the only thing the frontned D-Bus service does is sending signals to the backends to switch the filtering. Here the right way is to implement the filter switching as methods in the backend interfaces and remove the need of the frontends also being a D-Bus service to get a real Snap hell. Biswadeep is currently working on this one. 5. Add newly appearing backends while the dialog is open. Not yet started, will be Biswadeep's next point. Biswadeep's work is progressing well and available in pull requests. The pull requests for (1) and (2) are already merged. cpdb-libs: Pull Request for (1) and (2) (merged), Pull Request for (4) cpdb-backend-cups: Pull Request for (1) and (2) (merged), Pull Request for (4) Thanks, Biswadeep, for your great work! Akarshan Kapoor is continuing to work on the scanning support in PAPPL, to allow providing scanner drivers as Scanner Applications and the Printer Applications for multi-function printers also covering the scanner part. In the GSoC 2023 he created an eSCL parser and afterwards SANE driver retro-fitting support for pappl-retrofit. Currently he works on the implementation of the scanning API functions in PAPPL and will continue this in this year's GSoC. Thanks a lot, Arkashan! Thanks to the awesome work of Rudra Pratap Singh on the Ubuntu Snap automation GitHub action and naturally also on the Snaps themselves we have now deployed Snap update automation and Snap versioning automation on OpenPrinting's Snaps. See our detailed coverage in the January News. What is still missing, is to devide up our Snap GitHub repositories into 2 branches, a development one and a stable one and to have the automation running on the stable branch and the resulting packages uploaded to the \"candidate\" channel of the Snap Store, controlled by a Launchpad setup, as described in the second part of my Snap update automation workshop. Now, using the simple autobuild mechanism of the Snap Store web admin interface, the automation simply happens on the master branch and the resulting Snaps go into the \"edge\" (unstable/development) channel of the Snap Store. But this is good enough to observe whether the automation works correctly, and it actually does! So no worries any more about the frequent updates of QPDF or the many drivers contained in the Ghostscript Printer Application. They get all just updated and as long as they build the users get up-to-date software. Also the version numbers are nice
Student: Lakshay Bandlish
Mentors: Rithvik Patibandla, Michael Sweet, Ira McDonald, Smith Kennedy, Danny Brennan Common Print Dialog Backends (CPDB) Qt implementation
Student: Priydarshi Singh
Mentors: Dongxu Li, Nilanjana Lodh, Till Kamppeter, Deepak Patankar IPP scan (or virtual MF device) server (Scanner Application)
Student: Aakash Lahoti
Mentors: Alexander Pevzner, Thierry Hucahrd, Michael Sweet, Ira McDonald, Smith Kennedy, TIll Kamppeter General Printer Application SDK (PAPPL-based)
Student: Jai Luthra
Mentors: Dheeraj Yadav, Michael Sweet, Ira McDonald, Till Kamppeter Make Printer Applications configurable (via PAPPL)
Student: Sambhav Dusad
Mentors: Michael Sweet, Dheeraj Yadav, Ira McDonald, Till Kamppeter, Sahil Arora Speed/scaling optimization of cups-browsed
Student: Mohit Mohan
Mentors: Till Kamppeter, Deepak Patankar Extract raster data from PDFs for direct printing
Student: Vikrant Malik
Mentors: Sahil Arora, Alexander Pevzner, Thierry Hucahrd, Till Kamppeter They all started getting into their projects now and some have even startet coding. The Linux Foundation got accepted as one of the 50 mentoring organizations by Google! We have lined up and registered 19 mentors! So we will not have any problem with assuring continuous mentoring during the whole doc writing period. As umbrella organization we can get up to 4 project slots which we will distribute to the sub-organizations of the Linux Foundation. Here are the project ideas for OpenPrinting. Especially we want to get a tutorial written so that printer and scanner manufacturers have an easy guide to design and package their drivers as Printer Applications. Michael Sweet is not alone any more on the PAPPL project. After some e-mail exchange with Michael and me both Jai Luthra and Sambhav Dusad have started coding on their GSoC projects and Michael has accepted their first pull requests. Sambhav has added buttons for handling jobs and Jai has added DNS-SD discovery. Alexander continued the development of his \"airscan\" SANE backend, having many users testing their devices making up a longer and longer list of devices known to work. Especially now there will be only one entry per physical device even if it supports both eSCL and WSD and discovery is also much faster and the exact behavior is configurable via the configuration file. In addition, there is now the new airscan-discover utility included, to simply discover supported devices via command line. In contrary to the former separate tool this one is written in C now. And the WSD support got merged into the stable \"airscan\" GitHub branch. So we can count on a release and also on the start of the IPP Scan support development soon. On the snapd interface for the Printing Stack Snap we came to a solution. We settled on going the PulseAudio way, patching the CUPS daemon to check whether the inquiry is administrative, and if yes, if the client process is of a Snap which is not under classic confinement. In this case we reject the inquiry if the client Snap is not plugging the \"cups-control\" interface. The appropriate patch for CUPS I have committed to the CUPS Snap's GitHub. The snapd team is now working on the new interfaces. After that I have continued work on the Snap: Updated upstream packages: CUPS 2.3.3, cups-filters 1.27.4, Ghostscript 9.52, QPDF: 10.0.1 Let the standard domain socket (/var)/run/cups/cups.sock be used when the Snap's CUPS is the only one on the system, for maximum compatibility with client applications Made the libcups of the Snap read the Snap's configuration files, especially the client.conf with the domain socket actually used by the Snap Use the \"snap_daemon\" user to replace the unavailable \"lp\" system user to drop the privileges of filter and backend processes Dropped several modifications on CUPS which are now not needed any more, especially the removal of all chown() and chmod() calls For determining an admin group for the snapped CUPS, check first whether the host system has an \"lpadmin\" group, then \"adm\", and after that allow CUPS administration only to root. Added fixes for CUPS upstream bugs which Apple did not apply yet Fixed setup of fonts.conf file for the texttopdf filter Made cupsctl correctly working. The Snap is approaching to have all features and fixes needed for use as the standard CUPS of a Linux distribution, but for actual use we need to complete the Printer Applications in this year's GSoC, as classic drivers are not supported by a snapped CUPS. New release 2.3.3: Security fixes CUPS 2.3.2 did not get actually released. CUPS developer Steve Algernon from Apple was on this year's OpenPrinting Summit/PWG meeting but he did not give a presentation, so we have no new CUPS roadmap. Currently released is 1.27.4. No further releases. Ubuntu 20.04 is shipping ippusbxd 0.34. Unfortunately, on some multi-function devices, when querying the eSCL scanning properties, it comes to a segfault. I plan to issue a 0.35 release and use it for a Stable Release Update on Ubuntu 20.04. Later another bug got discovered and Thierry Hucahrd and Alexander Pevzner are working on it. I like to include the fix in 0.35, too."
+ },
+ {
+ "id": "post:OpenPrinting-News-May-2021",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - May 2021",
+ "url": "/OpenPrinting-News-May-2021",
+ "headings": [
+ "OpenPrinting Summit/PWG Meeting",
+ "Google Summer of Code 2021",
+ "Google Season of Docs 2021",
+ "CUPS Snap",
+ "PostScript Printer Application",
+ "Driverless Scanning",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "OpenPrinting Summit/PWG Meeting, GSoC, GSoD, CUPS Snap proxy mode, PostScript Printer Application, CUPS",
+ "content": "On May 4-7 we will had our annual meeting, the OpenPrinting Summit/PWG Meeting. Because of the Corona virus situation we again had a virtual meeting. Smith Kennedy from HP wrote up a great summary of the meeting. There are also the minutes from Ira McDonald. The slides of all presentations are linked on the agenda of the event. Google has officially announced the accepted student projects. The Linux Foundation got 19 student slots and so could accommodate all students they considered for mentoring. With this we can also run 5 student projects for OpenPrinting: cups-filters: Make sure all filter functions work without PPD files
Student: Suraj Kulriya
Mentors: Jai Luthra, Till Kamppeter, Dheeraj Yadav cups-filters: Convert filters to filter functions
Student: Pratyush Ranjan
Mentors: Till Kamppeter, Dheeraj Yadav cups-filters: Create a single, universal CUPS filter to replace the chain of individual filters
Student: Pranshu Kharkwal
Mentors: Till Kamppeter, Dheeraj Yadav GUI for listing and managing available IPP Print/Scan services (or DNS-SD-advertised network services in general)
Student: Divyasheel
Mentors: Till Kamppeter Firmware and other file handling in PAPPL
Student: Bhavna Kosta
Mentors: Jai Luthra, Till Kamppeter With our application for this year’s Google Season of Docs we did not get accepted. CUPS Snap in the Snap Store, Call for testing on the snapcraft.io forum and on the Ubuntu Discourse As reported in the April news I have worked out a security concept with the snapd developers to print from user application Snaps without allowing administrative access to CUPS. With this we can let developers upload applications to the Snap Store which automatically connect to the cups interface for printing, without the risk that such applications mess with CUPS. We have discussed the concept further on the snapcraft.io forum (this post and the following) to work out the details. Now only the finalization in snapd is needed. The final concept is here, only the paths for the CUPS socket needed to get adjusted. I have also presented my work on the CUPS Snap on the OpenPrinting Summit/PWG meeting. Features and fixes in the past month: The CUPS Snap is now based on Ubuntu Core 20 and not Core 18 any more. The Core20 base Snap did not support mDNS host name lookup. This got fixed now but the CUPS Snap also contains a workaround. Added libpaper support. Restricted the build architectures in the Snap Store to the actually supported ones: amd64, arm64, and armhf. Upgraded the built-in Ghostscript to 9.54. Main TODOs are: Complete the security concept on the snapd side, especially implement the content interfaces Testing Turn classic CUPS drivers into Printer Applications Add a migration script so that OS distributions can easily switch over from classic packages to the CUPS Snap. Up to now, the CUPS Snap got installed from the Snap Store more than 1600 times! Note that it is still only on the Edge channel, there is not yet an \"official\" release. PostScript Printer Application in the Snap Store, Call for testing on the snapcraft.io forum and on the Ubuntu Discourse I have presented my work on the PostScript Printer Application on the OpenPrinting Summit/PWG meeting and Michael Sweet has also given a presentation about Printer Applications in general and PAPPL. Features and fixes in the past month: Following the CUPS Snap also switched to core20 and restricted build architectures also here. Also here added the workaround for mDNS host name lookup as I did for the CUPS Snap. Added checking of the user’s location via locale-related environment variables and based on this use A4 or Letter as default paper size when a new print queue is created, also posted appropriate feature request on PAPPL. Applied a patch for a PAPPL bug of changes of loaded media are not taken into account when printing. Updated the built-in QPDF to 10.3.1 and Ghostscript to 9.54. Some clean-up in snapcraft.yaml. Unfortunately, some things in the PostScript Printer Application are not working as expected due to bugs in PAPPL and/or in printer firmware: USB connection only uni-directional (This especially leads to polling option defaults and installable accessory configuration not working): This seems to be a problem (firmware bug) of my HP OfficeJet Pro 8730, for other printer models it is reported to work. When creating a print queue via command line, I cannot auto-select the driver (You cannot use -m auto when creating a print queue via command line): This works for USB-connected devices now, but for network devices a further fix is needed. For creation of GUI tools to easily find Printer Applications and set up printers we would need these improvements: Extend \"ps-printer-app drivers\" to also show supported device IDs Add subcommand to simply ask whether a given printer is supported With appropriate features added to PAPPL we will be able to also add the following: Human-readable strings for vendor options. Needs support in PAPPL. Ink level check via ps_status() function. Needs support in PAPPL. Once having these features implemented, the PostScript Printer Application is complete so far. Up to now, the PostScript Printer Application Snap got installed from the Snap Store more than 1000 times! Note that it is still only on the Edge channel, there is not yet an \"official\" release. Mopria has published the specifications of the eSCL scanning protocol! You can download it here. Principally it is the same as AirScan, the scanning part of Apple's AirPrint. As long as the hardware industry does not adopt IPP Scan, we can simply do our client/server scan architecture for Scanner Applications as snappable scanner drivers with eSCL. See our discussion thread on the OpenPrinting mailing list. Please subscribe here to participate in the discussion. sane-airscan got finally, two days before Final Freeze of Ubuntu Hirsute (21.04), accepted into the main part of the distribution and so it is now in default desktop installation. This will make the scanners in most modern multi-function printers, plus some stand-alone models (like Canon LIDE 300) work with Hirsute out-of-the-box. Currently released is 2.3.3op2. Michael Sweet presented his plans on CUPS 2.4.x and 3.x on the OpenPrinting Summit/PWG Meeting. CUPS 2.4.x is supposed to get shared printers reporting all required attributes/keys/values, OAuth 2.0/OpenID authentication, pkg-config support, snapcraft support, \"job-sheets-col\" and better \"media-col\" attribute support, TLS and X.509 improvements, and deprecate cups-config and Kerberos authentication. CUPS 3.x will be a major change in architecture, having the CUPS daemon split in two, a user daemon to handle local printing to USB printers and printers in the local network and a system daemon to share printers. Development of CUPS 2.4 is in progress, currently mainly fixing of bugs which were reported to Apple's CUPS GitHub in the last 17 months. Ubuntu Hirsute Hippo (21.04) comes with CUPS 2.3.3op2, the CUPS Snap and the PostScript Printer Application Snap use the current GIT master. Currently released is 1.28.8. I have also presented my work on cups-filters on the OpenPrinting Summit/PWG meeting. I have removed the duplicate PPD generator (for CUPS queues for driverless IPP printers) from libppd, keeping the one in libcupsfilters. In this one I have cleaned up the obtaining of human-readable strings, taking them from a PWF IPP standard repository which is included in the translation string files of CUPS. See the OpenPrinting mailing list thread about this. Currently I am working on improving the handling of color spaces and depths when printing to a driverless printer in Apple or PWG Raster foirmat. Formerly, the auto-generated PPD files of cups-filters provided choices in their \"ColorModel\" option to select color space and depth manually. To make the \"ColorModel\" option in the PPD mirror the \"print-color-mode\" IPP attribute and to make printing easier for the user I am switching to automatic selection. See this thread on the OpenPrinting mailing list and this thread on the Ghostscript developer mailing list. Update: First version, applied to ghostscript() filter function, posted (Details) Please subscribe to the OpenPrinting mailing list and/or to the Ghostscript mailing list to participate in the discussions. I have also merged Mohit Mohan's GSoC 2021 project of multi-threading support for cups-browsed and fixed several bugs in cups-browsed and the filters, many were fixed by GSoC student candidates as assignments. Ubuntu Hirsute Hippo (21.04) comes with cups-filters 1.28.8, also the CUPS Snap currently uses this version. The PostScript Printer Application Snap uses the current GIT master of cups-filters. Currently released is 1.0.3. Michael Sweet has given a presentation about Printer Applications in general and PAPPL on the OpenPrinting Summit/PWG meeting. See also the currently open and closed issues of PAPPL."
+ },
+ {
+ "id": "post:OpenPrinting-News-May-2022",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - May 2022",
+ "url": "/OpenPrinting-News-May-2022",
+ "headings": [
+ "OpenPrinting Summit/PWG Meeting",
+ "Linux Application Summit 2022",
+ "OpenPrinting Micro-Conference on the Linux Plumbers 2022",
+ "GUADEC 2022",
+ "Google Summer of Code 2022",
+ "OpenPrinting Snaps and the Ubuntu Indaba with Mark Shuttleworth",
+ "CUPS Snap and snapd printing interface",
+ "Official Docker image of CUPS and Printer Applications",
+ "Approaching cups-filters 2.0",
+ "CUPS 3.x: Filtering and new D-Bus interface",
+ "ipp-usb: Printer does IPP-over-USB but not driverless IPP and driver vs. driverless",
+ "Contributions to Common Print Dialog Backends",
+ "CUPS-driver-retro-fitting Printer Applications",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/CBPefa0Ckq8/hqdefault.jpg",
+ "snippet": "OP Summit/PWG Meeting, GUADEC, Linux Plumbers, GSoC 2022, \"cups\" snapd interface, CUPS in Docker, PPD-independent libcupsfilters 2.x, IPP-over-USB, HPLIP 3.22.4",
+ "content": "On May 17-19 we will have our annual meeting together with the PWG (Printer Working Group) again, the OpenPrinting Summit/PWG Meeting. Because of the Corona virus situation we will again have a virtual meeting, as in the last two years, with the side effect that everyone can participate, without needing to travel. Instructions for participation via WebEx are on the meeting’s page. The agenda is already put up, with the OpenPrinting part on the first two days. Links to the slides will be continuously added on the meeting page and we will link to any summary/outcome here in the next month’s news. I have been on this year's Linux Application Summit on April 29 and 30 in Rovereto, Italy, near the Lake Garda. The conference was successful. It was not only giving talks and listening to other people's talks but also the famous hallway tracks. Here I have, inspired by the critique on slow start-up of desktop application Snaps (Firefox and Chrome in Ubuntu 22.04 especially) and on the fact that there is only one Snap Store, especially discussed distribution-independent/sandboxed packaging, mainly with Heather Ellsworth and Robert McQueen, learning that the way to get OpenPrinting's original upstream CUPS and Printer Applications into image-based OS distributions is to make official Docker images from them. Such conversations are not recorded, unfortunately, but all the talks on the main stage (Auditorium) are recorded in two long YouTube videos, one per day: Friday, Saturday The BoFs did not get recorded. The descriptions of the two videos on YouTube contain a list of links to the beginnings of each of the talks. The links below are also links to the beginning of the talk in the two day's videos. Please see also our News Flash for more info about our talks. Links to the recordings Ubuntu 22.04 LTS (Jammy Jellyfish) Virtual Release Party OpenPrinting Talk about the New Architecture and what GUI/app developers need to know Getting Good: Gaming on Linux Snapcraft Secrets: The hidden power of desktop extensions Ubuntu Summit Announcement Thanks Thanks, Heather Ellsworth, for participating in the organization of the event and making me aware of it! Thanks, Ken VanDine for the original idea of the Ubuntu Summit announcement lightning talk. Thanks, Britt Yazel for MC-ing (Master of the Ceremony) the sessions in the Auditorium! Thanks, Heather Ellsworth, Monica Ayhens-Madon, Britt Yazel, Aniss, Kristi Progri, Dani, Caroline Henriksen for the great collaboration on the organization of the Ubuntu release parties. Thanks, Igor Ljubuncic for providing to me with the YouTube links, and especially with the time marks for each of our presentations! We got accepted for our forth Openprinting Micro-Conference on the Linux Plumbers Conference 2022 taking place from Monday September 12 to Wednesday September 14, 2022. Update: Linux Plumbers will be in-person again! Live on stage in Dublin!! It will be hybrid, so that speakers and attendees do not necessarily need to travel, but for micro-conference runners (Aveek Basu and me) they highly recommend to be there. And to everyone who wants to speak on or attend the OpenPrinting Micro-Conference, please consider to travel to Dublin. It is much easier to communicate, and much more fun!! The date of OpenPrinting’s turn is not yet determined, please keep an eye on the web site of Linux Plumbers. This year the GUADEC (GNOME developer conference) will take place on July 20-25 in Guadalajara in Mexico. But why do I write about this here on OpenPrinting? It will be my first time on The GUADEC! And then a GUADEC at such a nice place! I am not a GNOMie (GNOME developer, or am I getting one as I am managing the work on the GNOME Control Center Printing-and-Scanning module for the New Architecture?), but I want to help them to make printing from GNOME continue to \"just work\" with my talk about the New Architecture of printing and scanning. Here I will introduce the New Architecture and tell what is important for GNOME and GTK developers for applications with print functionality, print dialogs, and printer setup tools. I will also report the progress on the new Printing-and-Scanning module for the GNOME Control Center. Currently, we have to select the best contributor proposals of the many we received, find mentors for these proposed projects, assign the mentors who have stepped up, and then rank the proposals. After the deadline for that on May 12 (this Thursday) Google will assign slots to each mentoring organization and by this the proposals ranked highest will automatically be selected into the slots. There is no way for us to correct after receiving the slot count. Selected contributors/projects will be announced on May 20 (Friday next week). As in the other years we have loked for possible contributors already several months ago. We have let them done some exercises to learn about OpenPrinting, CUPS, cups-filters, driverless printing, ... let them also work on issue reports, mainly for cups-filters. Finally, they all have submitted proposals for GSoC projects. About the Ubuntu Desktop Team Indaba with Mark Shuttleworth I commented on the OMGUbuntu article about the Indaba that Mark did not mention that with Snap you can also package system-daemons and I made heavily use of it and with the Printer Applications one can distribute distro-independent hardware driver packages. On that I got an up-vote from Alan Pope, former Canonical employee who wants to move us to all-Flatpak!! On a Canonical-internal platform I commented the same and got a thumbs-up from Mark. And thanks, Heather Ellsworth and Monica Ayhens-Madon for this great Indaba! CUPS Snap in the Snap Store Finally! Everything for the new cups snapd interface is in place now. snapd 2.55.3 with the new interface and no show-stopping regressions in the stable channel of the Snap Store now and the CUPS Snap is appropriately updated for being used with this interface. For the launch of the interface I have posted a thread on snapcraft.io, describing how one uses the interface when making Snaps from user applications with print functionality and also how the interface actually works. Please see any updated details on how to use it there. Applications with print functionality can now be packaged in Snaps easily, by simply using the cups interface to allow the application to print. When such an application is downloaded from the Snap Store, the cups interface connects automatically. I have also posted a proposal for addition of how to use the cups interface to the snapcraft documentation on the \"doc\" forum on snapcraft.io. Graham Morrison is already on it. On the Linux Application Summit 2022 in Rovereto, Italy, I have, inspired by the critique on slow start-up of desktop application Snaps (Firefox and Chrome in Ubuntu 22.04 especially) and on the fact that there is only one Snap Store, discussed the methods of distribution-independent/sandboxed packaging, mainly with Heather Ellsworth and Robert McQueen. Especially knowing that from Snap, Flatpak, and AppImage (see also March and April News Posts) only Snap supports packaging system daemons, like CUPS, ipp-usb, and the Printer Applications. On systems (and for users/admins) who accept Snaps one can easily get the full printing system right from upstream, OpenPrinting, updated independently of the OS distribution, also after its release, and get support for new printers (and in the future also scanners) in a timely manner. Now let us go to Snap deniers, systems unsuitable for Snap (e. g. not systemd-based), or systems based on a minimal/immutable/atomic/image-based OS designed for applications being installed as Flatpaks. Here we are not able to provide straight-forwardly distribution-independent packages of CUPS, ipp-usb, and the Printer Applications. So printing is restricted to an OS-provided solution or even not possible at all. Robert McQueen suggested to publish an OCI-compatible container image of CUPS (and also images of the Printer Applications) on DockerHub, but official ones by OpenPrinting (there are many third-party ones. These could be run in said systems (including minimal/immutable/atomic OS) using a runtime like docker or podman. After the conference he sent me a longer e-mail about this idea and CCed it to the Flatpak mailing list. He suggested to use podman together with the systemd generator Quadlet for the CUPS daemon to start automatically on boot. This started a small discussion with further suggestions. Unfortunately, I did not find time to follow up on this yet, but will come back to this later. The next step in my preparation of the 2.0 release of cups-filters is the handling of cups-filters in environments which do not support PPD files, like CUPS 3.x and also in environments which support PPD files, like CUPS 2.5.x or older or driver-retro-fitting Printer Applications. First thought, when starting the development of cups-filters 2.x was conditional compilin, but this does not work out. How do we have a libcupsfilters without any PPD file support to use as distro package in a system with CUPS 3.x? But how still be able to install a (non-snapped, DEB package) retro-fitting Printer Application in such a system without needing to replace libcupsfilters by a differently built variant (is this possible in distros?) which supports PPDs, without needing a libcupsfilters generally supporting PPDs (and we all wanted to get rid of them)? So I thought out a design change in cups-filters: Currently the filter functions support PPDs, libcupsfilters depends on libppd, I will remove the PPD support from the filter functions, making libcupsfilters independent of PPDs and libppd, create wrapper filter functions in libppd overtaking the PPD support and calling the original filter function. So dependencies get reversed, libppd depends on libcupsfilters and libppd provides the PPD-supporting set of filter functions, libcupsfilters the PPD-free set, and that without code duplications. I started to do the restructuring with the cfFilterPDFToPDF() filter function (pdftopdf CUPS filter). Created a first wrapper filter function ppdFilterPDFToPDF() calling cfFilterPDFToPDF() with the latter not having PPD file support. I let the PPD file loader function directly translate the PPD file into printer IPP attributes for the call of the original filter function in libcupsfilters now and I have currently created a function to extract the requested paper size dimensions from job IPP attributes and options. Currently I am going through cfFilterPDFToPDF() to eliminate all direct PPD accesses and move them to the PPD loader/PPD-to-printer-IPP-attributes converter and to the wrapper filter function. This I will also do with all the other filters. There it should be less work then, as similar items are needed from the PPD. This will be the last major code change before the release. Once this done I will return to tidying up the code and finally release cups-filter 2.0b1. This way CUPS 3.x could use libcupsfilters without pulling any dependency of PPD file support. For Snaps and other types of sandboxed packages I will also add conditionals to libcupsfilters to skip building the support for unneeded data formats. In a future 2.x release, after 2.0 we will switch cfFilterPDFToPDF() from QPDF to Michael Sweet's PDFio. This way we will get rid of C++ as it causes binary compatibility problems from time to time. For doing this switchover PDFio need to provide all the feature which QPDF does, especially flattening of filled interactive PDF forms. When preparing the talk for the LAS 2022 in Italy I had another look on Michael Sweet's slides about CUPS 3.x from Linux Plumbers 2021. This made me think about the filtering/converting of print data formats in CUPS 3.x and also the D-Bus interface of the local CUPS server in relation to the D-Bus interface of the Common Print Dialog Backends (CPDB). So I started two threads on the OpenPrinting mailing list (not that you need to subscribe to the list to participate in the discussion): (Follow the \"Next Message\" links in each mail or get an overview of the full threads here.) CUPS 3.x: How we make it converting job data formats? This caused a longer discussion between Michael Sweet and me. Michael want to principally use the ipptransform tool (source) of (ippsample](https://istopwg.github.io/ippsample/). He tells that there are only a few formats to be converted. As input only PDF, plain text, JPEG, and PWG will be accepted and as output we need only the driverless standard formats PDF, Apple Raster, and PWG Raster. PCLM he considers as not needed despite there are some HP printers being driverless with PCLM-only. As PDF renderer he wants that there is Poppler support as with GPL2 this is the only renderer which can be shipped (at least as external executable, not linked in) together with CUPS 3.x code in commercial packages. with the AGPL of Ghostscript this is not possible. Ghostscript can be supported as alternative for OS distributions though (they all come with Ghostscript and this seems to be OK for Artifex). There will also be PDF pre-processing (similar to the pdftopdf CUPS filter, based on PDFio. It would be needed for watermarking and header/footer text but also flattening of filled interactive PDF forms. Even if cups-filters will not be used in CUPS 3.x I will continue on it as it is needed by CUPS 2.5.x and by Printer Applications. CUPS 3.x: Printing via D-Bus On the D-Bus interface which Mike Sweet mentioned to be in the local CUPS server of CUPS 3.x I was curious whether we could make the D-Bus interface of the Common Print Dialog Backends (CPDB) compatible with this one and so make the local CUPS server a CPDB backend by itself. Mike told that the D-Bus interface is more ample, continuing many IPP functions. So we will stay with different D-Bus interfaces for CPDB and CUPS 3.x. Recently, we got bug reports of users that their printers stopped working and it turned out that ipp-usb attached to them (because they support the 7/1/4 USB protocol of IPP-over-USB) but do not do driverless IPP printing. The IPP-over-USB standard requires that a printer and/or scanner supporting this USB protocol supports driverless IPP printing and/or driverless scanning (eSCL/AirScan, IPP Scan, WSD). The problem can be a firmware bug, either in the driverless print/scan support or that the 7/1/4 USB protocol is activated on a generally non-driverless device. The devices discovered up to now are the \"HP Laser\" (not \"LaserJet\") devices, printers re-branced from Samsung when HP acquired the printer division of Samsung. At least the HP Laser 107a and the HP Laser 135a are reported to have this problem. The printers seem to work via Wi-Fi though. Alexander Pevzner, author of ipp-usb, has immediately added the HP Laser 107a to the exclusion list (Issue #51) and I have suggested to add a feature to ipp-usb that if ipp-usb is not able to communicate with the device on start-up, to drop out immediately so that classic access will not get precluded (Issue #52). This also raised a discussion (mainly between Alexander Pevzner and Zdenek Dohnal) about whether the introduction of ipp-usb in Linux distributions should auto-migrate print queues with classic driver to driverless IPP-over-USB when ipp-usb supports the printer in question ((Issue #50). Here questions came up like migrating a working print queue with the risk that it will not work any more and also that a classic printer driver can have more features or higher output quality than the driverless approach. Also whether and how to ask the user was talked about. Wor on the Common Print Dialog Backends (CPDB) is continuing! I had posted a project idea for GSoC about adding this functionality to the print dialogs which are currently typically used: GTK, Qt, Chrome, ... and a contributor candidate, Gaurav Guleria (aka TinyTrebuchet) has already contributed to the cpdb-libs and CUPS CPDB backend projects: Add human-readable option/choice name support The original CPDB had only machine-readable option and choice names, making print dialogs only able to display standard options, like media size, media source, resolution, ... nicely. Now the human-readable names used by the print service (CUPS, ...) are made use of (Pull request #2, commit). Support for human-readable-choice-name and bug fixes In the CUPS CPDB backend added support for the options provided by CUPS/cups-filters (number-up, page-set, output-order, ...) which are available for any CUPS queue. Also provide human-readable names for these options and their choices and fixed some bugs (Pull request #8, replaces PR #7). Removed CUPS specific functions from frontend Removed some CUPS-specific functions from the frontend library, everything CUPS-specific should go into the CUPDS CPDB backend, the frontend part has to stay neutral (Pull request #3). Thanks, Gaurav Guleria, for your contributions. HPLIP 3.22.4 in all Printer Applications The HPLIP Printer Application (Snap Store) got another update of the underlying HPLIP version. It is now HPLIP 3.22.4. We continue using the Debian package sources to include more than 80 bug fixes not adopted upstream. Sorry again for the delayed updates due to this. It is always a lot of work for Debian printing package maintainer Thosten Alteholz to update the upstream source code and to adapt the patches where needed. Thanks a lot for this, Thorsten. The update adds explicit support for the new HP printer models which got released in the last two months. Note that most of those printers should also work as driverless IPP printers and therefore also work without the HPLIP Printer Application. Note that there are some former Samsung models re-branded after the acquisition of Samsung's printer division by HP (\"HP Laser\" not \"LaserJet\"). Note that they are not supported by HPLIP AFAIK and do not do driverless via USB (see above). It seems the only way to get them to work is driverless via network (Wi-Fi or Ethernet). The update worked out smoothly. If you have installed an HPLIP Printer Application version which still uses an older HPLIP 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 some minutes and that during this time your printer will perhaps not work. After that, I have 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 3.22.4. In all the 4 Printer Applications (and also in the CUPS Snap) I have also fixed updated the included Ghostscript to version 9.56.1 and unlocked the state of the PAPPL to be used, returning to using the current GIT snapshot. This way all new features and fixes of PAPPL 1.2rc1 are included. From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|4776| |ipp-usb|ipp-usb|2097| |ps-printer-app|PostScript Printer Application|2421| |ghostscript-printer-app|Ghostscript Printer Application|1334| |hplip-printer-app|HPLIP Printer Application|4511| |gutenprint-printer-app|Gutenprint Printer Application|3712| Currently released is 2.4.1. There will be further bug fix releases in the 2.4.x series. Some bug fixes were done, see changes below. Ubuntu Jammy Jellyfish (22.04 LTS) comes with 2.4.1. Ubuntu Kinetic Kudu (22.10 will most probably come with a later 2.4.x. The CUPS Snap and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master of CUPS. Currently released is 1.28.15. We are continuing to polish and to fix bugs for the 2.0.0 release. Currently I am restructuring to make libcupsfilters not supporting PPD files and not being dependent on libppd, to make it easily usable in PPD-free (CUPS 3.x or CUPS Snap) environments. For retro-fitting Printer Applications and other applications using PPD files, PPD-supporting wrapper filter functions, one for each filter function in libcupsfilters, will be added to libppd. See above for more details. The re-structuring and also a lot of other work (see everything here above) made me not doing any further bug fixes on cups-filters, so there is also nothing to backport to 1.x. Ubuntu Jammy Jellyfish (22.04 LTS) comes with cups-filters 1.28.15. Ubuntu Kinetic Kudu (22.10 will be the first Ubuntu coming with cups-filters 2.x. 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. Currently released is 1.2rc1. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-May-2023",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - May 2023",
+ "url": "/OpenPrinting-News-May-2023",
+ "headings": [
+ "OpenPrinting Summit/PWG Meeting",
+ "Linux App Summit 2023",
+ "GUADEC 2023 in Riga",
+ "Ubuntu Summit 2023 in Riga",
+ "Google Summer of Code 2023",
+ "CUPS 3.x release postponed",
+ "Approaching final release of cups-filters 2.0.0",
+ "Test the GUI changes for the New Architecture",
+ "Common Print Dialog Backends getting into the dialogs",
+ "Handling reported security bugs with GitHub"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/3-_aUNZMvko/hqdefault.jpg",
+ "snippet": "OpenPrinting Summit/PWG Meeting 2023, LAS 2023 in Brno, GUADEC 2023 in Riga, Ubuntu Summit 2023 in Riga, GSoC 2023, CUPS 3.x only end-2024, Print GUI testing, CPDB in print dialogs, security bugs",
+ "content": "Update: Michael Sweet wins Google Open Source Peer Bonus for his CUPS project! Congratulations to him!! Lots of conferences during the last 4 weeks: the Linux App Summit 2023 in Brno, then home for a week and after that back to the Czech Republic for a week in Prague for Canonical's Engineering Sprint, another conference-free week again and this week we had our annual OpenPrinting Summit together with the Printer Working Group (PWG) again, but completely online, so no third trip within a month. Hot news from the OpenPrinting Summit, not so nice, by Michael Sweet, author of and maintainer of CUPS: He showed in his CUPS Plenary a nice roadmap for the CUPS 2.5.x releases, in contrary to our last micro-conference in the end of this year. So I have asked him what about CUPS 3.x and he told that he has pushed it out by one year, to end-2024 ... But nevertheless, we will all continue working on the New Architecture, the Printer and Scanner Applications, the Snaps, ... and I will switch Ubuntu 23.10, the Mantic Minotaur, as planned, to use the CUPS Snap as its printing system and the Printer Application Snaps as drivers for non-IPP-driverless printers. We have now configured our GitHub repositories to support private security bug reports and have made our experience with the first vulnerability reported this way, and together with the help of Canonical's Security Team we got the fix completed. I have written up my experience as a tutorial for free software projects using GitHub. And we will get a new team member: My colleague Amin Bandali, in the Ubuntu Desktop Team at Canonical responsable for the packaging of Firefox, got very interested in OpenPrinting. We talked a lot about it in hallway sessions on the Canonical Engineering Sprint, and he attended the whole OpenPrinting Summit and liked it a lot. He is interested in contributing the documentation for the libraries (libcupsfilters, libppd, libpappl-retrofit). Welcome on board! On May 16-18 we had our annual meeting together with the PWG (Printer Working Group) again, the OpenPrinting Summit/PWG Meeting. We presented and discussed our work of the last 12 months and what we plan to do next. Especially CUPS 2.5.x/3.x, use of OAuth with CUPS, cups-filters 2.x, Printer/Scanner Applications, Chrome OS, and the GSoC 2023 projects for the New Architecture were the main subjects of the meeting. Main news item of the meeting was the postponing of CUPS 3.x by a year. In contrary to the previous years we had no presentation from Artifex about Ghostscript and MuPDF. This is due to changes in the staff at Artifex after they got acquired by ePapyrus. I will try to obtain news about the future of Ghostscript from the new/remaining team and post here later. The time slot which got free by that I have made use of to report about cups-filters 2.x, filter functions, separating PPD file support into libppd, clean-up, release, ... in much more detail. A highlight was also the session about the Goggle Summer of Code with our contributors from 2022 presenting and demoing their work and praising me as their mentor. There will be written up summaries of the event in the coming weeks. I will post links to them in the June News. My second Linux App Summit 2023 has taken place in Brno in the Czech Republic, the city of the European Red Hat office. Recordings: Day 1, room 1, Day 2, room 1, Day 2, room 2. Direct links to all sessions are in the comments of the videos (thanks, Ban Jo @Enry211). Unfortunately, there are no recordings of room 2 on day 1. I have also added links to the recordings of all mentioned sessions in the April News On Friday morning I went by train from Vienna to Brno, a trip of only 2 hours, and so I already had lunch with my colleagues from Canonical and the Ubuntu community, Heather Ellsworth, Jeremy Bicha, Dennis Loose, Igor Ljubuncic, and Lucy Llewellyn. In the afternoon we also met Michal Kohutek, with whom we picked up the letters for the decoration of the release party (Ubuntu 23.04, Fedora 38, cups-filters 2.0). Then we all got to the pre-registration social event at Harry's Pivovar (brewery), where we met a lot of people, especially we met Jason Evangelho from Thunderbird (one of the sponsors of LAS) who was hanging out with us most of the time from then on and I also met Keywan Tonekaboni from the German c't computer magazine, who was very interested in my OpenPrinting work. Friday night and Saturday in the early morning in my hotel room I was chatting with Mohit Verma, GSoC contributor for the \"Printers\" module in the GNOME Control Center, and with Gaurav Guleria, GSoC contributor of Common Print Dialog Backends (CPDB) support in the print dialogs, via Telegram and I got some last bug fixes on the printing GUI code for my demo in the afternoon. Thanks a lot! On Saturday the conference started and keynote speaker Marcel Kolaja, member of the European Parlament, got Zdenek Dohnal's (Red Hat printing maintainer) and my help to get some papers for his talk (video) printed on the printer we had at the venue for my demo later that day. Also Jeremy Bicha asked me for some printouts later during the day. For the Canonical/Ubuntu Office Hours we decided spontaneously to not do an AMA (Ask Me Anything) at the booth, but instead, do a panel about Ubuntu and Canonical, similar to what we did last year. Heather Ellsworth, me, Dennis Loose, and Jeremy Bicha (seating order) talked about what is new in Ubuntu 23.04, and what we are working on, and to motivate people to work at Canonical, about how we got hired, how the hiring process is, and about how we work at the pioneer of work-from-home. There were not many attendees as it was at lunch time, but it is recorded, so that people can watch it (video). In the afternoon I met with Zdenek Dohnal and Marek Kasik (Upstream maintainer of GTK print dialog and \"Printers\" module in GNOME Control Center) about all things OpenPrinting and the Google Summer of Code. This was the first time I met Marek in-person. After that my talk and demo about the printing GUI, GNOME Control Center and also the Common Print Dialog Backends used in the GTK and Qt print dialogs has taken place. After some struggle with the projection from my laptop it all worked fine. the printer which Zdenek and Felipe have brought from the Red Hat office also worked. It was the last time slot of the day, right before the release party. So I started telling that we will have the release party for cups-filters 2.x after my talk, as the 2 distros, Ubuntu 23.04 and Fedora 38 are the first 2 with the new version of cups-filters. I explained the New Architecture and its GUI requirements and then demoed the GNOME Control Center and the print dialogs (video, slides). The day's program ended with the release party, officially for Ubuntu 23.04 and Fedora 38, both being the 38th releaso of each distro, but it was also the release party for cups-filters 2.x, as the 2 distros are the first ones using the new generation of cups-filters. There was a cake, one half with blue icing for Fedora and the other half with orange icing for Ubuntu, and the first cut was done together by Jiri Eischmann from Red Hat representing Fedora and Heather Ellsworth from Canonical representing Ubuntu. On Sunday I got interviewed by Keywan Tonekaboni from the German c't computer magazine. He wanted to know everything about my OpenPrinting work. It took 40 min, one time slot of talks, and afterwards I also sent him a longer e-mail with links to write-ups, News Posts, and conference videos. The main intention is an article about OpenPrinting in the magazine, but as Keywan has attended the conference, there is also a small news article (in German) about the LAS, also mentioning my OpenPrinting work in one paragraph. Some further interesting talks to mention: \"What’s next for the Linux App Ecosystem?\", Panel Discussion by Sriram Ramkrishna with Jason Evangelho (Thunderbird), Lubos Kocman (SUSE), Aleix Pol (KDE), Heather Ellsworth (Ubuntu/Canonical), Robert McQueen (GNOME), Felipe Borges (Fedora) \"Free & Open Source Software: Software Design For The Environment\" by Joseph P. De Veaugh-Geiss (KDE) \"GNOME Mobile Show & Tell\" by Jonas Dreßler (GNOME), Robert Mader (Collabora), and Tobias Bernard (GNOME) \"Snap performance optimization - The Firefox case study\" by Igor Ljubuncic (Canonical/Ubuntu) \"UnifiedPush - Push notifications for Linux\" by Volker Krause (KDE) \"Game development on Linux\" by Jesús Soto (Canonical/Ubuntu) \"We can’t spell BUGs without U\" by Heather Ellsworth (Canonical/Ubuntu) See also Mastodon, hash tags #LAS2023, #LinuxAppSummit, and #OpenPrinting. Update: Extra call for proposals (ends June 12) for BoFs and Workshops! Seems that they got an extra room for the weekend. GUADEC in Riga, Latvia, is approaching! Now the talks, workshops, and BoFs are selected and the schedules are available and my 2 proposals got accepted! The New Printing GUIs: GNOME Control Center and Common Print Dialog Backends Wed, July 26, 10:00 EEST, room 2 So right on the first day I will talk about the state of the art of the printing GUIs for the New Architecture, the \"Printers\" part of the GNOME Control Center and the Common Print Dialog Backends (CPDB) support in the print dialogs and will also demo the GUIs. Your app everywhere, just in a Snap! (Workshop) Sat, July 29, 12:30 EEST, room 2 This GUADEC will get snappy! In this 2-hour interactive workshop you will learn how to snap (= package as a Snap) your favourite applications! You will snap a simple GNOME application on your own laptop and after that we (me and Jesús Soto) will also help you to snap your applications. So if you have some free software application project and want to make it easily avcailable for your users, without them needing to compile, and without the goodwill of the maintainers of their distro, Snap is the right solution. This is distribution-independent, secure, and easy-to-use packaging, like on smartphones. More about Snap: The Powers, The People Note: Unfortunately, Heather Ellsworth is not able to attend GUADEC this year. Therefore Jesús Soto, also from the Canonical Desktop Team, replaces her as my co-speaker. I have already asked the organizers for updating the announcement of the workshop. Canonical/Ubuntu And as usual, I come with my colleagues, this time the Canonical Gang consists of Jeremy Bicha, Jesús Soto, Marco Trevisan, Mauro Gaspari, and me. There will be an orange Ubuntu booth again, as last year, a nice point to find us and to start interesting hallway sessions (Developers, not marketing people). And, in addition to my two sessions mentioned above, you will see my colleagues in these sessions: How GNOME Gets into Ubuntu by Jeremy Bicha Wed, July 26, 13:50 EEST, room 1 Jeremy's description: GNOME produces two major releases every year. Ubuntu also has two releases every year. In this talk, a longtime Ubuntu Desktop team member will discuss how GNOME features and bugfixes get into Ubuntu. Release Team BoF Sat, July 29, 12:30 EEST, room 1 This is a meeting of the GNOME Release Team, where Jeremy Bicha is member of. The site for the Ubuntu Summit 2023 is up! And it will take place in Riga, Latvia! Riga? Did we not have it already? Yes, the GUADEC will take place there, too, see above. So me and my colleagues from Canonical who attend GUADEC will visit Riga twice, experiencing it once in Summer and the second time in fall. And we will hopefully find some nice restaurants and bars to recommend to the rest of Canonical ... It will take place on the weekend between the two internal meetings of Canonical, the Roadmap/Product Sprint in the week before and the Engineering Sprint in the week after, so that Canonical employees having to attend the two Sprints are not away from their families for more than 2 weeks and many Canonical employees have no excuse to not be on the Summit ... So it takes place on Fri, Nov 3, 2PM EET to Sun, Nov 5, 6PM EET If you have something awesome to present on the Ubuntu Summit, please submit your abstract. The Call for Proposals (Update) opens on June 5 and ends on July 2. I will be in the organization team again and I am eager to see your submissions. Some weeks ago, Google has announced the slot counts assigned to each of the mentoring organizations and the accepted projects. Unfortunately, the Linux Foundation got only 12 slots for their 24 ranked proposals. This means that for OpenPrinting 6 of 10 ranked proposals got accepted. The accepted proposals for OpenPrinting are the following: OpenPrinting: CPDB support for application's print dialogs: Firefox, Chromium, LibreOffice
Contributor: Kushagra Sharma
Mentors: Till Kamppeter, Gaurav Guleria, Shivam Mishra, Rithvik Patibandla, Ira McDonald
See below and also test it! Sand-Boxed Scanner Application Framework
Contributor: Akarshan Kapoor
Mentors: Till Kamppeter, Rishabh Maheshwari, Deepak Patankar, Ira McDonald GNOME Control Center: List and handle IPP print services for the New Architecture
Contributor: Mohit Verma
Mentors: Till Kamppeter, Marek Kašík, Zdenek Dohnal, Rithvik Patibandla, Ira McDonald
Test it! Continuous Integration: Test Programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, CPDB Libs
Contributor: Pratyush Ranjan
Mentors: Till Kamppeter, Deepak Patankar, Zdenek Dohnal, Ira McDonald Adding support for the new functionality of IPP Everywhere 2.x to libcupsfilters and CPDB
Contributor: Gayatri Kapse
Mentors: Till Kamppeter, Rishabh Maheshwari, Zdenek Dohnal, Ira McDonald Native gutenprint Printer Application
Contributor: Yuvraj Aseri
Mentors: Till Kamppeter, Solomon Peachy, Rishabh Maheshwari, Chandresh Soni, Ira McDonald Some of the other candidates already told that they want to participate in OpenPrinting voluntarily, like for example fixing bugs. Our contributors already have started their work on their projects and provided short write-ups about what they have done in the recent weeks: Kushagra Sharma (CPDB support for Mozilla, Chromium, LibreOffice, see below and also test it!): Made a feature request for Chromium, Mozilla and LibreOffice for CPDB support.collaboration started with chromium dev team of CPDB support. Completed design documentation for better understanding of CPDB for upstream developers. In upcoming week I will be working with CPDB team at OpenPrinting to start the coding process to whichever development team agrees for adding CPDB support to existing print dialog. Akarshan Kapoor (Scanning with PAPPL): The very first task that I had to implement was regex parsing for scan jobs following the eSCL Protocol in the C language. The challenge? Unlike C++ or Python, C does not come equipped with built-in regex parsing libraries. However, I have managed to surmount this challenge at a file-independent level. (The merge with the local code base is still pending.) The eSCL Protocol, or the network scanning protocol, forms an integral part of scanning functionality. It utilizes HTTP and XML for communication between devices, thereby making it a vital feature for transmitting both scan jobs/requests and scan features. In the context of regex parsing, it was essential to comprehend and process XML responses effectively. To do this, I delved into the different XML responses outlined in the MOPRIA Scan Specifications. These specifications define the format of requests to be text/xml and interact with the appended directory functionality. This posed an intriguing challenge, and I'm eagerly anticipating tackling more of these during my Summer of Code with Google and with OpenPrinting. Mohit Verma (GNOME Control Center \"Printers\", test it!): I am working on the project of \"List and handle IPP print services for the New Architecture\". I have completed the work of listing _ipps-system._tcp, _ipp-system._tcp, _ipps._tcp & _ipp._tcp print services and currently working on grouping the services together & making the entire process for finding and listing print services asynchronous. I am working with TIll extensively and he keeps on providing me valuable insights about my work by checking out my G-C-C build whenever required. Gayatri Kapse (IPP Everywhere 2.0 support): I have figured out what \"functionality implementation I have to do in libcupsfilters and user interface enhancement in CPDB. In libcupsfilters, I will incorporate the new attributes and their functionality specified in IPP Everywhere 2.0, ensuring seamless interaction with printers. For CPDB, I will enhance the user interface to support and display the new attributes, creating an intuitive printing experience.\" Currently I am going through the ipp-support in cups and then after figuring out where to code, I will start writing the logic and start testing it. Yuvraj Aseri (Gutenprint Printer Application): I am working on native gutenprint printer application, Gutenprint is a package of high quality printer drivers for Linux, BSD, Solaris, Macintosh OS X, IRIX, and other UNIX-alike operating systems. I have completed the framework of printer application. I have gone through codebase of libgutenprint to add functionalities in the applications. Currently I am reading the source codebase of pappl-retrofit to understand how to integrate the libgutenprint into printer application. As every year, CUPS author Michael Sweet has presented his CUPS Plenary on the OpenPrinting Summit/PWG meeting. When I browsed through the slides before the actual presentation I already saw that the releases of CUPS 2.5.x were scheduled at the end of this year (page 8) and there were no release schedules at all for CUPS 3.x (page 11+). So I asked Mike about the CUPS 3.x release while he was giving his talk and he confirmed that the CUPS 3.x release is indeed pushed out by a year, meaning that the release will be end-2024. This especially also means that Ubuntu 24.04 LTS will come with CUPS 2.5.x instead of 3.x. But as we will switch from the Debian packages of CUPS to the CUPS Snap already in Ubuntu 23.10 anyway, the New Architecture will already be reality in 24.04 LTS. So we are still heavily working on the New Architecture! And when CUPS 3.x will finally make it into the distributions, the Printer Applications as replacement for the classic CUPS printer drivers will be well established so that we get a smooth transition into the new CUPS. Also we will be starting already to test the new libcups 3.x in the Printer Applications. they do not need anything from libcups which is removed from version 3.x, especially as the retro-fitting Printer Applications are using libppd. Now having the new cups-filters in the first 2 distros, Ubuntu 23.04 and Fedora 38, first bug reports started to appear: All PDFs when printed come out mirror image (Ubuntu bug #2018538) I asked for the queue's PPD file from the people who observed the bug but did not yet get an answer. cups-browsed is using an excessive amount of CPU (Ubuntu bug #2018504) I am not able to reproduce it by myself, but I got debug logs from one of the people suffering this bug. Need to investigate. Brother DCP-J125 not printing after update to cups-filer 2.0b3 & 2.0rc1 (libppd issue #20) Here I already did deeper investigations. It occurs for PPD files which require the print data to be turned into PostScript, either for a PostScript printer or for a proprietary printer driver (here from Brother) and if the printer stacks up the printed sheets face-up and therefore needs the jobs printed in reverse order. In this case the ppdFilterPSToPS() filter function is actually not outputting any print data due to a wrong function being used for the output. This was most probably introduced with the conversion of the pstops CUPS filter to the ppdFilterPSToPS() filter function. At too many places the regular puts()/printf() got replaced by doc_puts()/doc_printf() where actually just a fputs()/fprintf() to outputfd had been needed. PDFtoraster - Printout of image files (.JPEG, .PNG) are not properly aligned and cropped (cups-filters issue #529) Not yet started the investigations. I will try to fix these bugs before the final release, at least if I get enough cooperations by the reporters and who else claimed to have observed the bug. I will also update all the Snaps, the CUPS Snap and the Printer Application Snaps, to use the new cups-filters components and check whether they are still working correctly. If all this works well and any occuring bugs are fixed I will do the final release. After the release of 2.0rc1 some newly discovered bugs got already fixed: In libcupsfilters the filter function cfFilterPDFToPDF() failed to correctly flatten filled interactive PDF forms in some files, losing the entered data (Issue #28). With the flattening actually done by QPDF I asked Jay Berkenbilt, maintainer of QPDF, for help and he pointed me to QPDF issue #949 where the same problem was reported. Jay fixed the bug and released QPDF 11.4.0, which I tested and this indeed fixed the bug. So I updated the documentation appropriately. In cups-filters we got our first private security bug report. It was that the (very rarely used) beh backend, a wrapper backend to handle errors of the actual backend, called the actual backend with the system() function. And this function takes a command line as a single string and not the arguments as separate strings, so it is easy to inject arbitrary commands by a forged job title. This is fixed and published now and with this I learned how to handle security vulnerabilities as upstream organization. I also added some missing #include lines in the backend/parallel.c file of cups-filters. I discovered this when I prepared libcupsfilters for libcups3 support cleaning up some things in it. And in cups-browsed we have first switched to pkg-config from the deprecated cups-config and second, fixed a glitch in the build system (Issue #12). Central part of the OpenPrinting work in this year's GSoC is to make the printing-related GUIs working with the New Architecture. Mohit Verma is adding support for IPP print destinations and Printer Applications to the \"Printers\" module of the GNOME Control Center, while Gaurav Guleria has added CPDB support to the GTK print dialog and is adding it also to the Qt one. And Kushagra Sharma is adding CPDB support to application-specific print dialogs, for Firefox, Thunderbird, Chromium Browser, and LibreOffice. This code needs testing, not only by the mentors of the GSoC contributors, but by as many people as possible, and so that everyone can easily install the packages with the modifications for supporting the New Architecture, I have created a PPA (Personal Package Archive) with all the modified packages for Ubuntu 23.04 (Lunar Lobster) on the x86_64, arm64, and armhf architectures (most PCs, laptops, mobile devices, and single-board computers, like Raspberry Pi). So one can simply include the PPA in one's system as described and install the packages. This PPA will get updated frequently, so come back at any time and see the progress. In addition, the PPA helps to demo the development on conferences (see my talks on LAS 2023 and GUADEC 2023 above, slides) and I will also use it to present the work to Canonical's design team, so that they can try it out and optimize the UI design of the \"Printers\" module of GNOME Control Center. GNOME Control Center The test version of the \"Printers\" module of the GNOME Control Center (package gnome-control-center in the PPA) currently only covers the main view, the list of available print destinations, not the Printer Application support in the \"Add Printer\" dialog. In the main view you will see: All available IPP print services/destinations Network printers IPP-over-USB printers Printer Applications Permanent CUPS queues, created manually or created automatically by plugging a (classic) USB printer or by cups-browsed If an IPP device (most likely a Printer Application) has more than one print destination, the destinations are listed together. So you will see all print destinations where you can print to with CUPS, both classic CUPS queues and IPP destinations for which CUPS creates a temporary queue when printing to them. The menu opening when clicking the button to configure an entry differs whether we have a classic CUPS queue or an IPP destination. For the former you will have, as before, the possibilities to set default option settings, remove the queue, ..., but for the latter you will simply only have the possibility to enter the destination's web admin interface, as there is no local CUPS queue to configure, but you can configure the service by its web interface. Common Print Dialog Backends The Common Print Dialog Backends (CPDB) you can test on the standard print dialogs of GTK and Qt 6.x. The packages to install from the PPA are gtk4 and qt6-base resp. In addition, you also need to install cpdb-backend-cups and cpdb-backend-file. The components of cpdb-libs should get installed automatically. Most GNOME or GTK applications, like gnome-text-editor, use the standard GTK print dialog. So simply print from them (Ctrl + P) and you are testing the CPDB-based print dialog. For Qt, unfortunately, most applications available for Ubuntu 23.04 use Qt 5.x, and the CPDB support is only available on our test version of Qt 6.x. So you need to find applications using Qt 6.x by the following command: For example you could install focuswriter for the test. Do not be disappointed that the GUI of the print dialog is not cute, we did not change it for adding the CPDB support and it is the original from when CUPS support was introduced to Qt ~20 years ago. Note also that some applications, as far as I know currently, Firefox, Thunderbird, Chromium Browser, and LibreOffice have their own print dialogs. As long as these do not appear in my PPA, you should use the standard GTK print dialog by clicking the appropriate link or button inside the print dialogs of these applications. Also note that desktop applications installed as Snaps or Flatpaks do not use your system's libraries, especially not the GTK and Qt you have installed from my PPA, but on the other side they often use a print dialog provided by the running desktop environment instead of their own print dialogs, so that if you are running Ubuntu's standard GNOME (or another GTK-based desktop) and you get the standard GTK print dialog when you print from your application, you most probably have the CPDB-enabled one from my PPA. Test example Here is a step-by-step HOWTO to test the new GUIs: Stop cups-browsed (to not get permanent CUPS queues generated for each IPP print destination): Include the PPA in your package installation sources: Install the packages (and focuswriter as Qt 6.x example): For being able to test even without having a printer at hand, install cups-ipp-utils: and run the IPP printer emulator ippeveprinter: This emulates a color IPP printer with duplex capability which understands jobs in Apple Raster (URF) and PDF. Printing to it makes the input file being dropped in the /tmp directory, without any conversion (original URF or PDF file). DNS-SD service name is testprinter. Create a classic CUPS queue via If you have a printer, make it available in your local network and/or connect it via USB. If your printer is not a driverless IPP printer (or a driverless printer which can also be used the classic way, like PostScript for example), install the appropriate Printer Application: Open the web interface of the Printer Application (http://localhost:8000/) either using a web browser directly or finding the Printer Application in the destination list of the \"Printers\" module of GNOME Control Center, clicking its configure button (with a gear icon), and choosing \"Web Interface\" (see also below). Create a print queue using the \"Add Printer\" button in the web interface (under \"Printers\", top-right. Now run or, if you are using GNOME as your desktop, start it by clicking the gear button in the quick settings panel which you get when clicking the upper-right corner of your screen. Choose the \"Printers\" entry in the list on the left. In the main area you see a list of the print destinations now. At least you should have the testprinter which you have created with ippeveprinter and testclassic which you have created with lpadmin. If you are so lucky that you have a printer at hand, you will see more entries, especially the print queues which you had created before starting this test and also entries coming directly from the printer itself (if it is a driverless IPP printer) or from the Printer Application you have installed and set up. For the Printer Applications you do not only get an entry for each of your configured print destinations within it, but one extra entry for the Printer Application itself. This allows to see its presence and access its web interface already before adding the first printer to it, especially to do just this. You can try this also by installing a Printer Application even without having an appropriate printer. Now each destination has a button with a gear on it. This is the configure button. Click it, and you will see one of two types of a menu, either with four or five entries, like \"Printer Options\", \"Remove Printer\", ..., or with only one entry, \"Web Interface\". If you get the former, you have a classic CUPS queue, which as before, you configure locally using the functionality of GNOME Control Center. In case of the latter you have an IPP print service. There is no local configuration for it, but it has a web admin interface. Click on \"Web Interface\" to open it in your browser. There is nothing new on how to configure classic CUPS queues, so I will not elaborate on that here. In case of the web interfaces, a web interface is required by the IPP standards, therefore you even get one for ippeveprinter, not a very useful one, but there is one. By the web interfaces you see where the print destinations come from, you know the manufacturer's interfaces of network printers, and Printer Applications show the one of PAPPL (example HPLIP). And if you see the web interface of a network printer and the URL is http://localhost:60000/, then it is IPP-over-USB, you have connected a driverless IPP printer via USB. Note that there are still some glitches, especially GNOME Control Center gets blocked while creating the print destination list or groups of destinations from a Printer Application are not clearly marked, lead entries of Printer Applications are not marked as such, no fax-out queues listed, ... Now open applications and trigger their print functionality (Ctrl + P). The print dialog pops up. If it is a standard GTK print dialog you should see all print destinations which you have seen in GNOME Control Center. In case of a Qt print dialog, only if the application is using Qt 6.x. Run for example Select printers, set options, print ... This all should work. Note that options can be different between IPP services and classic CUPS queues for the same printer. If you print on testprinter grab your \"printouts\" in the /tmp directory. Opening the print dialogs must have started the CPDB backends. Run and you will see entries for each backend in the /usr/lib/*/print-backends/ directory. Kushagra Sharma got now accepted as GSoC contributor with his project of adding CPDB support to several application's print dialogs. He gets mentored by Gaurav Guleria and me and he has already started working on his project. I have found for him the places and people in the upstream organizations of Mozilla (Firefox/Thunderbird), Chromium, and LibreOffice, to propose the switch of the print dialog from direct CUPS support to CPDB. Currently, we have reached out with the following activities: I posted a Feature request for Mozilla already some weeks ago. First discussion has started. I posted on the mailing list for LibreOffice, after some IRC chat on #libreoffice-dev on Libera.Chat. I am in contact with Piotr Pawliczek and Benjamin Gordon from the Chromium Paper I/O team and, after getting an appropriate hint via the developer Google group, Kushagra has created a design document and posted a feature request for the CPDB support on Chromium's print dialog. Benjamin is aware of the feature request. Kushagra is currently studying the code of the print dialogs and also finding the best agreements with with the upstream developers on how to implement the CPDB support. a very important maintenance task for free-software organizations is to handle reports of security vulnerabilities. Generally all the development of a free software project is public. Changes, independent whether for new features or to fix bugs, are committed into public code repositories. And all the work towards them is discussed on public platformas, mailing lists, discussion forums, conferences. Reporting a security vulnerability on a public bug tracker is counter-productive though, as not only the developers supposed to fix the bug but also potential attackers can read them and get aware of the bug before it gets fixed and updates made available for all major OS distributions. So we get here into a situation where also free software developers have to keep something confidential. To avoid potential attackers to get aware of a security flaw, such bugs need to get reported in private and their publication be embargoed until the bug is fixed and the package maintainers of the distributions having gotten a reasonable period of time to apply the fix to their packages. This is the common practice between the upstream free software projects and the downstream OS distributions. Therefore most bug tracking systems ask the reporter of a bug whether it is a security issue, or whether the bug should be reported publicly or in private. We at OpenPrinting, and also many other free software organizations and individual developers, use GitHub as platform to host the code repositories and track our bugs. Unfortunately, in GitHub, if you start a new repository or a new organization, private bug reporting is not available by default. It is supported though, but it is not intuitive how to activate it and how to tell who of the organization should have access. Also it is no obvious how to make the OS distribution's maintainers or security teams aware of a received security bug report. This makes many developers just fix the bug and commit the fix ... I discovered some weeks ago, when I reported a (regular) bug on PAPPL, that when clicking the button to report a new issue, that an extra page appeared where I can choose whether my issue is a regular bug, a feature request, or a security vulnerability. Such a page did not appear when reporting a bug on any OpenPrinting reporsitory. So I investigated what is different, and found out that private security bug reports must be activated under the security settings and bug report templates to generate selection page for the report type must be created. I also told Mark Esler of Canonical's Security Team about that and he was very happy about having learned about this, as Canonical is using GitHub heavily, too. Once done so, I quickly received the first security issue. It was easy to fix the actual bug, and one could also request a CVE number easily by a simple click in GitHubs interface for private security bugs, but then I ran into the problem on how to inform all relevant OS distributions about this report. It came the time of the Canonical Engineering Sprint in Prague where all the engineers of Canonical (~700) meet in a huge hotel for a week, including the Security Team. So I took the opportunity and scheduled a meeting with the Security Team in their room, exactly with Mark Esler, Marc Deslauriers, and Seth Arnold. They gave me a 25-min HOWTO on how to proceed, posting the report and the patch on the appropriate mailing list where all the responsible persons of the distributiins are subscribed and setting the publication date/end of the embargo and at the end of the embargo, regardless whether all the distros have actually done the update, publish the report by committing/merging the fix and posting on a public list specialized for that. I suggested them to give a workshop or at least a 50-min talk on the upcoming Ubuntu Summit, to help the several upstream application developers who attend the conference. Mark told that it took him only 25 min to explain that to me, but then I told him that his explanation was a HOWTO for an experienced upstream developer/organization lead and downstream packager, but on the conference we need a tutorial for less experienced application developers ... And now the last challenge was to manage who in our OpenPrinting team will be able to access the security bug reports, without making all of them owners of the organization in GitHub. But this I found out rather quickly. One has to create a team in the GitHub organization and make it the security manager. Mark Esler has also reported the problem of needing to create templates for getting a button to report a security issue to GitHub and that got fixed, so now one only needs to activate private bug reports in the settings. And, on the day after my meeting with the security team on the Sprint, he gave a lightning talk about all this and mentioned me giving him the hint about security bug reporting support in GitHub. So what you have to do is the following: Activate security bug reports for a whole organization or account By default, private vulnerability reporting is not active at all. This makes your users hesitating to report security vulnerabilities or reporting them publicly, like regular bugs, and it also makes developers just committing the fixes of such bugs. At a rather hidden place in your account's (or your organization's) GitHub settings you can activate private bug reporting. We recommend to activate it to your whole account/organization and get it activated by default for new repositories in it. This way you avoid that any repository stays without coverage. In the following URLs replace XXX by your organization's (would be OpenPrinting for me) or your user name (tillkamppeter for me), depending on where you want to apply the changes. Go to your organization's/account's start page: and then click \"Settings\" near the top, to get onto the settings panel of your organization/account: Then click \"Code security and analysis\" under \"Security\" on the left: Under \"Private vulnerability reporting\" check \"Automatically enable for new public repositories\" to make sure all repositories added in the future accept security bug reports, and click \"Enable All\" to enable this functionality on all already existing repositories. Activate security bug reports for a single repository If you are maintaining a repository in an organization where you have no appropriate administrator rights for, or if you do not want to accept security bugs on all your repositories, you can activate them also only for a single repository. Please replace also YYY by the name of the repository, for example cpdb-libs. Go to your repository's start page: and then click \"Settings\" near the top, to get onto the settings panel of your repository: Then click \"Code security and analysis\" under \"Security\" on the left: Now click \"Enable\" for \"Private vulnerability reporting\" and then \"Save changes\" at the bottom of the page. Ready for receiving private security vulnerability reports Now, when a user wants to report a new issue, clicking on the \"New Issue\" button on your repository's issues page they get asked whether the issue should be a regular, public bug report or a private security vulnerability report. Note that owners of the repository do not get asked this, but there is an alternative way to start a security bug report, clicking \"Security\" at the top of the start page of a repository, landing at and then clicking \"Advisories\" under \"Reporting\" on the left, getting onto On this page there is a button \"New draft security advisory\". Click it to start a new private security bug report. If you have activated private bug reporting for your whole organization or account, this is valid for all your repositories. Allow access to everyone who needs it Security bug reports mentioned above are only accessible to the owners of your organization. This is most probably not everyone in your developer team who should have access, for example as they would be the right persons to fix these bugs. So you have to define the security managers for your organization. Go to the organization's start page again: and click \"Teams\" near the top: Create a team and add all the people who need to access the security bug reports of your organization. These are the core developers of your organization, but also could be the security people of the major OS distributions, ... You can add/invite more people at any time later. Now go back to the start page and click \"Settings\" and then \"Code security and analysis\" again. Scroll down to find \"Security managers\". Enter the name of your newly created team into the search bar and add the team. Now the members can do everything in the security bug reports, commenting, proposing patches, ... Handling a security vulnerability report Once having done all the setup, you will sooner or later get your first vulnerability report, probably the sooner, the more your project is an essential part of the operating system. You find all your vulnerability reports to each repository when you click \"Security\" at the top of the start page and then \"Advisories\" under \"Reporting\" on the left: It is expected that you do the whole procedure within three months after the original report. First, check if your organization's security team is under the \"Collaborators\". If not, add it. Enter its name into the search line and confirm its addition. Fix the bug, but do not commit the fix to the regular, public repository. If you need more info from the reporter, especially if they have not supplied steps to reproduce the bug, ask via comments on the report. Do not discuss the bug on public mailing lists or forums. You can also discuss the bug with your security team colleagues by means of comments in the private bug report. If the report is done by someone external to your organization, there will appear a section \"Accept vulnerability report\" near the bottom of the report. If you, perhaps after some first investigations and discussion in your team, believe that it is actually a security problem, click \"Accept and open as draft\" to accept the report. If you have accepted and fixed it, use the appropriate button in the security bug report to let GitHub request a CVE (Common Vulnerabilities and Exposures) number for you. With this the bug gets registered in the central CVE database. Once having gotten the CVE number go to \"Collaborate on a patch in private\" near the bottom of the bug report and click \"Start a temporary private fork\" to get a private fork of your repository. Follow the instructions under the then appearing \"Collaborate on a patch\" to clone the private fork of your repository. Apply your fix to your local copy of the fork, then commit and push it. Make sure to include the CVE number in the first line of the commit message, for example The title after the CVE number could be the title of the bug report, or a one-line description of the fix. Add more lines to explain your fix. \"git push\" your commit. Now you can discuss the fix with your team colleagues and with the original reporter, and they all can also clone the private fork to test the fix and/or apply additional changes. Once done the first push into the private fork, in the bug report there appears a button \"Compare & Pull Request\". Click this button to get a private pull request attached to the bug report. Next step is to inform the responsible people of the major OS distributions, usually package maintainers and security teams, about the bug and the fix and give them a time period of around 1 to 2 weeks to provide updates with the fix for their distributions. Only after this time period (the embargo) expires, you publish the bug report and the fix. For this there is a non-public mailing list with the right persons subscribed to it. So you do not need to know all these people to either mail to them individually or add them to your organization's security team. The e-mail address of the list is distros@vs.openwall.org (or linux-distros@vs.openwall.org if the bug is Linux-specific). Please respect the list's policy. The email subject must start with the four characters [vs] to bypass their weird anti-spam filtering measures. The subject should also contain the CVE number and a one-line description of the bug. The mail body should contain a description of the bug, instructions to reproduce or exploit, if available, a link to the bug report (not yet working for most of the readers), the planned date for the publication, and the patch to fix the bug should be attached to the e-mail. Simply copy and paste the appropriate text content from the bug report. For the publication date the maximum is 14 days from the date of sending the mail, 7-10 days are preferable. Make sure that at that date a team member is available to do the publication. On the day of publication, first merge the private pull request, so that the fix gets committed to your public repository. If you want, spin a release of your repository now. Then click the button at the bottom of your bug report to publish the report. Now everyone can access it. The link to the report which you have put into your e-mail will work for everyone from now on. Send another e-mail, now, to the public list oss-security@lists.openwall.com, with the same subject and body as your first e-mail, no attached patch required any more if you instead add a link to the appropriate commit (the one from merging the private pull request) in your public repository. You always publish a security bug on the publication day you have chosen in your first e-mail, regardless of whether all distributions provide updates in time. This way you do not make the publication dependent on a distribution not doing their duty and do not get stressed on that distributions do not provide their updates. It is in the full responsibility of each distribution not to be covered on the day of publication. Now you are done with the security bug. This is at least what I did on our first security report. Thanks a lot to Mark Esler, Marc Deslauriers, and Seth Arnold from Canonical's Security Team for guiding me through handling security bug reports as upstream organization and for reporting to GitHub the need of creating templates to make security bug reporting possible in the regular issue reporting process. And thanks to the GitHub folks to quickly fix this."
+ },
+ {
+ "id": "post:OpenPrinting-News-May-2024",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - May 2024",
+ "url": "/OpenPrinting-News-May-2024",
+ "headings": [
+ "OpenPrinting Summit/PWG Meeting",
+ "GUADEC 2024 in Denver",
+ "aKademy 2024",
+ "UbuCon Asia 2024 in India",
+ "Google Summer of Code 2024",
+ "CPDB CUPS backend Snap",
+ "Open Documentation Academy"
+ ],
+ "tags": [],
+ "snippet": "20 Years!! CUPS 3.x postponed to mid-2025, OpenPrinting Summit/PWG Meeting, GUADEC 2024, aKademy 2024, UbuCon Asia 2024, GSoC 2024, CPDB Snap, Open Documentation Academy",
+ "content": "This year is the 20th anniversary! The 20th anniversary? Of what? Of Ubuntu! Its first version 4.10 got released in October 2004. Of Canonical! The company behind Ubuntu. It got founded earlier in 2004. Of the Google Summer of Code! This year's edition is the 20th. Of Thunderbird! The famous e-mail clinet. Its 1.0 got released in December 2004. Of OpenWrt! Embedded operating system for routers. Started back in January 2004. And ... ... I got married in 2004, a really magic year. And I was already working with free software, but not aware of all these great things which happened in that year. This month we had our annual OpenPrinting Summit/PWG Meeting again, and, as usual Michael Sweet was reporting about the state of the art of CUPS, with an updated time line. Unfortunatly, things do not go as fast as thought about and therefore the sharing server, as the last component of CUPS 3.x to be released will only be ready mid-2025, in 1 year from now. And this is the date which marks when distros can switch over to CUPS 3.x, so that for Ubuntu the switchover will only happen in 25.10. Do you want to learn how to package software in the Snap package format? Most probably you will not look for resources here on OpenPrinting then, but rather at snapcraft.io. I had already talked about this with Graham Morrison, Snap documentation lead at Canonical, on the Ubuntu Summit last November and now, finally, after meeting him again on the Canonical-internal Engineering Sprint this month, I have created a page about the Snap workshops on snapcraft.io: Learn snapping! - Interactive Snap Workshops I will keep this page up to date with new workshops, updates of the existing workshops, announcements of next chances to attend in person ... So let us see what happened at OpenPrinting in May ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat On May 6-8 we had our annual meeting together with the PWG (Printer Working Group) again, the OpenPrinting Summit/PWG Meeting. The meeting was online again, as most of the participants were not able/willing to travel. All slides are available via links in the schedules. The first half of the meeting was dedicated to OpenPrinting, the second half to the PWG, mainly the development of the Internet Printing Protocol (IPP). In the OpenPrinting part there was no Ghostscript session again. Since having gotten acquired by ePapyrus Artifex has reduced the development activity on Ghostscript a lot and so there were only bug fixes. We used the time again for other topics, this year especially about desktop integration and software distribution methods (Snap, OCI). Most important session was Michael Sweet's CUPS plenary, where he always gives estimated timelines of the upcomimg releases of CUPS. Unfortuntaly, these do not match the last ones, presented on the Opportunity Open Source in September last year. The final 3.0.0 releases of the components are now estimated as follows: libcups3: August/September 2024 cups-local: February/March 2025 cups-sharing: April/May 2025 This means a further delay of another ~6 months. Note that for an integration in Linux distributions all the 3 components need to be available. It would be awkward to have a desktop distribution using the local server of CUPS 3.0.0 (with libcups3) and if a user wants to share their printers they have to install CUPS 2.x (with libcups2) and somehow the interaction between the CUPS 2.x daemon and the local server of CUPS 3.x has to get managed. libcups3 could get into use more quickly, for example in Snaps or OCI container images of Printer Applications. We had also 2 short talks by our GSoC contributors this year. Akarshan Kapoor has presented his work about scanning support in PAPPL and Rudra Pratap Singh his planned GSoC project of OCI containerization of CUPS and Printer Applications. There will be written up summaries of the event in the coming weeks. I will post links to them as soon as they get available. The next GUADEC is approaching! This year it will take place in Denver, Colorado, USA, on July 19-24! As usual it will consist of talks on the first 3 days, then workshops and BoFs for 2 days and to complete it, 1 day-trip day. The Call for Proposals has closed some weeks ago and the talks are already selected and scheduled, but not yet the workshops and BoFs. As in the previous years I will be there with a Canonical Gang, this time Ken VanDine, Marco Trevisan, Jeremy Bicha, and Aaron Prisk. And we all will meet our former colleague Heather Ellsworth (had moved on to Thunderbird last year). Living in Colorado Springs, one hour from Denver, this GUADEC is practically a home game for her (and she was actually involved in this location selection). I had also submitted 3 proposals. The Snap workshop and a talk about the Google Summer of Code got rejected, but my talk about Snap and Ubuntu Core Desktop will take place. It is Snap and Ubuntu Core Desktop - Desktop Linux, as easy as a smartphone! Fri, July 19, 15:15 MDT, Room 250 Turnhalle (Track 1) This talk is about Snap and the all-Snap desktop Linux distribution Ubuntu Core Desktop, how all this works, the motivations, advantages, challenges, and state-of-the-art ... I submitted the proposal for a 40-min slot, to allow for a generous Q&A, like Ken VanDine had on SCaLE (directly to Q&A), but unfortunately, I got only 25 min, as I got for this talk when I gave it on FOSDEM. As Ken is also on this conference, he will be most probably with me in the room and help answering questions. This year will be the first time that I attend the aKademy, KDE's annual conference! This is to raise awareness of the New Architecture for printing also under the KDE folks. Also they need to update their printing support, both in the printer setup tool and the print dialog, to allow for distros to switch to CUPS 3.x. The dialog got already done by Gaurav Guleria adding CPDB support and the KDE developer Mike Noe is on the KDE Print Manager, but to be sure it is better to let the wider KDE developer community know ... For that I have submitted a talk proposal to tell what the New Architecture is all about, what it requires from the GUIs, and the state-of-the-art of KDE's work on supporting it. Another point is that I will, together with my colleague Alex Lowe from Canonical, make the conference snappy. For that Alex has submitted a short (10 min) talk about \"why a [KDE] developer might want to release their software as a Snap\" and I have submitted my talk \"Desktop Linux, as easy as a smartphone! Just in a Snap!\" based on the one which I already have given on FOSDEM, but also telling about the state-of-the-art of KDE desktop session Snaps (which could make up a Kubuntu Core Desktop) if there are ones by the time of the conference. There was no CfP for workshops yet, but as soon as submissions for workshops open, Alex and me, we will submit my initial Snap workshop \"Your app everywhere, just in a Snap!\" but as a KDE edition. Alex will make KDE-based examples/exercises for that. I could also submit the workshop about Snap update automation in addition, to make the \"SnapKademy\" complete ... By the way, the aKademy 2024 takes place on September 7-12 in Würzburg, in Germany. As I already told in March I am working on a second edition of the Opportunity Open Source in India. Having again another conference in India, this time the UbuCon Asia in Jaipur on Aug 31 - Sep 2 (Sat - Mon) I am planning to run the Opportunity Open Source on Aug 23 - 25 (Fri - Sun), and most probably in the IIT Kanpur, and this way attend two conferences on one trip. Therefore I have submitted several talk proposals and got 2 sessions accepted: Desktop Linux, as easy as a smartphone! Just in a Snap! Sat, August 31, 11:35 AM IST, Main Hall The motivation, advantages, and concept of the sandboxed, immutable Snap packaging format is shown and how it is used to make up immutable all-Snap OS distros, the IoT distro Snap was originally designed for, Ubuntu Core, and the easily usable and maintainable Ubuntu Core Desktop. Your app everywhere - Just in a Snap! - Interactive Workshop Sun, September 1, 1:55 PM IST, Room 2 Interactive workshop to learn how to package applications in the sandboxed, immutable package format Snap to publish them in the Snap Store. Attendees will create simple Snaps in several hands-on exercises. Full schedules Special thanks to Youngbin Han from the Ubuntu Korea community and Ubuntu LoCo Council, who is leading the organization of the conference, for his great support. Lat week, the official coding period has started. Some of the contributors have started to work on their projects already earlier, others had their final exams for this semester in the last weeks and therefore are starting only now. I have created group chats on Telegram for each project to ease the communications between the mentors, the contributors and me. The OpenPrinting channel on Telegram is for general discussion and for my announcements. I have also taken care that there are mentors for everybody and I do not have to do all the mentoring by myself. And I have started to ask the contributors for write-ups for the OpenPrinting News, and several have written some lines: Packaging CUPS and Printer Apps into OCI images
Contributor: Rudra Pratap Singh This month, I have concentrated on deepening my knowledge by studying the Rockcraft documentation. Looking ahead, my next objective is to develop a production-ready CUPS container. To achieve automation in this endeavor, I am thoroughly reviewing the codebase of the ubuntu/desktop-snap project. My goal is to leverage their existing work to implement automated versioning and dependency updates for our container images. Additionally, I have successfully developed a Dockerfile for CUPS, enabling remote access from the host system to the CUPS instance within the container using the cupsctl --remote-admin command. Have a look at the github repository http://github.com/Rudra-IITM/cups-docker CPDB support for the LibreOffice print dialog
Contributor: Biswadeep Purkayastha This month I worked on the remaining part for the CPDB Snap. I finished making the necessary changes for filtering the printer list completely by the frontends and not by sending signals to the backends, and submitted a PR for the same. I am currently working on facilitating adding new backends while the frontend dialog is open. I am working closely with Till on this and hope to finish it as soon as possible to ensure everything is ready for the CPDB Snap. With respect to GSOC, I have finished setting up the development environment for LibreOffice, and am currently going through the code of the previous OpenPrinting contributor's work on the print dialog of LibreOffice. Biswadeep still mostly worked on the snappability of the CPDB backends, but finished the needed changes now (see below). Now he has started on his actual GSoC project. Integrating C-based OpenPrinting Projects in OSS-Fuzz Testing
Contributor: Jiongchi Yu Enhancing OpenPrinting's Security with OSS-Fuzz Integration Most of OpenPrinting's projects are predominantly written in C, which are prone to encounter memory violation bugs, and lack advanced testing methods like fuzzing. OSS-Fuzz, a well-recognized initiative for identifying vulnerabilities in open-source projects, is now being leveraged to bolster the security of C-based projects under OpenPrinting. This strategic integration aims to continuously detect and report potential threats. The current phase of integrating CUPS with OSS-Fuzz is primarily dedicated to rigorous validation and testing. Our approach involves developing fuzzing harnesses grounded on previously identified CVE vulnerabilities and refining existing unit testing framework into a more robust fuzzing infrastructure. This initial integration serves as a foundational step in our broader strategy to enhance the resilience of OpenPrinting’s projects through comprehensive fuzz testing. PAPPL API Bridging for Scanner Applications
Contributor: Akarshan Kapoor My work was focused on developing the API for the Scanner object and Driver Interface, with an initial task to finalise the structure of scan APIs within the scanner and scanner-private header files. Key achievements include developing the Scan API object based on the Printer API object, tailored to eSCL scanning needs. I also updated the PAPPL job API object to accommodate both print and scan jobs by adding a reference to the scan object. Additionally, I created the scan driver API, modelled after the print driver APIs, but with callback functions and without support for vendor-specific options to align with PAPPL eSCL scanning protocols. Similarly, the options API structure was updated based on printer options and also excludes vendor options. The scanner headers for the public and private APIs were introduced, each with appropriately named header guard macros, patterned after their printer counterparts. Currently, I am enhancing the accessors file to provide accessor functions for the scanner object, following the format established in the printer accessor functions. Desktop Integration: Update system-config-printer for the New Architecture of printing
Contributor: Shivam Jaiswal Here's the latest on my project: Understanding System Config Printer: I've been studying the current code and functions of system-config-printer to understand how it works. This helps me see what needs to be changed for the new architecture. Switching to the New Architecture: To update CUPS for the new architecture, we will need to change some existing functions in system-config-printer. This will make sure everything works well together. Understanding IPP Services: I've been reading about the IPP (Internet Printing Protocol) services that system-config-printer needs to use. This is important for making the necessary updates. Talking with My Mentor: I had a discussion with my mentor, Mohit Verma, who gave me an overview of how to start the project and suggested some functions I might need to write. His advice is helping me plan the updates. Next Steps: Right now, I'm focused on understanding the existing functions in system-config-printer. Next, I'll figure out and add the new functions needed for the new architecture. User interfaces for using OAuth2 with printers and scanners
Contributor: Shivam Sharma User interface for using OAuth2 with printers and scanners This project is all about providing authentication support to the printers and scanners which can help us to save the client's files. I had figured the idea about adding this functionality to the print dialogs. The CPDB does not have authentication support, which may cause threat to client's data. It is important to use an authentication server and for this I am using GNOME online accounts (GOA). I had a discussion with GOA for using their server for authentication and it can be used to create or add an account which client needs to initiate for the authentication. To proceed with it setting up D-Bus communication, querying GOA for OAuth2 tokens. To use GOA as authentication server, the installation of few libraries are required such as 'libgoa-1.0-dev' for GOA and 'libdbus-1-dev' for D-Bus communication. Unfortunately, we did not get write-ups from everyone. Several have been deeply in their exams these days. Especially Arun Patwa (Braille) and Ankit Pal Singh (Gutenprint) have graduated. Congratulations to them! Biswadeep Purkayastha is volunteering on snapping the CPDB backend for CUPS since the end of last year and we ran into several problems, especially as we have to do with user daemons now and the frontend browses available D-Bus services to find all installed backends. Discussion on the snapcraft.io forum led to the need of some changes in the architecture of the Common Print Dialog Backends (CPDB) infrastructure and Biswadeep has done them all now! Thanks again, Biswadeep, for your great work! The changes are: The printFile method of backends passes the job data as stream via a domain socket now, not as file specified by a file path The D-Bus methods getActiveJobsCount, getAllJobs, and cancelJob got removed from CPDB The file backend of CPDB cannot be used. We decided to discontinue its development and will use it for development and documentation only Filtering of the printer list in the dialog is now done by D-Bus methods in the backend's D-Bus service and not any more by the frontend also being a D-Bus service and sending signals By a background thread the coming and going of backends is monitored and the printer list in the dialog appropriately updated Biswadeep provided the changes via the following Pull Requests which got all merged now: cpdb-libs: Pull Request for (1) and (2) (merged), Pull Request for (4) and (5) (merged) cpdb-backend-cups: Pull Request for (1) and (2) (merged), Pull Request for (4) (merged) I have posted the news on the thread in snapcraft.io and snapd developers Zygmunt Krynicki and James Henstridge are looking into how to proceed with the snapping. See also our coverage here in the October News, the November News, and the March News. OpenPrinting needs contributors for documentation urgently. Especially we have no documentation for the APIs of libcupsfilters, libppd, pappl-retrofit, and cpdb-libs. Finding contributors for documentation is not easy, Google Summer of Code is only for code contributions, Google Season of Docs is not suitable for us as we would have to hire the technical writer, and finding people just volunteering i tried, even some telling they would do, but they did not do in the end ... Now another chance came up for us: Recently Canonical has started the new \"Open Documentation Academy\" program and this seems to be a good way to find volunteer documentation writers. Central point of it is a GitHub repository, where organizations can post their documentation needs as issues, so volunteer writers can browse the issues and find documentation tasks they like to do. I have already posted one issue as an example, it is for API documentation of libcupsfilters. Here is the original on our GitHub and a manual copy at the Open Documentation Academy. This is a little awkward and several feature requests for improvements got posted. First idea was automatic copying of documentation issues, but this would need explicit permission from Canonical's IS team (they are owner of the https://github.com/canonical/ organization on GitHub). Then I brought in the ideas of registration and self-presentation of participating organizations and of listing documentation-related issues directly from their tracker. And the Open Documentation Academy is not only finding together organization's documentation needs and voluntary writers, but they support the writers with a lot of resources: Discussion forum, Weekly Office Hours (live discussion, recording on YouTube), Chat on Matrix, mentoring, guiding, ... We will post more documentation tasks in the list and hopefully will have a better presentation of ourselves and of our tasks in the program soon. Thanks Graham Morrison for this great initiative!"
+ },
+ {
+ "id": "post:OpenPrinting-News-November-2019",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - November 2019",
+ "url": "/OpenPrinting-News-November-2019",
+ "headings": [
+ "Google Code-In 2019",
+ "Google Summer of Code 2019",
+ "Google Summer of Code 2020",
+ "Future work of OpenPrinting: Printer/Scanner Applications and IPP System Service",
+ "Avahi local service support",
+ "OpenPrinting web site",
+ "CUPS",
+ "cups-filters",
+ "ippusbxd"
+ ],
+ "tags": [],
+ "snippet": "The Linux Foundation applied for Google Code-In 2019 but did not get selected, future work of OpenPrinting should concentrate in Printer/Scanner Applications and IPP System Service, CUPS 2.3.x in Ubuntu 20.04 LTS (Focal Fossa), cups-filters 1.25.11, for ippusbxd David Valleau will look into allowing classic USB access in parallel",
+ "content": "Aveek Basu and Till Kamppeter have conducted an application for the Linux Foundation as mentoring organization in the Google Code-In 2019 and, unfortunately, did not get selected. A web page got set up for the application, containing sample tasks of several work groups of the Linux Foundation, including many of OpenPrinting. The web page will stay available as a start for an application next year. We try to find out why we did not get selected but have no results yet. Till Kamppeter and Aveek Basu have attended the Mentor Summit in Munich on October 17-20, 2019. They have presented a lightning talk about the success of the students working for OpenPrinting and also a held a session to discuss current OpenPrinting work. We need to start with the student selection process soon, so that we can let them do assignments to compensate for the missed Google Code-In opportunity. We need to concentrate on Printer/Scanner Applications and IPP System Service from know on. This is urgently needed as Michael Sweet (Apple?) plans to drop PPD file support in CUPS 2.4.x (next cycle, ~1 year from now), at least according to the warning message which one gets from lpadmin when one creates a print queue with PPD file (-P or -m option, except -m everywhere). This is a substantial change in the printing architecture on Posix-style operating systems. Especially we need to create libraries to allow easy creation of Printer/Scanner Applications. They should provide: Acquisition of a port on localhost (or on all network interfaces for sharing). Managing the port numbers in a useful way. DNS-SD advertising of the services (printer, scanner, fax, config interfaces, ...) IPP server: Answering all types of requests and calling functions to do the needed interactions with the printer/scanner and the application-internal printer/scanner capability data. Processing and filtering the incoming job data: Printer Applications will take PDF and raster formats as input and convert to the printer's native format. Functionality of the filters in cups-filters should be moved into a library, to be available as API functions. Legacy interface functions: For filters/PPDs and for SANE drivers. Communication with printers and scanners, functionality of the CUPS backends. IPP System Service as a server, to allow configuration of the Printer/Scanner Application via an external GUI (IPP System Service client). Then there can even be a Printer Application for a legacy printer which cannot be auto-discovered in the network. The application starts only providing IPP System Service. As soon as the user has entered the printer's IP address via the configuration interface, the application connects to the printer and starts to offer IPP print service. Perhaps also a web server for legacy clients. Then commodity functions of the library for building up a configuration interface should add each interface element to both the IPP System Service server and the web server. IPP System Service as a client, for GUI (and also CLI) apps to configure IPP printers and also Printer/Scanner Applications. This will be a central part of printer setup tools in the future. For testing this we should create a native Printer Application from Gutenprint for example, or one for PostScript printers for which we have PPD files. We also should create a native Scanner Application wrapping SANE with its current driver collection. Additional things to do: Turn cups-browsed into a Printer Application: Instead of creating a local CUPS queue for a printer cluster emulate an IPP printer which prints to the cluster (and local CUPS picks it up automatically, but how to prevent local CUPS from seeing the member printers directly?). We can also pick up legacy CUPS broadcasts (or BrowsePoll from legacy servers) and provide these printers as IPP printers. Configuration of cups-browsed then also via IPP System Service. Overtake PPD support API functions and pstops filter as soon as they get dropped from CUPS, for legacy support in Printer Aplications and cups-browsed. SANE driver for IPP scanners, so that applications accessing scanners via SANE can also access IPP scanners and Scanner Applications. Documentation/Community reach-out: Design guidelines for printer and scanner drivers as Printer/Scanner Applications, instructions to do this with our new libraries. As soon as SANE is wrapped into Scanner Applications, move GUI developers to base their scan frontends on IPP scanning and not SANE any more. No further progress this month. We urgently need the localhost support for the Printer/Scanner Applications, as PPD support will go away within a year. We need to go through the new site now and look for things which are still missing or need improving. Please report any issue here. No further release. The development cycle of Ubuntu 20.04 LTS (Focal Fossa) has started and CUPS 2.3.0 is now synced into Ubuntu from Debian, meaning that 20.04 will be released with CUPS 2.3.x. The lpadmin command issues a warning message telling that PPD support will get removed in the next CUPS cycle (2.4.x) when one creates a print queue with PPD file (-P or -m option, except -m everywhere). Therefore we need to get Printer Applications working by then. Currently released is 1.25.11. Many releases happened during the short time to get bug fixes into Ubuntu 19.10 (Eoan), which was released on Thu, Oct 17. The upcomimg 1.25.12 release contains many fixes on the pdftops filter, especially to solve problems with grayscale jobs when Poppler is used as PDF renderer. These jobs print now reliably but can come out in color on color printers. To assure that grayscale printing on color PostScript printers works correctly, use Ghostscript or MuPDF (these are able to convert color to grayscale). See Issue #169. 1.25.12 also builds with no compiler warnings now (tested on Ubuntu 19.10). 1.25.11: Bug fix release for cups-browsed working correctly with legacy (IPP 1.1) remote printers 1.25.10: Bug fix release for a bug making cups-browsed crash 1.25.9: Important bug fix release, fixes infinite recursion in cups-browsed! DO NOT use 1.25.8! 1.25.8: Bug fix release, especially to solve problems with cups-browsed connecting to older IPP printers/servers and for compatibility with Ghostscript 9.27+ David Valleau from Chrome OS/Google cotributed some minor fixes. Thanks to him for this contribution. An important problem of ippusbxd is that while it is running, the printer is exclusively accessible via IPP-over-USB. Classic USB access in parallel (or at least when there is no ongoing IPP communication) is not possible. This makes the use of ippusbxd on multi-function devices awkward, as IPP-over-USB currently only works with printing and not with scanning, due to the fact that manufacturers did not adopt the driverless IPP scanning standard of the PWG yet (Issue #9). David Valleau will look into implementing this."
+ },
+ {
+ "id": "post:OpenPrinting-News-November-2020",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - November 2020",
+ "url": "/OpenPrinting-News-November-2020",
+ "headings": [
+ "Lexmark second manufacturer (after HP) to certify IPP Everywhere printers",
+ "Google Summer of Code 2021",
+ "Google Season of Docs 2020",
+ "Linux Foundation Mentorship Program",
+ "PAPPL first beta release",
+ "PostScript Printer Application",
+ "CUPS",
+ "cups-filters"
+ ],
+ "tags": [],
+ "snippet": "PAPPL first beta, PostScript Printer Application, GSoC 2021, GSoD, LFMP, CUPS fork in Debian, cups-filters",
+ "content": "The days (months?, years?) of only HP being present on the PWG's certified IPP Everywhere printers list are counted. Lexmark has entered as second manufacturer, registering 92 IPP Everywhere v1.1 printers and with this the first v1.1 certifications at all. The total amount of printers in the list is currently 625. We are currently looking for project ideas for next year's Google Summer of Code. As mentioned last month student projects will only be half the timr (6 weeks). Google tells that this will probably attract more students, but for us it is a much higher workload as we have to find the double amount of students and get the double amount of students introduced and up to speed to get the same work done. For larger project we should also consider to run them under the Linux Foundation Mentoring Program instead of GSoC. Our OpenPrinting project is continuing well. Most pages of Piyush Goyal's project are already populated, merely only the scanning part is missing as its coding in our LFMP project is not yet completed. Next steps for the time being until IPP Scan gets far enough for being documented is to check whether everything is correct, recent API changes in PAPPL taken into account, design of existing Printer Applications, like the HP PCL and the PostScript Printer Applications explained, ... Our second LFMP project about IPP Scan is going on, with both Abhik Chakraborty and Rishabh Arya woring on the IPP Scan server/Scanner Application. Abhik is introducing Rishabh into PAPPL and the IPP server work. Mentoring will be mainly done by Michael Sweet. PAPPL made it to its first beta release, 1.0b1! So now it takes more or less the shape for the first stable release, having mostly the features and functionality needed to create printer driver packages in the new Printer Application format. 1.0 will not yet have scanning support. This will come in a later release. The devlopment of the PostScript Printer Application is going on and the application's TODO items get less. To fulfill IPP Everywhere requirements printing of PWG/Apple Raster input is streaming now, using PAPPL's built in Raster filter and raster callback functions to generate the PostScript for the printer, with the PPD's PostScript code snippets for the option settings inserted. Streaming instead of spooling means that the printing does not only start when the Printer Application has sucked in the whole job, but continuously picks up input data, filters it, and sends it off to the printer, raster line by raster line and as soon as the printer has enough data to print something it prints, in PostScript on completion of each page. This is less resource-consuming for large jobs and even would permit infinite jobs. Also printing of JPEG and PNG images uses PAPPL's internal image filter now, but PDF and PostScript input is handled by the appropriate filter functions of cups-filters. The creation of the PPD file list (currently we use ~4000 PPD files) was optimized to get the printer model names sorted in a human-friendly way (HP LaserJet 4, HP LaserJet 5, HP LaserJet 4000, HP LaserJet 5000 and not HP LaserJet 4, HP LaserJet 4000, HP LaserJet 5, HP LaserJet 5000) and to easily match the printer's device IDs with the PPD files even if the PPD file does not contain the device ID. Also the driver names for PAPPL's command line interface and config file are stable against changes in the PPD list, like the order or adding/removing some PPDs. My work on the PostScript Printer Application as the first non-Raster, retro-fitting, and many printers supporting Printer Application also has exercised PAPPL a lot and made me posting several bug reports (partially with patches) and feature requests on PAPPL and most of them Michael Sweet has fixed/implemented. Here are the most recent ones: Provide device ID to driver callback (Milestone for 1.0) Web interface: Button/Link to return to printer's main page from printer's config pages, also show print queue name on the config pages (Fixed) When printing colored PNG image in gray the image does not get correctly converted (Fixed) When printing an image with \"print-scaling=fill\" the image is not blown to fully fill the page but printed as with \"print-scaling=auto\" (Fixed) When printing JPG image with Printer Application the Printer Application crashes (Fixed) With PWG/Apple Raster input papplJobCreatePrintOptions() is called with num_pages = 0, clobbering the Duplex default setting (Fixed) Add tolerance to rounding errors when sending Apple/PWG Raster (Fixed) PAPPL-based Printer Applications do not DNS-SD-advertise their printers (Fixed) When printing to a network printer host name does not get resolved from device URI, job falls into infinite, uninterruptable (Fixed) Web interface: One can set Borderless Media, but setting not displayed (Fixed) More to be seen under the currently open and closed issues of PAPPL. Currently released is 2.3.3. On our fork of CUPS on OpenPrinting Didier Raboud (\"OdyX\"), maintainer of the printing packages on Debian, has posted pull requests for most of Debian's (and so also Ubuntu's) distribution patches and Michael Sweet has merged most of these pull requests so that future packaging will work without this \"patch hell\". First GIT snapshots got already packaged and released on Debian Experimental. Michael Sweet has also merged several other pull requests and fixed bugs which got originally reported to the original repository at Apple and there not taken care of. Here is the new CHANGES-OPENPRINTING.md of the fork: Currently released is 1.28.5. On the way towards 2.0.0 and driven by the further development of the PostScript Printer Application I have added the following new features: Moved IEEE1284-device-ID-related functions into the public API of libcupsfilters, also made the internal functions public and renamed them all to ieee1284...(), moved test1284 to cupsfilters/ Extended ieee1284NormalizeMakeAndModel() to a universal function to clean up and normalize make/model strings (also device IDs) to get human-readable, machine-readable, or easily sortable make/model strings Added filterPOpen() and filterPClose() functions which similar to popen() and pclose() create a file descriptor which either takes data to feed into a filter function or provides data coming out of a filter function. In cupsRasterParseIPPOptions() (called from filter functions used without PPD file) improved understanding of color mode options. Options \"output-mode\", \"OutputMode\", \"print-color-mode\", and choices \"auto\", \"color\", \"auto-monochrome\", \"process-monochrome\", and \"bi-level\" are supported now and default color mode is RGB 8-bit color and not 1-bit grayscale."
+ },
+ {
+ "id": "post:OpenPrinting-News-November-2021",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - November 2021",
+ "url": "/OpenPrinting-News-November-2021",
+ "headings": [
+ "Google Summer of Code 2022",
+ "Practically all free printer drivers in Printer Applications",
+ "Your driver not in a Printer Application? - The Legacy Printer Application",
+ "Printer querying on the OpenPrinting web server",
+ "pappl-retrofit - The CUPS Driver Retro-Fit Library",
+ "Ghostscript Printer Application",
+ "CUPS-driver-retro-fitting Printer Applications",
+ "CUPS Snap",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "Google Summer of Code 2022, all free drivers in Printer Application Snaps, Legacy Printer Application, CUPS 2.4rc1, PAPPL 1.1b3",
+ "content": "On November 5 the virtual Mentor Summit of GSoC 2021 has taken place and there the organization team of the GSoCs at Google has announced that we will have a GSoC again in 2022! But this time, for the 18th year, there will be several changes: Contributors, not only students: From now on it is not required any more to be a university/college student any more to code for GSoC. Anyone 18 years olde and older can do. Two project sizes: 16 GSoCs with ~350-hour projects, then one with ~175-hour ptojects, some tasks fit better into one size others into the other, no one-size-fits-all. Now we can have both. The organizations can select from these two sizes for each project idea they offer. Coding period flexibility: Before, there was a fixed time period of ~3 months in which the projects had to be done, also with fixed dates for the 2 or 3 evaluations. From 2022 on the period can be extended to 22 weeks on agreement between mentor and contrbutor, should there be some interruptions like exams, trips, sickness, different dates of mid-year break, ... This gives more people the chance to be able to participate. Now we have much more flexibility in defining projects and in selecting candidates, so much better chances in getting our projects done and finding more long-term contributors. Any suggestions for GSoC projects are welcome. We will start looking around for candidates and pre-selecting soon. Now we are an important step closer to using the CUPS Snap as the standard printing system and generally to use a CUPS which does not support PPDs and printers drivers (like 3.x): All free software printer drivers which are available in Debian packages (for Debian and Ubuntu) are now also available in Printer Application Snaps, so with the CUPS Snap and any future CUPS version there is no loss of printer support. There are four Printer Applications with nearly every driver in the Snap Store: PostScript Printer Application (Snap Store): Printer Application Snap for PostScript printers which are supported by the manufacturer's PPD files. User can add PPD files if the needed one is not included or outdated. HPLIP Printer Application (Snap Store): HPLIP in a Printer Application Snap. Supports nearly every HP printer ever made. Installing HP's proprietary plugin (needed for a few printers) into the Snap is supported and easily done with the web interface, and it gets automatically updated. Gutenprint Printer Application (Snap Store): High quality output and a lot of knobs to adjust, especially for Epson and Canon inkjets but also for many other printers, for example dye sublimation photo printers, in a Printer Application Snap. Ghostscript Printer Application (Snap Store): Printer Application with Ghostscript and many other drivers, for practically all free-software-supported printers which are not PostScript and not supported by HPLIP or Gutenprint. It contains all the printer for which there is no separate Snap. In addition, there is LPrint which supports many label printers (more label printer models supported by the Ghostscript Printer Application): LPrint (Snap Store): Supports Dymo LabelWriter and Zebra ZPL label printers, with all label-printer-typical options: Label modes, tear-off offsets, media tracking, media top offset, print darkness, resolution, roll selection, speed, ... Note that this is of the pre-PAPPL era and so does not use PAPPL with all its features. If there are any free software CUPS printer drivers left which are not in these Printer Applications and you think it would be great to have it there, please report an issue on the Ghostscript Printer Application. If you have manufacturer-supplied PostScript printer PPDs which are published under a free software license but not included in the PostScript Printer Application, please report an issue. For non-free-licensed PPD files simply install the PostScript Printer Application and use the \"Add PPD file\" functionality in its web interface to install your printers's PPD locally. If your printer still needs a driver which does not exist in any of the above-mentioned Printer Applications but is available for classic installation on your system (RPM or DEB packages, source code, ...) you can make your driver available in a Printer Application by installing the Legacy Printer Application. It is a part of the pappl-retrofit package and it makes drivers classically installed for the system's classically installed CUPS available in a Printer Application and this way for the CUPS Snap and any non-driver-supporting CUPS in the future. Note that this Printer Application cannot be put into a Snap and has to be classically installed instead, as otherwise it would not have access to your classically installed driver. This is especially of help for proprietary drivers for legacy printers, which are not updated any more by the manufacturers and so will not get converted to Printer Applications. Important for making printing \"just work\" for users is an ideally fully automatic setup of the printer. For driverless IPP printers (AirPrint, IPP Everywhere, Mopria, Wi-Fi Direct Print) this is no problem, they get auto-discovered by CUPS and made available as virtual, temporary print queues. Non-driverless printers which need a driver would need a way to get the correct Printer Application downloaded and installed. So a printer setup tool would need to discover the non-driverless printers, get their device IDs and send a query to somewhere to get as answer which Printer Application to install. The first idea for this was to get hardware-signature-based search added to the Snap Store, and an appropriate feature request got already posted, but after suggesting it near 2 years ago there seemed to be not much interest on that. And if one would try to revive the idea, it can still take rather long until it gets actually implemented. So I am looking into another approach: For years we could query printers and which drivers support them by the OpenPrinting web server, only that we usually only got told about which upstream source project supports the printer, not ready-to-use packages. Here we could improve and update to get what we want. The server allows human access (Printers page -> select printer make/model -> HP LaseJet 4050 -> select driver -> HPLIP) and also machine access: https://openprinting.org/query.php?type=printer&make=HP https://openprinting.org/query.php?type=printer&make=HP&model=HP-LaserJet_4050 https://openprinting.org/query.php?type=printer&make=HP&model=HP-LaserJet_4050&moreinfo=1 https://openprinting.org/query.php?type=printer&printer=MFG:HP;MDL:LaserJet%204050;&moreinfo=1 https://openprinting.org/query.php?type=driver&make=HP&model=HP-LaserJet_4050 The answers are in plain text (optionally XML, by adding &format=xml to the URLs). What we need is that this system tells about the Printer Applications to use not simply the drivers. A first approach I have already added to the human access interface: The driver pages, at least the ones of drivers which are contained in one of the 4 Printer Applications from OpenPrinting, contain a prominent link to the appropriate Printer Application. For example see the entries of HPLIP, Gutenprint, pxlcolor, hl7x0, Ricoh PostScript. Now one could think about adding all printers and drivers supported by the printer applications to the Foomatic database (the database behind the lookup system shown here). Probablem is that there are very many printers (~10000). Even if one creates a script to make this automatic it is very awkward. The human access interface gets a lot of \"boring\" entries, only carrying make and model names and driver relationships, no comments and no support quality info. In addition, we can run into scalability issues, getting the system, or the pre-build of PPDs very slow. We also would need to add a field for the Printer Applications into the database somewhere. And we need to update everything whenever we modify one of the Printer Applications. So I will try another concept: I will use the Printer Applications themselves and not a database derived from them to answer the queries. If you have a single Printer Application, you can find out whether it supports a given printer by simply querying it with the device ID of the printer: There will be no answer if the given printer is not supported, and if it is supported, one gets an answer like this: This is the internal driver name of the Printer Application for this printer, a human-readable description (the one which you also see in the web interface of the Printer Application), and the device ID as it is registered for this printer in the Printer Application. You see now that the device ID in our query does not match the device ID in the Printer Application. The one in the Printer Application is most probably the actual one of the printers, as it comes from HP's PPD file of the printer, which is included in the Printer Application Snap and the one in the command line simply comes from the top of my head (many years ago I worked in the office of Mandriva in Paris, and the daily-work network printer, and also subject of many tests by me, was an HP LaserJet 4050). Here we see that there is a fuzzy matching between the device IDs. This helps us to also do manual searches (user enters make and model names) and we also can match printers from which we do not know the exact device ID, but at least make and model as written on the printer's case. What I plan to do with this is to install all the Printer Applications (as most modern printers are driverless IPP there should not appear too many Printer Applications) from the Snap Store on the OpenPrinting web server, stop their daemons (the query works without the daemon), and let the auto-update mechanism of snapd and the Snap Store keep them always up-to-date. Now we extend the script behind the machine access interface (query.php) to allow querying all Printer Applications for a given printer. It would make a script like this being run (this is simplified a lot): Running it with 'MFG:HP;MDL:LaserJet 4050;' as argument results in: So all the 4 Printer Applications support it. Such an answer is naturally rare in real life, but it can easily happen with a standard laser printer supporting all the common PDLs, like PostScript, PCL 5e, and PCL-XL. So we will need to prioritize so that we can return the answers in desirability order. We will first check whether the manufacturer name in the answer is \"Generic\" and in that case only give a very low priority, as it is a generic match, for example by the PDLs in the \"CMD:\" field of the device ID. Results which contain the actual model name get higher priority. If this does not lead to a \"best\" answer, we will also prioritize between the Printer Applications. For example if it has manufacturer-supplied drivers it will get preferred, also more sophisticated drivers are preferred against simpler drivers. This will lead to the following priority order of our 4 Printer Applications: HPLIP PostScript Gutenprint Ghostscript HPLIP is a manufacturer's driver, PostScript is a collection of manufacturer-supplied PostScript PPDs, Gutenprint is a sophisticated, high-output-quality driver, and Ghostscript contains many simple, generic drivers for PCL and PostScript printers which are better supported by the other Printer Applications. So our querying printer setup tool would set up our HP LaserJet 4050 with the HPLIP Printer Application (and with this it will be used in PostScript mode). Most importantly the Test Printer Application included with pappl-retrofit, originally thought as a programming example and to test drivers whether they work in a Printer Application, was renamed to Legacy Printer Application as it serves also for making classically installed CUPS drivers available in a Printer Application. So one can install it on a system using the CUPS Snap to make available the classically installed printer drivers. So it can be used on production systems to support older, often proprietary drivers which did not get converted to Printer Applications (see also above). To make the new Legacy Printer Application pweform as best as possible we assure now that it never runs the driverless utility as PPD generator/backend if it is installed, as it does not make sense to support driverless IPP printers with a Printer Application, we create PPDs on-the-fly from *.drv files, and we use only CUPS backends for best compatibility with the drivers (side-/back-channel support, ...). The PAPPL backends can be used for testing by building with ./configure --enable-pappl-backends-for-legacy-printer-app. For streaming Raster or image jobs to PDF printers we make use of Ghostscript's new PDF Image and PCLm output devices now. the streaming got fixed in Ghostscript 9.55. This way printing on PDF printers needs less client resources and also some printers could start to print the job alreasy before all the job data is transferred (commit). With the conversion of the bannertopdf CUPS filter into a filter function in libcupsfilters (see below) we can now use a PDF-based dynamic test page. In contrary to the former bannertopdf CUPS filter the banner instruction file and the PDF template/background file can be joined into one, to ease the implementation of the Printer Application. When running in debug logging mode we now save a copy of the job data which goes to the printer (commit). The retro-fitting library has also received many fixes and improvements during the work on the 4 Printer Applications, especially for correctly listing the supported printer models in a user-friendly way, reliably auto-assigning the correct driver/model to a discovered printer, and also to prevent crashes: When setting up the driver verify and correct default resolution, especially the default resolution saved in the state file can get invalid if the driver is removed from the Printer Application and another one auto-selected. This causes crashes on shutdown (commit). Use device ID as display string (for \"Add Printer\") only if manufacturer matches (commit) On driver setup skip media sources/types/sizes without PWG name to avoid crashes (commit). When generating the driver list, never use a single \"*Product\" entry in the PPD file, as this entry is either the model name from the \"*NickName\" or something weird (commit) On driver setup corrected loop to go through the \"*cupsFilter(2)\" lines of the PPD, as only the first line got actually used (commit) Let system setup set the CUPS_SERVERBIN environment variable, as some CUPS filters rely on it (commit) Further development of the library will go with the development of PAPPL and the needs of the Printer Applications. Especially the following features will get implemented/supported as soon as they are implemented/fixed in PAPPL: Support for scanning. Needs support in PAPPL (Bhavna Kosta's GSoC project). Support for string/text-style vendor options. Needs support in PAPPL (Patch already applied in the Printer Application Snaps). Human-readable strings for vendor options. Needs support in PAPPL. Ink level check via ps_status() function. Needs support in PAPPL. Ghostscript Printer Application in the Snap Store I Added all the small, old, and mostly unmaintained printer drivers (Debian packages printer-driver-..., see output of \"apt search printer-driver-\" in Debian or Ubuntu distributions) to the Snap. This avoids cluttering the Snap Store with tons of Printer Applications, makes maintenance easier, especially less Printer Applications to rebuild after a change in the infrastructure (PAPPL, libcups, cups-filters, pappl-retrofit, Ghostscript, …), and less infrastructure overhead on the user’s machine if he has more than one printer. The drivers added are c2050, cjet, min12xxw, pnm2ppa, hpijs (non-HP PCL lasers only), c2esp, dymo-cups-drivers, foo2zjs, fxlinuxprint, m2300w, oki, pxljr, rastertosag-gdi, splix, brlaser, and ptouch-driver. I used the Debian source code of the drivers to get Debian's patches to fit the old code to the current systems and to fix the bugs, but I built the drivers by myself in the Snap to not pull in their dependencies (old Ubuntu 20.04 packages of the full printing stack including cupsd). With this and the 3 other driver-retro-fitting Printer Applications all printer drivers available in Debian packages are now also available in Printer Applications. I also make use of libppd’s *.drv file support in the Snap (commit) as several drivers use this format instead of actual PPD files or a PPD-file-generating executable and so we do not need to pre-build the PPD files. Also I discovered that the pdftops CUPS filter (needed by foomatic-rip for drivers which accept only PostScript) was missing and added it (it is actually only a little stub to call the pdftops() filter function in libcupsfilters). I did further testing, optimizing, and debugging on listing the supported printers and finding the best support for a given printer, both whether a Printer Application supports the printer at all and if so, which driver is the best. Listing and checking is fast and reliable now and it should be possible to do it on the OpenPrinting web server (see above). The Snaps of the 4 Printer Application also got some general improvements: Make use of libppd’s *.drv support in the Snaps (commit) More precise determination of files to include in the Snaps in snapcraft.yaml (commit) Patched dnssd CUPS backend in the Snaps to only report JetDirect/Port 9100 and not IPP or LPD, to avoid discovery of driverless IPP printers including other Printer Applications (commit) Switched to the PDF-based dynamic test page (commit) Corrected passing of arguments in the startup scripts for the Snaps, to make it possible to pass printer device IDs to the -o device-id=... option, needed for checking support of a given printer (see above, commit) CUPS Snap in the Snap Store I am still waiting for the snapd team to implement the security concept on the snapd side, but now we have progress here. Most of the changes requested in the snapd Pull Request got implemented and I got asked to do a second real-life test of the current state of snapd. Everything is working as intended and the results of the test I have reported in the Pull Request. Together with the fact that we have practically all free software printer drivers in Printer Applications now we are very shortly before being able to use the CUPS Snap as standard printing system in Linux distributions, like Ubuntu 22.04 (Jammy Jellyfish). Main TODOs are: Complete the security concept on the snapd side, especially implement the content interfaces (see above) Testing Add a migration script so that OS distributions can easily switch over from classic packages to the CUPS Snap From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|3138| |ipp-usb|ipp-usb|621| |ps-printer-app|PostScript Printer Application|1798| |ghostscript-printer-app|Ghostscript Printer Application|516| |hplip-printer-app|HPLIP Printer Application|1859| |gutenprint-printer-app|Gutenprint Printer Application|1004| Currently released is 2.4rc1. This is a release candidate for the first feature release of CUPS on OpenPrinting. Thanks to Zdenek Dohnal (RedHat) for having taken the role of the release manager for the CUPS 2.4.x series. Ubuntu Jammy Jellyfish (22.04 LTS) will come with CUPS 2.4.x, if all works well as Snap. The CUPS Snap and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master of CUPS. Ongoing discussion Feature Request: Implement printer profiles (Issue #207) Zdenek Dohnal (RedHat) writes: This issue is a placeholder for implementing printer profiles, which are needed for the case: CUPS temporary queues work only with LAN located devices, because the tech uses mDNS for device discovery. However, this situation isn't usually a case for enterprises, where their IT engineers tend to put printers into a separate VLAN - they do it because of security and monitoring. Without any migration plan, these use cases would be left behind if permanent queues are gone and CUPS temporary queues become the only technology in CUPS. The idea of printer profiles was introduced by Mike Sweet during email communication within OpenPrinting group and distro maintainers and presented during PWG F2F meetups. In good progress: Remove print filters and printer driver support (Issue #103) Here I have especially reported that we have most drivers in Printer Applications now. 2.4rc1 CUPS 2.4rc1 is a release candidate for OpenPrinting CUPS 2.4.0, which adds some further enhancements before the stable release. 2.4b1 CUPS 2.4b1 is the beta release for OpenPrinting CUPS 2.4 which contains several new features such as basic OAuth support, support for AirPrint and Mopria clients and support for running CUPS as a snap, several deprecations (Kerberos, cups-config), removals of old deprecated configuration file directives, and many bug fixes. Currently released is 1.28.10. In cups-filters we are getting closer to the 2.0 release. All filters which are not printer drivers are now converted to filter functions and the universal filter function is also added. Also all PPD-handling code from CUPS is moved into cups-filters to allow retro-fitting of drivers also after CUPS has dropped PPD file support. Several minor bug fixes and improvements got initiated by the work on adding the old, unmaintained printer drivers to the Ghostscript Printer Application. Now mainly clean-up is needed. Merged Pranshu Kharkwal's Pull Request for adding a universal filter function and CUPS filter to replace the chain of individual CUPS filters. Also did the build system integration for the new filter to easily choose between the universal filter executable or individual filter executables. Now all GSoC 2021 projects on cups-filters are merged. Ported CUPS’ PPD compiler (ppdc) into libppd (commit 1, commit 2, commit 3). This way also classic CUPS drivers using /usr/share/cups/drv/*.drv files instead of physical PPDs can get straightforwardly encapsulated into Printer Applications with pappl-retrofit now. So all PPD handling functionality of CUPS is ported to cups-filters now and all types of classic CUPS printer drivers can get easily converted to Printer Applications. Improved bannertopdf() filter function to integrate in pappl-retrofit more easily, to allow PDF-based dynamic test pages, easier to customize for the specific Printer Applications, no need of a PostScript interpreter (commit). Dropped support for CUPS < 2.2.2 and QPDF < 10.3.2 from cups-filters 2.x. Removed the obsolete urftopdf CUPS filter, as libcups supports Apple Raster already for some years now. Fixed bugs in the texttopdf() filter function which got discovered when developing the universal filter function. In pwgtoraster() with PPD do not modify the Raster header via IPP options (commit). Parse device IDs with spaces correctly (commit). Allow specifying CUPS filter/backend executable without full path in the filterExternalCUPS() filter function (commit). Let filterExternalCUPS() return 1 if filter is terminated by a signal (commit). Added \"FXOutputMode\" of Fuji Xerox to auto-mapping IPP attributes to PPD option settings (commit). Useful \"*Product:\" entries in the PCL-XL PPDs (commit). Removed “series” from printer model names when normalizing them to make it easier to search for support for a given printer (commit). Ubuntu Jammy Jellyfish (22.04 LTS) will most probably come with cups-filters 2.x. The CUPS Snap currently uses 1.28.10. The Printer Application Snaps use the current GIT master of cups-filters. Currently released is 1.1b3. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher. After this release only changes for Windows compatibility got added. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-November-2022",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - November 2022",
+ "url": "/OpenPrinting-News-November-2022",
+ "headings": [
+ "The first Ubuntu Summit was a success!!",
+ "The making-of",
+ "And the conference finally started ...",
+ "Thanks",
+ "OpenPrinting Micro-Conference on Linux Plumbers 2022 - The recordings",
+ "Google Summer of Code 2023",
+ "Google Summer of Code 2022",
+ "cups-filters Second Generation - First Beta Release!",
+ "Getting Cute - New UI for the Qt print dialog",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "teaserImage": "/assets/images/brachiograph/master-of-the-brachiograph.jpg",
+ "snippet": "Ubuntu Summit 2022, OpenPrinting micro-conference recordings, GSoC 2023 announced, GSoC 2022 results, cups-filters 2nd gen. 1st beta release, Qt print dialog, CUPS, PAPPL",
+ "content": "You all probably know that OpenPrinting is all about reproducing graphical content from a computer on paper or similar flat surfaces. The hardware to do this contains more or less sophisticated mechanics to precisely position pixels on the surface of the output media. And this hardware is usually only affordable because it is produced in an industrial mass-production process and because its ink or toner refills are expensive ... Did you already think about why one does not construct a machine which puts the ink onto the paper like a human being, with an arm and a pen? Some kind of hand-writing machine, controlled by a computer? Have you perhaps already thought about building such a machine by yourself, from simple, cheap parts, much cheaper than the cheapest available printer? Did you already think about a huge conference hotel where you find free refills in each guest room and even more in the meeting rooms? On the first Ubuntu Summit in Prague this got reality: Daniele Procida, Canonical's Engineering Director for Documentation, is the creator of the Brachiograph (Ancient Greek: \"Brachio\" = arm, \"Graph\" = writer -> arm writer), a plotter made from a Raspberry Pi, 3 servos, and some household/office items, worth a total of ~12.50 EUR. He demoed the device at first on Monday and on Tuesday, it was the attendee's turn to build this device, in a 90-min interactive workshop. Originally Daniele only submitted the 25-min demo session to the Call for Proposals, but when I was reviewing submissions (I was in the organization committee of the Summit) and found his proposal I immediately contacted him, suggesting him to also submit a workshop, where attendees can actually build this device, and Daniele liked my suggestion and submitted the workshop. So I wrote another nice, positve review ... and got able to build such a plotter myself! So the workshop has taken place and I was so lucky that it was not to the same time as any of the 4 sessions where I was speaker/host of, so I actually attended it: Master of the Brachiograph
Daniele Procida, master of the Brachiograph, explaining the wiring Shoulder and material
The shoulder motor is already mounted on the base board, the other parts you see on the left Forearm
The assembled forearm, with elbow motor on the left, clothes peg to hold the pen on the right, and wrist motor (pen up/down) at the top Assembling
Putting it all together: Here the forearm gets fitted to the elbow Calibration
The motors are wired to the Raspberry Pi now and the plotter gets calibrated with the help of a template sheet Plotting a photo
And finally, photos turn into pieces of art!! The software running on the Raspberry Pi which controls it is completely written in Python and includes everything needed, especially also the functionality for calibration of the device and for converting raster images/photos into a line plot. Unfortunately, it does not contain a CUPS driver or even a Printer Application, but the simple mechanics, flex, non-linearity of the servos, hysteresis, and the fact that it is not able to plot straight horizontal or vertical lines, probably leave not enough precision anyway to plot things like normal-sized text in readable quality anyway ... Nevertheless it is an ineresting experience seeing this device plotting pictures and what it makes out of a photo is some kind of art ... And it is a low-budget first experience with robotics, not needing any expensive/sophisticated equipment, workshops, engineering skills ... All details you find on Daniele's web site, and as Daniele is Canonical's master of documentation it is all well described and easily understandable (and you see that it follows Daniele's Diataxis principle). Update: Recordings of most of the sessions are on YouTube. Unfortunately there were problems with the A/V in the breakout rooms (Karlin 1-4) on the first day and we could only use the recordings of 4 sessions there, from the ballroom we have recordings of all sessions. From the other days we could provide the recordings of all sessions. Note that we did not record the workshops, as they were highly interactive and watching them after the fact does not make much sense. Now I am back from Prague after 5 days of the Canonical-internal Engineering Sprint and 3 days of the Ubuntu Summit. All the hard work I had with it, promoting it, participating in its organization, creating and organizing the Snap tutorial workshop series, and preparing my 4 sessions really worked out and we ended up with an awesome conference! Back in March in Frankfurt, one Engineering Sprint earlier (Canonical does it twice a year, once per Ubuntu release), Ken VanDine (head of Canonical's Desktop Team, as long on GNOME as me on printing) gave a 5-min lightning talk announcing that, 10 years after the great era of Ubuntu Development Summits (UDS) ended, we are returning to have a conference with the community, this time calling it Ubuntu Summit (as there are more than only developers contributing). In that time the Summit was planned to be held in Vienna, Austria. I was already planning to go to the Linux Application Summit (LAS) in Rovereto, Italy to give a talk about the New Architecture and what needs to be done for it in the desktop environments. And as I am living in Vienna (so it had been a home game for me) I came to the idea to announce it on the LAS (Ken did not go there), the first time on a publicly accessible conference. A few weeks after Frankfurt Canonical's plans changed and Sprint and Summit were moved to Prague, but once formed my idea of the announcement I stayed with it and gave a 10-min lightning talk, an enhanced version of Ken's original one. Mid-July, 2 weeks before this year's GUADEC we formed the organization team for the Summit and had our very first team meeting via Google Meet. Mauro Gaspari from Canonical's Community Team was leading the organization and I was also in the team. Mauro was interested in my OpenPrinting work and conference and community experience with it and also in my UDS experience and asked me for staying in the line after the meeting. This led us to 3:30-hour 1:1 conversation (and for Mauro living in Taiwan it was midnight to 3:30am). I especially liked that the conference got as one of its session formats interactive workshops where the audience does exercises on their own laptops. So I ended up giving the ideas of doing a Snap tutorial workshop series with intro panel session, but also an OpenPrinting Community panel session, and a lightning talk about saving legacy printers on Windows via WSL. And all these ideas I turned into reality. So we all started reviewing submissions like hell, and I also started organizing the Snap tutorial workshop series. First I created some nice titles, for the whole thingie \"Your application everywhere, just in a Snap!\", for the starter tutorial (given by Heather Ellsworth, nick \"hellsworth\") \"Snapping like hell(sworth)\", and for my workshop \"Daemon Snapper's Workshop\". Then I had to line up teams, once the speakers for the workshops and second, the panelists for the Indaba-like intro, and in the end colleagues got tired of my inquiries on our internal chat channel of the Desktop Team ... And probably the organizers did not originally plan to pro-actively design sessions and sub-conferences and then search for speakers for them ... And my participation in the organization had also some nice side effects and by-products. Once asking around for workshop speakers in the community I asked Frederik Feichtmeier whether he would do the one about snapping Flutter apps. He declined as he is not into snapping, but picked up on the workshop idea and submitted \"How to build an Ubuntu Flutter Desktop App like LEGO\". Together with the actual snapping-Flutter workshop and another Flutter workshop independently submitted I \"accidentally\" created a Flutter workshop series ... And I have initiated the \"Let's build a pen-plotter\" workshop, too ... (see above). So I was the initiator of 6 workshops on the conference and I by myself was supposed to be on stage with 4 sessions (Snap intro panel, \"Daemon Snapper's Workshop\", OpenPrinting Community panel, WSL lightning talk) and this created a nice puzzle game for Philipp Kewisch, community manager at Canonical, who scheduled all the sessions, having to take care to have everything in the right order and no one of the speakers having to be cut apart to give two sessions at the same time ... For the OpenPrinting Community panel (\"OpenPrinting - Join the team to make printing just work!\") I also wanted to line up Aveek Basu (OpenPrinting Program Manager) and one or another GSoC mentor/contributor from India, but they were not able to obtain a Schengen visa to visit Prague. But fortunately, during the aftermath of this year's GSoC, I found out that Deepak Patankar, one of the mentors (and GSoC contributor 2018), moved to Amsterdam 2 months before the Summit, and so being in the EU already can freely travel to Prague! So I immediatly asked him whether he would like to come and I asked the organizers whether Canonical would pay, all 10 days before the Summit started, and all worked out and he joined the panel in-person! And Aveek could participate remotely. E-mail threads pre-interviewing the guests of both panel sessions to find out about what they will tell more or less and also discussing the flow of the sessions followed. Finally travelling to Prague I had the opportunity to meet all my colleagues already a week before the Summit on the Engineering Sprint. Usually serving for planning the next Ubuntu release, Lunar Lobster (23.04), the Sprint was for me mostly doing the final preparations for the Summit ... Especially worried about hosting panel sessions for the first time I had a working lunch with Heather Ellsworth, master of the Indabas, Mauro, and Philipp, and I also had a pre-meeting with the panelists of the Snap intro. I also had a meeting with all the speakers of the Snap workshops to coordinate the workshop content. Even the non-Canonical participants joined the meetings by Google Meet. And having brought along my tripod and my external webcam for these pre-meetings I was also able to enhance the November Ubuntu Desktop Team Indaba (about the Ubuntu release process) which was held in-person on the Sprint. Instead of the 4 participants sitting next to each other in the same room looking into the built-in webcams of each one's laptop, making up 4 frames with the same background, I have put the tripod with the external webcam in front of the 4, connected it to Heather's laptop, and so we have all the 4 in one single frame, conveying the in-person character of the Indaba! Playlist of all recordings on YouTube. Update: Impressions of the event: The Aftermovie! On the Sunday before the conference, in the morning, Deepak arrived and I had a walk through Prague with him and in the evening then we all met on the pre-conference reception in the rooftop bar of the hotel, finally getting together with all the friends and (former) colleagues from the Linux community, including those I have given a nice review for their submission and those I have lined up for the Snap series. And you remember me writing here three months ago about Heather Ellsworth introducing me to others back in 2019 (\"This is Till, making printing just work, on ...\")? Now she introduced me to Cassidy Blaede: This is Till, he makes printing just work, on any platform. On Monday, in the opening plenary by Philipp Kewisch and Mark Shuttleworth (recording on YouTube) my lightning talk about saving legacy printers under Windows was prominently mentioned but there was no mention at all of my Snap tutorial workshop series! Really a bug! So after Oliver Grawert's plenary talk \"An Ubuntu for a 10 ton steel press and your window shades, UbuntuCore at a glance\" (recording on YouTube), at the end of its Q&A, I grabbed the mic and shouted out my tutorial track. Was it not part of my work in Canonical's Desktop Team to fix bugs? Your app everywhere, just in a Snap!: On the Indaba-like intro panel (recording on YouTube) there were not only me as the host and Heather Ellsworth, Ken Vandine, Sergio Schvezov, Dani Llewellyn, and Graham Morrison as the invited guests, but Gustavo Niemeyer and Zygmunt Krynicki entered the panel as surprise guests, with Gustavo having originally declined my invitation to be on the panel due to the fact that he was not much involved in Snap any more. The conversation was going by itself and I did not need to ask much. The room was rather full during the session, in contrary to what I am used to on printing-related sessions on conferences. So my first panel session with me as the host was a success. The Snap tutorial workshops: After the intro panel there were 5 workshops taking place throughout the conference to learn snapping (packaging applications as Snaps). Those who never snapped in their lives were supposed to attend one of \"Snapping like hell(sworth)\" or the robotics/IoT-oriented \"Robotics and IoT deployment with snaps Workshop\" and those having attended one of these or already having basic snapping knowledge could attend the advanced workshops \"Daemon Snapper's Workshop\", \"Snapping desktop applications\", and \"Deploying Flutter apps on Linux Desktop\". The workshops are not just longer talks, they are interactive, attendees do exercises and examples on their own laptops. Unfortunately, in some tutorials attendees had problems setting up their systems, mainly due to the fact that everyone has another operating systen on their machines, but otherwise all was working fine. We should better have used the OS container/VM launcher Workshops for the workshops. Daemon Snapper's Workshop: My workshop which I did together with Sergio Cazzolato from Canonical's snapd team, was all about snapping daemons/system services. With my experience on snapping CUPS, ipp-usb, and Printer Applications I have decided that I give this workshop. I organized most of the workshop, creating its content and slide deck and Sergio coded the exercises based on my idea to create a super-simple daemon just receiving raw data on a network port and dropping it into a file, like a network printer listening for raw job data on port 9100 (on GitHub: Exercise, Completed). It was a success. The room was full and it seems that the attendees had the required pre-knowledge and also set up their systems appropriately, so that they could do the exercises right away. We also got some help on answering questions from Heather Ellsworth and Zygmunt Krynicki being in the room at least during a part of the time. OpenPrinting Community Panel on Ubuntu Summit 2022: After having a pre-meeting in-person Monday night on the Summit with Zdenek Dohnal from Red Hat and last-minute guest Deepak Patankar the session itself took place on Wednesday, an Indaba-like panel (recording on YouTube) with me as the host and Zdenek Dohnal (Red Hat/OpenPrinting), Johannes Meixner (SUSE), and Deepak Patankar (OpenPrinting) as in-person guests and Aveek Basu (OpenPrinting) as remote guest. Unfortunately, it had only low attendance but people liked it, especially Oliver Smith, Product Manager Ubuntu Desktop, participated well in the discussion and also Liam Proven from The Register was there. Save Legacy Printers under Windows with WSL and Printer Applications on Ubuntu Summit 2022: My lightning talk (slides, recording on YouTube) about Carlos Nihelton's OpenPrinting HOWTO to save legacy printers was perhaps the greatest success of all my 4 sessions. Many people came up to me praising this idea and it also got an article in The Register by Liam Proven! Also Craig Loewen from Microsoft attended it and liked the idea a lot! At the end of the talk I called Carlos Nihelton and Dani Llewellyn onto the stage to express my special thanks to them. Yes, we are sustainable! I also met a lot of people from the community, often old friends and colleagues, attended many great sessions, by Oliver Grawert about Ubuntu Core and Snap (recording on YouTube), by Craig Loewen from Microsoft about WSL (recording on YouTube), the production of a podcast (recording on YouTube, the published podcast) by the Linux Lads (they took my e-mail address for a possible OpenPrinting episode), playing with Mini Pupper, the little four-legged robot, building a pen plotter (see above) ... And especially I had a cute hallway session with KDE developer Harald Sitter and he wants to improve the user interface of the Qt print dialog. See below ... And I met Martin Wimpress (Ubuntu Mate, former head of the Canonical Desktop Team) and learned about his project to create an Ubuntu flavor named \"Butterfly\", with an all-Flutter desktop ... Thanks a lot to Mark Shuttleworth to initiate the revival of the Ubuntu Developer Summits as the new Ubuntu Summit. Thanks to Ken VanDine to promote this project. Thanks a lot to Mauro Gaspari, Philipp Kewisch, Heather Ellsworth, Igor Ljubuncic, Nathan Haines, Oliver Smith, Adam Szopa, Sarah Craddock, Claire Newman, and others for organizing this great Summit!! Thanks a lot to Mauro Gaspari to have the 3:30-hour 1:1 meeting with me to exchange ideas about what to do on the Summit. Thanks to Heather Ellsworth, Ken VanDine, Sergio Schvezov, Dani Llewellyn, Graham Morrison, Gustavo Niemeyer, and Zygmunt Krynicki to be my guests on my Snap intro panel. Thanks to Heather Ellsworth, Dani Llewellyn, Guillaume Beuzeboc, Sergio Cazzolato, Olivier Tilloy, Scarlett Moore, and Carlos Nihelton for being the speakers on the 5 awesome Snap tutorial workshops! Thanks a lot to Zdenek Dohnal, Johannes Meixner, Deepak Patankar, and Aveek Basu to be my guests on my OpenPrinting Community panel. And thanks to Heather Ellsworth, Mauro Gaspari, and Philipp Kewisch for their work lunch with me to learn about how to run an Indaba-like panel session. It helped me a lot for hosting my first two panel sessions. Special thanks to Mauro Gaspari and Aaron Prisk for their great work on editing the recordings of all the sessions, and saving most of them, especially also my Snap panel. Also thanks to everyone participating in any form on the Summit and making it an exceptional event!! The videos of the sessions on the Linux Plumbers Conference 2022 in Dublin are edited and ready for watching! Especially the recordings of the OpenPrinting micro-conference are available now: CUPS 2.5 and 3.0 Development Testing and CI for OpenPrinting projects Restricting access to IPP printers with OAuth2 framework Documentation for OpenPrinting projects Sandboxing/Containerizing alternatives to Snap for Printer Applications Note that the documentation session finished early and we already started on containerization in the documentation time slot, so therefore some of the containerization talk and discussion is in the video of the documentation session. I have also updated the summary of the outcome of our Micro-conference in our September News Post with the links. The program will take place again next year! Also the timeline is already published. And I will participate again with the Linux Foundation and OpenPrinting, there is enough on our roadmap. Also we started already with the selection and onboarding of the first contributor candidates. Potential project ideas are: Adding support for the new functionality/attributes of IPP Everywhere 2.x to PAPPL, libcupsfilters, Common Print Dialog Backends (CPDB), ... CPDB backend for IPP infrastructure/cloud printers Turn cups-browsed into a Printer Application Native Gutenprint Printer Application - Take 2 CI Testing programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, ... Note that the need of GUI/Desktop integration for printing with OAuth2 is still to be discussed, as in 2023 the IPP/OAuth2 standard will be significantly enhanced as in the current incarnation essential featues are still missing. Here are the final results of this year's Google Summer of Code. We got a lot of work done! GNOME Control Center GUI for discovering non-driverless printers and finding suitable Printer Applications for them
Contributor: Mohit Verma
Mentors: Till Kamppeter, Michael Sweet, Pranshu Kharkwal, Divyasheel, Deepak Patankar
Work Product PASSED Create new printer setup tool for the GNOME Control Center
Contributor: Shivam Mishra
Mentors: Till Kamppeter, Pranshu Kharkwal, Divyasheel, Deepak Patankar
Work Product PASSED Adding Common Print Dialog Backends (CPDB) support to existing Print Dialogs
Contributor: Gaurav Guleria
Mentors: Till Kamppeter
Work Product PASSED Scanning Support in PAPPL with eSCL Support
Contributor: Rishabh Maheshwari
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
Work Product PASSED Scanning Support in PAPPL
Contributor: Deepak Khatri
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
Work product not delivered. FAILED Converting Braille embosser support into a printer application
Contributor: Chandresh Soni
Mentors: Till Kamppeter, Samuel Thibault
Work Product PASSED Add Avahi calls for discovering and resolving driverless IPP printers and Optimize the processes
Contributor: Sachin Thakan
Mentors: Till Kamppeter, Michael Sweet, Deepak Patankar
Work Product PASSED Make a native Printer Application from Gutenprint
Contributor: Sahil Kumar Dhiman
Mentors: Till Kamppeter, Solomon Peachy, Michael Sweet
Failed already on mid-term. FAILED In all the evaluations the contributors submitted, both mid-term and final, they praised their mentors, especially me, and also the work at OpenPrinting. Thanks a lot to all the contributors for their great work and also to the mentors for guiding our contributors through their projects. Also thanks a lot to Aveek Basu for contacting universities and colleges in India to find these amazing contributors. Organizing an amazing Ubuntu Summit and mentoring a great team of GSoC contributors is much more exciting work than the tedious clean-up of thousands of lines of code. This is probably the reason why the release got delayed ... ... but now, finally it is done: The first beta of the new generation of cups-filters is available! The cups-filters project is now split into several parts, similar to CUPS on its transition to the 3.x series. There are the following parts: libcupsfilters: The central library with the filter functions and some useful functions for printer drivers, human-readable strings and translation handling for IPP attributes, ... It does not contain any support for PPD files. libppd: PPD file support library providing the complete support for PPD files from libcups (2.x and earlier, see ppd/ppd.h), the CUPS PPD compiler and utilities (ppdc, see ppd/ppdc.h) and functions to convert PPD options into IPP attributes, to add PPD file support to the filter functions of libcupsfilters, to handle collections of PPD files, ... This library is only for legacy PPD and driver support, it should not motivate anyone to create new PPD files! cups-filters: Legacy CUPS filter/backend executables for CUPS 2.x. Uses both libcupsfilters and libppd. Any XXXtoYYY filters, foomatic-rip, driverless, ... braille-printer-app: The Braille embosser driver code plus Chandresh Soni's GSoC work to turn this code into a Printer Application. cups-browsed: Daemon to automatically create local print queues for network printers and remote CUPS queues and to create printer clusters. Will be turned into a Printer Application later (GSoC project?). libcupsfilters is completely free of PPD file support, same for braille-printer-app. libcupsfilters can be used for all kinds of Printer Applications and wherever print data or scanned data has to get converted. The Braille Printer Application is a native Printer Application, it does not use PPD files internally. libppd contains the complete PPD file support for Printer Applications which retro-fit PostScript PPD files or classic CUPS drivers. These Printer Applications are usually created based on pappl-retrofit. Distributions using the New Architecture for printing and scanning will not install libppd by default, as it is not needed any more. cups-filters provides the filter executables needed by CUPS 2.x or earlier. Most executables are just simple wrappers and all the internal workings have moved into the filter functions in libcupsfilters, and the PPD file support into libppd. This package requires libppd, but it is for PPD-based classic CUPS versions only anyway. cups-browsed is currently supporting and generating PPD files (for CUPS 2.x), and therefore also depending on libppd. In a later version, when it is turned into a Printer Application, the PPD file support will be removed. An important goal of the separation is to put all PPD support into their own project so that it can get discontinued later and this way we can easily stop maintaining the PPD file support code while all the other useful code of the former cups-filters will live on. libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion cups-filters: More Details and Download, Discussion cups-browsed: More Details and Download, Discussion Note that braille-printer-app will only be released once the conversion to a Printer Application got committed. Now all the code cleaning is done (filter/, backend/, and utils/ were still missing) and the license/copyright headers of all the files (both code and non-code files, like PPDs, *drv, MIME rules, ...) are switched to the new Apache 2.0 license (same license as CUPS). Also the source package documentation files (README.md, INSTALL, CHNAGES.md, COPYING, ...) got updated, new documentation files (DEVELOPING.md and CONTRIBUTING.md), and the new license files (LICENSE, NOTICE) got added. After that the actual separation has taken place. Studying how to best do the separation, especially conserving commit histories and avoiding clutter, I found this method on GitHub and the git-filter-repo tool. I did the separation thoroughly, one part at a time, with a lot of testing whether everything still builds and no files get missing or duplicate, did final adjustments in the source package documentation files, and released 4 of the 5 parts. And for the first time I assigned a GitHub discussion thread to each release. Now I need to also release pappl-retrofit and update the 4 retro-fitting Printer Application Snaps which currently do not build any more. In a hallway session on the Ubuntu Summit I talked with Harald Sitter from KDE about my GUI GSoC work for OpenPrinting, especially of Gaurav Guleria's project of switching both GNOME/GTK and KDE/Qt print dialogs to the Common Print Dialog Backends and also about that this does not change the GUI of the dialogs and the GUI of the Qt dialog is still of the early 2000s when the switchover to CUPS happened. Harald told that he wants to improve/modify the GUI and we agreed on getting at least a design similar to the GTK dialog. After being back from the Summit I sent him my OpenPrinting onboarding materials. From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|850874| |ipp-usb|ipp-usb|3106| |ps-printer-app|PostScript Printer Application|2660| |ghostscript-printer-app|Ghostscript Printer Application|2070| |hplip-printer-app|HPLIP Printer Application|6440| |gutenprint-printer-app|Gutenprint Printer Application|5193| Note: The installed base of the CUPS Snap sky-rocketed to ~850000 (factor of 10) due to the switchover of the Chromium browser Snap to plugging the cups interface. Now all Chromium Snap installations auto-install the CUPS Snap as dependency. Currently released is 2.4.2. There will be further bug fix releases in the 2.4.x series. In the last month there were mainly typo fixes in comments and other minor fixes, nothing in the actual code of CUPS. Ubuntu Lunar Lobster (23.04 will use some 2.4.x or 2.5.x release of CUPS. It is planned to use the Snap package of CUPS. The CUPS Snap (in the Edge channel) and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master of CUPS. The CUPS Snap in the stable channel is version 2.4.2. Currently released is 2.0b1. The first beta (2.0b1) of the second generation of cups-filters is now released. cups-filters is now split into 5 separate packages. See above for more details. cups-filters 1.x releases can happen depending on need of the ditros. Ubuntu Lunar Lobster (23.04 will use the New Architecture and with this use 3.x packages of libcupsfilters, libppd, cups-filters, braille-printer-app, and cups-browsed. CUPS will be included as Snap. The CUPS Snap is currently locked to the /e496badbf2 commit (from May 20) of cups-filter's GIT master (2.x) until the restructuring gets more tested. This lock will get lifted soon. The Printer Application Snaps use the current GIT master of cups-filters and currently do not build. They need to get adapted to the split repositories. Currently released is 1.2.3. In the last months the development of the 1.3.x series has already started. See changes below. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-November-2023",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - November 2023",
+ "url": "/OpenPrinting-News-November-2023",
+ "headings": [
+ "Ubuntu Summit 2023 in Riga",
+ "FOSDEM 2024",
+ "Google Summer of Code 2024",
+ "Google Summer of Code 2023",
+ "Snap workshops",
+ "CPDB CUPS backend Snap",
+ "PAPPL 1.4.3"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/TtsglXhbxno/hqdefault.jpg",
+ "snippet": "Ubuntu Summit 2023 in Riga, FOSDEM 2024, GSoC 2024, GSoC 2023, Snap workshops, CPDB CUPS backend Snap, PAPPL 1.4.3",
+ "content": "Probably most of you have made their first desktop computer experience with Windows, and later on started working with a Linux desktop system. Many of your daily tasks which you formerly did under Windows you are doing under Linux now. Some work great, for others you wish your Windows back ... But having a look at this (stone-old, from Dec 2021) Linus Tech Tips video and especially Michael Tunnell's reaction video, printing is not the part where one wants to have Windows back. At 3:00 min Michael says There is no such thing like a pain-free experience of printing under Windows ... Linux printing is ridiculously good ... and at 14:25-17:25 min we get the confirmation that one can effortlessly print even with an oooold, non-driverless Samsung CPL-something ... Thanks Michael, I am looking forward to our Destination Linux episode ... But there is more on YouTube, this time on Ubuntu OnAir. After the Ubuntu Summit I have stayed in Riga for one more week, for Canonical's internal Engineering Sprint where all the engineers of Canonical, around ~700 people currently, meet twice a year, near the beginning of each Ubuntu development cycle. In addition to meetings inside and across the teams there are also lightning talks and workshops open for everyone on the Sprint. I have given two sessions this time, both not containing anything Canonical-confidential and so I got the permission to publish the recordings on Ubuntu OnAir. Here we go: Lightning talk: Opportunity Open Source conference in the IIT Mandi, India: Motivating people to be a part of us! Interactive workshop: Your app everywhere, just in a Snap! And last but not least, we have a nice video of the Ubuntu Summit 2022 in Prague, the Aftermovie, published shortly before this year's Summit as motivation to attend. And we have good news for users of NixOS: Now Snap is supported and so you cannot only install many application Snaps from the Snap Store but also our Printer Application Snaps to make all those ~10000 non-driverless legacy printers which are already working with common classic Linux distributions also just work with NixOS. And everyone is providing an advent calendar these days, unfortunately we did not make one at OpenPrinting, but there is one from the Ubuntu Summit 2023! See below ... So let us dive into what happened at OpenPrinting in November ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Update: Complete playlist of all 88 sessions! Recordings from the plenary room: Day 1, part 1, Day 1, part 2, Day 2, Day 3 And here is the Ubuntu Summit Advent Calendar: Recordings of the individual sessions in all rooms will be posted from today on until the end of this year on the Ubuntu Summit 2023 playlist on Ubuntu OnAir. Open 3 new videos every day (workshops on Wednesdays) for the coming 30 days. They are all edited by a professional editing team. Mastodon: #UbuntuSummit, #UbuntuSummit2023 Now it has taken place, the second Ubuntu Summit, this year in Riga in Latvia, and we in the organization team are already making our first thoughts on the third one ... Two and a half days of amazing sessions in 5 rooms in parallel. The speakers on this second edition were less Canonical employees but more people from the wider community, and not exactly an Ubuntu Summit but more a Summit about Linux and free software in general. Sessions Still making well use of the hallway track I succeeded to attend many sessions, most of those I originally planned to attend and listed last month here: Welcome to the Ubuntu Summit, Philipp Kewisch (Head of Community Team, Canonical), Mark Shuttleworth (Founder and CEO, Canonical), Nathan Haines (Ubuntu Community Council), Fri 11/3, 14:00 EET (video) From origins to open source: The journey of DreamWorks Animation's production path tracer, MoonRay, Randy Packer (DreamWorks Animation), Fri 11/3, 15:00 EET (video): Amazing presentation, with sample movie in the following break. Introducing Ubuntu Core Desktop, Ken Vandine (Core Desktop development lead, Canonical), Oliver Smith (Product Manager Desktop, Canonical), Fri 11/3, 16:30 EET (video): Nice overview of the state of the art of the development of Ubuntu Core Desktop, and Ken shouted me out when it came to the printing part, I got up and the audience applauded ... I have also answered the first user comment on the YouTube video of the recording. Alioli ROV Submarine Drone, Juanmi Taboada, 11/3, Fri 17:00 EET (video): How a remote-controlled submarine to explore and photograph potential SCUBA diving sites was developed and all being controlled with free software. And the next day there came the surprise event: We all could test-d(r)ive it in the hotel's pool (only 1.30 m deep, so no risk to implode it) ... What It's Like to Build an Open, Repairable Laptop, Daniel Schaefer (Framework Computer), Sat 11/4, 9:00 EET (video): We are sustainable! Last year we have recycled old printers and this year we have easily repairable and practically arbitrarily upgradable laptops on the Summit. I also had a hallway session with Daniel afterwards and he was demonstrating how easily hardware components could get changed. Windows Subsystem for Linux (WSL) - Make an awesome Linux environment directly on Windows, Craig Loewen (Microsoft), Sat 11/4, 9:30 EET (video) Improving Snap maintenance: Automating tag updates on new upstream releases of the app - Interactive workshop, Till Kamppeter (Canonical/OpenPrinting), Jesús Soto (Canonical), Sat 11/4, 12:00 EET (video, slides): My workshop about Snap update automation. Also Sergio Costas and Ken VanDine, both passionate snappers in the Ubuntu Desktop Team at Canonical, and Sergio having worked together with Heather Ellsworth on the automation method I have presented in this workshop, were in the room in case people need help on the exercises. Container craftsmanship: from a Pebble to a ROCK - Interactive Workshop, Cristovão Cordeiro (Canonical), Sat 11/4, 14:00 EET (video, slides, exercises): Right after my workshop there was a workshop for snapcraft-experienced snappers to learn packaging apps in OCI containers using rockcraft. I attended it as this could be a way to create an official OCI container of CUPS, based on the CUPS Snap. And the way how upstream software components are loaded for the container build is exactly the same as with snapcraft, so applying update automation here would require only modifying a few lines. Skynet or Star Trek, what’s the future of AI? - Panel session, Graham Morrison (host, Canonical), Andreea Munteanu (Canonical), Craig Loewen (Microsoft), Frank Karlitschek (Nextcloud), Juan Luis Cano Rodríguez (QuantumBlack, AI by McKinsey), Pablo Ruiz-Múzquiz (Kaleidos/Penpot), Sun 11/5, 9:00 EET (video) ScaniVerse: A New Horizon in Unified Scanning for Linux Systems Akarshan Kapoor (Indian Institute of Technology, Mandi, India), Sun 11/5, 11:30 EET (video): Akarshan presenting his GSoC work of this year in his own, special style. I have been in his talk especially also to help answering questions and I have remarked in the end that one should be careful with making the MetaScan frontend send the user's Scan to external internet services for analysis, for privacy reasons. Bringing Windows applications to Linux app stores, Merlijn Sebrechts (Ubuntu Community Council, Snapcrafters), Sun 11/5, 12:00 EET (video): WINE allows to run many Windows apps under Linux but needs some configuration and setup work. To make it easy for end users to simply grab Windows apps in the Snap Store, there is Sommelier, which this talk was about. I asked Merlijn what about having a \"app loader\" Snaps using Somellier which do not contain the (often proprietary) app but just load it from the Windows file system to run it uner Linux. He told that this is already possible, especially with Bottles and Lutris (31:48 min). Behind the Scenes of tox: The Journey of Rewriting a Python Tool with Over 10 Million Monthly Downloads, Jürgen Gmach (Canonical), Sun 11/5, 14:30 EET (video): Jürgen is nearly as long into free software as me, I started with SUSE 5.1 in 1997, he two years later with SUSE 7.0. Linux Lads live podcast recording, Shane, Mike, Conor, and Amolith (Linux Lads Podcast), Sun 11/5, 16:00 EET (video, actual podcast): This was great, the Linux Lads podcast produced live with audience interaction. I have taken a first-class seat (first row), with these signs \"content creators only\", but hey, this news post is content, and my talks and workshops on conferences, too, and so I was close to them and contributed. At 20:40 min I give an example how meeting on conferences causes actions and tell why the Linux App Summit 2024 will take place in Monterrey, Mexico, and at 45:25 min I give an example how conference attendees come well equipped for winter weather. Closing Plenary, Philipp Kewisch (Head of Community Team, Canonical), Sun 11/5, 17:30 EET (video) Hallway Track But most important of all is the hallway track (including any evening outings, meals, bar hangouts, ...). For me it started already one day before the official opening of the Summit, as I traveled already on Thursday, the day before the event started, to make sure to be there in time, even if the airline messes up my flight. I had an early morning flight, directly from Vienna to Riga, and there I met already Andrei Iosif of Canonical's Security Team. So this was not actually a hallway session but more an inflight session. We happened to have seats close to each other and swapping with one other passenger we were sitting together. He told me about Fuzz testing, a special method to test software with random input to find crasher bugs, buffer overflows and similar which can cause severe security risks. He introduced me to Google OSS-Fuzz a free-of-charge service for free software projects and the possibility to fuzz-test OpenPrinting projects. I arrived in the hotel at lunch time, and so I already attended the hallway track of the last days of Canonical's internal Product/Roadmap Sprint, where Canonical's managers meet twice a year for one week each time. So several colleagues from Canonical I have met already there and this way got more time to meet old and new friends from the community on the actual Summit days. Thursday evening I finally met with non-Canonical people for the first time on this trip. We had dinner in the old town of Riga, mainly colleagues of Canonical's Desktop Team, like Ken VanDine, Sebastien Bacher, Jesús Soto, Jean-Baptiste Lallement, ... also Jürgen Gmach of the Launchpad Team, but also several non-Canonical people, as for example Alan Pope (\"Popey\") or Martin Wimpress (\"Wimpy\"). And on Friday at lunch time, right before the start of the event I met Akarshan Kapoor, GSoC contributor on PAPPL Scanning (see below) and Monica Ayhens-Madon, formerly in Canonical's Community Team and currently at Thunderbird (LAS 2022, Ubuntu Indaba, Community Office Hours). Monica hugged me saying that this is a hug from Heather, and so I hugged her back, telling her to pass this hug back to Heather. On the event I had several nice hallway sessions: Daniel Schaefer demonstrating the repairability and upgradeability of Framework laptops, everything held together by magnets and screws which do not fall out when unscrewed, no soldered-in RAM, everything modular to separately exchange and upgrade, even while the machine is turned on and running ... Popey (Alan Pope) is proudly presenting his Steam Deck running Ubuntu Core Desktop, naturally hanging out a lot with Ken VanDine therefore. We had a little Raspberry Pi demo table during the whole conference, right in front of the door of the plenary room, with a Pi (4 or 5) connected to a large monitor, a keyboard and a mouse, and different things were shown there: Ken VanDine was naturally showing off Ubuntu Core Desktop on the Raspberry Pi 4 (did not work yet on the 5, Ken spent nearly the whole Engineering Sprint in the week afterwards to get this finally going). And our gamers one also found often enough showing off their work on the Pis. I met Diogo Constantino from the Ubuntu Portugal local community and we exchanged ideas about combining DebConf 2024 and UbuCon 2024, holding both, one after the other in Aveiro in Portugal. Originally DebConf should have taken place in Haifa in Israel, but this got canceled and the Call for Locations re-opened. Noah J. Chelliah met me on the hallway and asked me for an interview, for his \"Ask Noah\" podcast. So we immediately went to an unused conference room for a \"Noah asks\" and we recorded the interview, me telling him about OpenPrinting, how it started and what we are doing. The interview will get put into one of the next shows, but he told that he also interviewed more people, so it can take some weeks until it is my turn (Update: It will be episode 368 due on Tuesday, December 20, ~11:59pm UTC). Amolith (from the Linux Lads) has created scripting to get informed about new releases of software running on his server, Willow, and it seems that it covers more types of upstream release notifications than our Snap update automation, so I have a way to improve the Snap automation if needed. Monica Ayhens-Madon came up with a little penguin which she has bought in the old town of Riga and wants to give it to a good friend who collects penguins (Update: It is Jill from Destination Linux), but first, gave it a tour on the Summit, taking a lot of photos with many interesting people. See her thread on Mastodon (Update: The penguin has safely arrived at its Destination (Linux)! Thanks, Mathieu Comandon! Jill's thread on Mastodon, Jill's LWDW/linuxgamecast video). When leaving the closing plenary, Michael Tunnell from TuxDigital and one of the hosts of Destination Linux grabbed me in the crowd leaving the plenary room and invited me for an interview in one of the next episodes of Destination Linux (Update: The interview has been produced now and will be on the road as episode 351 from Monday, December 18, ~10pm UTC on). And during the closing party I met Graham Morrison, master of the Snap/snapcraft documentation at Canonical, and suggested to him to put up all my Snap workshop materials (slides, exercises, video links) onto the snapcraft.io web site for people to learn Snap or to give the workshops on more conferences, and he liked the idea ... See below. Blogs and podcasts Naturally there are many content creators, bloggers, podcasters, YouTubers, ... on such an event, and so we already have some nice stuff to read, listen to, and watch (taken from the internal list of the organization team): Akarshan Kapoor on dev.to The Ubuntu Summit 2023: Akarshan Kapoor, excellent GSoC contributor on scanning support in PAPPL this year and co-organizer of the Opportunity Open Source, attended the Summit and presented his GSoC work, and wrote a great blog article about the Summit, starting with his talk getting accepted, his travel to Riga, the people he met, ... he has really amazed us with this blog in his special style. I have left a nice comment on it, also to give readers a background about the great things which Akarshan did. Alan Pope Blog Heading to Ubuntu Summit 2023: Alan Pope (\"Popey\") announcing that he will attend the Summit. He also tells about what the former Ubuntu Developer Summits were and what the Ubuntu Summit 2022 was. Ubuntu Summit 2023 was a success: Popey's report from the Summit. He speaks positively about many aspects of the Summit, especially the organization, the choice of talks, the hallway track, Raspberry Pi vs. games and Ubuntu Core Desktop, gaming night. Ubuntu Core Snapdeck: Popey tells about Ubuntu Core Desktop running on his Steam Deck, what he was proudly presenting on the hallway track of the Summit. The Register Canonical shows how to use Snaps without the Snap Store - Despite what you may have heard, it's not as proprietary as the trolls think: Our special vulture, Liam Proven, talked with Igor Ljubuncic about Snap and the Snap Store and how to install Snaps without Canonical's Snap Store. Near the end he gives examples how Canonical is publishing how Snap works and how to use it, including a link to my workshop about Snap update automation. Ubuntu for Arm64 laptops (plus RISC kit) - Did you know there's an Asahi flavored Ubuntu? And Debian, too: Here the vulture writes about the talks about Ubuntu on non-amd64 platforms, Arm, Apple silicon (Asahi), RISC-V, ... Canonical reveals more details about Ubuntu Core Desktop - This new entrant in the immutable space is not a replacement for ordinary Ubuntu: And the vulture has also attended Oliver's and Ken's talk about Ubuntu Core Desktop and writes about this distro, including Popey's demoing on the Steam Deck in the hallway track. Ubuntu Budgie switches its approach to Wayland - Elementary OS going full speed ahead, but Parachutist Parakeet considers a new, post-Enlightenment glide path: And as last year, the vulture provided us with 4 articles! He met David \"Fossfreedom\" Mohammed and Sam Lane from Ubuntu Budgie and talked with them about how it will get switched over to Wayland. Destination Linux Video PodCast Episode #346: A very good recap of the event, target audience, extra fun activities. Episode #347: Interview with Simon Quigley starts with a very good review of the Ubuntu Summit. Focus on importance on networking, community, and great talks. Michael Tunnell on YouTube Ubuntu Summit 2023 Day -1 & 0 Day 1 Day 2 Day 3: Michael Tunnell's daily video reports from the Summit Ask Noah Podcast Episode #362: Noah speaks positively about the Summit and spotlights Rudra and the respectful and empowering community of Ubuntu. Also interviews Jon Seager on a few topics, primarily JuJu. 2.5 Admins Podcast Episode #168: Jim Salter talks well of the Ubuntu Summit, Jim mentions Canonical looking at the feedback and working hard to make major improvements. Great hallway track, podcasters. Probably this list will get longer next month. After many, many years I will attend FOSDEM again! The last time I attended it was in the early 2000s when I worked at MandrakeSoft in Paris, having only 90 min by train to get there. From Vienna I will have to take a 2-hour flight. FOSDEM (Free and Open Source DEveloper's Meeting) is a large conference. It is registration-free, anyone can just walk in and attend all the talks. There are more than 8000 visitors to enjoy more than 600 sessions in 36 rooms in parallel and ~60 non-commercial exhibition booths. There are a few rooms for plenary sessions, main track, and lightning talks with the sessions selected by the organizers of FOSDEM itself, but most rooms are the so-called devrooms. 59 free software community projects selected by a call for proposals for the devrooms have received a devroom and are responsible to fill it with sessions, usually via a call for proposals for presentations. These calls for proposals are currently open and depending on the devroom will close between Dec 1st and Dec 8. I have done 6 submissions, all for sessions which I have already given in similar form on other conferences, but I will naturally update them where needed. This is what I have submitted (with links to my most recent versions of these sessions): Desktop Linux, as easy as a smartphone! Just in a Snap! - Talk telling what Snap and Ubuntu Core Desktop are and how they work 55-min talk in Distributions devroom (already given on Opportunity Open Source, video, slides). Your app everywhere - Just in a Snap! - Interactive Workshop - Attendees learn packaging applications as Snaps, with exercises on their own laptops 55-min workshop in Distributions devroom (already given on Opportunity Open Source and Canonical-internal Sprint, video, slides). OpenPrinting - We make printing just work! - How it all started, what we have achieved, and what we are currently doing 50-min talk in Main Track (already given on Opportunity Open Source, video, slides) Save Legacy Printers under Windows with WSL and Printer Applications - Installing Printer Applications under WSL to support printers where Microsoft or the printer manufacturer do not supply drivers any more 15-min Lightning Talk (already given on Ubuntu Summit 2022 in Prague, video, slides) Opportunity Open Source conference in the IIT Mandi, India: Motivating people to be a part of us! - About the conference I have organized in India to motivate people to join free software 30-min talk in Community devroom (already given on DebConf 2023 in Kochi, India, video, slides) 15-min (or 5-min) Lightning Talk (already given on Canonical-internal Sprint, video) Most probably not all of these proposals will get accepted, especially the proposal for the workshop in the Distributions devroom is rather experimental, and also if the two sizes of the talk about the Opportunity Open Source get accepted, I will perhaps only give the long version. Next year we will have a GSoC again, and this time a very special one, the 20th GSoC!! It got announced a few weeks ago. I will participate again with the Linux Foundation and OpenPrinting, there is enough to do ... And we are already starting with finding and selecting contributor candidates. Potential project ideas are: Desktop integration: CPDB support for the print dialogs of Mozilla (Thunderbird/Firefox) and LibreOffice Desktop Integration: Update system-config-printer for the New Architecture of printing Desktop Integration: User interfaces for using OAuth2 with printers and scanners CPDB backend for IPP infrastructure/cloud printers Turn cups-browsed into a Printer Application Note that for general acceptance of CUPS 3.x and of the CUPS Snap we need to have a desktop integration for all desktops, not only for GNOME. Suggestions for any further project ideas are more than welcome. And if you like to be a GSoC contributor next year, please contact me (till AT linux DOT com). This year's GSoC came to an end and 4 of our originally 6 GSoC contributors have passed their final evaluations. They did awesome work which brought us a lot closer to have a smooth transition to CUPS 3.x and its PPD-less New Architecture. The projects still need a little work, but the contributors will finish this in their end-of-year breaks. And here are the final results: OpenPrinting: CPDB support for application's print dialogs: Firefox, Chromium, LibreOffice
Contributor: Kushagra Sharma
Mentors: Till Kamppeter, Gaurav Guleria, Shivam Mishra, Rithvik Patibandla, Ira McDonald
Work Product PASSED Sand-Boxed Scanner Application Framework
Contributor: Akarshan Kapoor
Mentors: Till Kamppeter, Rishabh Maheshwari, Deepak Patankar, Ira McDonald
Work Product PASSED GNOME Control Center: List and handle IPP print services for the New Architecture
Contributor: Mohit Verma
Mentors: Till Kamppeter, Marek Kašík, Zdenek Dohnal, Rithvik Patibandla, Ira McDonald
Work Product PASSED Continuous Integration: Test Programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, CPDB Libs
Contributor: Pratyush Ranjan
Mentors: Till Kamppeter, Deepak Patankar, Zdenek Dohnal, Ira McDonald
Work Product PASSED Native gutenprint Printer Application
Contributor: Gayatri Kapse
Mentors: Till Kamppeter, Rishabh Maheshwari, Zdenek Dohnal, Ira McDonald
Work Product FAILED Native gutenprint Printer Application
Contributor: Yuvraj Aseri
Mentors: Till Kamppeter, Solomon Peachy, Rishabh Maheshwari, Chandresh Soni, Ira McDonald
Failed already on mid-term. FAILED Note that Gayatri's original project was \"Adding support for the new functionality of IPP Everywhere 2.x to libcupsfilters and CPDB\". This project turned out as not feasable and so I moved her to \"Native gutenprint Printer Application\", after mid-term, the project where Yuvraj failed on. Our contributors liked a lot to work with OpenPrinting and expressed it in their final evaluations for the mentors: Kushagra Sharma: Thank you for amazing guidance, OpenPrinting is an amazing team and working along side helped me learn a lot , I hope to keep contributing and keep in touch with mentors and fellow contributors Akarshan Kapoor: I express my profound gratitude for the invaluable guidance and unwavering support bestowed upon me by my mentors throughout the duration of the GSoC program. Their exceptional ability to simplify intricate concepts, their constructive critique on my contributions, and their genuine interest in nurturing my growth as a developer have played an instrumental role in making this journey immensely rewarding. The consistent check-ins and their willingness to address any obstacles or concerns that I encountered were particularly commendable. Nevertheless, there were certain instances when I felt slightly overwhelmed by the pace of progress, prompting me to suggest that incorporating more structured milestones or periodic evaluations could prove advantageous in future endeavors. In conclusion, I am profoundly appreciative of the knowledge they shared with me; their mentorship has indubitably left an enduring imprint on my personal and professional development trajectory. The mentors and the organization I encountered during my participation in GSoC left an indelible impression on me. The level of guidance, support, and communication extended to me was truly unparalleled, resulting in a seamless journey that proved immensely enriching. It became evident early on that their unwavering dedication lay not only in cultivating personal development but also fostering a conducive atmosphere for growth. Without a doubt, the mentorship offered and the program's well-structured framework exceeded all expectations I had harbored prior to embarking upon this endeavor. Consequently, I find myself overwhelmed with gratitude for being granted such an invaluable opportunity Mohit Verma: It was a wonderful expericence to work with OpenPrinting. I think they (the mentors) are the best out there. Pratyush Ranjan: I am really thankful for the support and response time, Till and Deepak gave me throughout the project. Workshop overview No need to meet me giving a workshop on a conference, you can do them all at any time. Click the links in this section and get a great snapper ... Snapcrafters and many upstream application projects need you ... Your app everywhere, just in a Snap!: Introduction into Snap packaging (snapping) with simple GNOME/GTK applications as example (video, slides) Daemon Snapper's Workshop: Snapping daemons and system applications (slides) Improving Snap maintenance: Automating tag updates on new upstream releases of the app: GitHub workflow to automatically update your Snap when an upstream source has a new release (video, slides) Links to the exercises and examples are on the slides. You need to have snapcraft installed and working on your machine, follow the instructions in the \"Setup\" section of the first workshop or use the virtual machine (~6 GB, *.qcow2) if needed. Stay updated on the official Snap workshop page on snapcraft.io! How I got into giving Snap workshops Back in mid-2022 when I joined the organization team of the Ubuntu Summit 2022 in Prague, I had a 3.5-hour 1:1 video call with the leader of the organization team, Mauro Gaspari, exchanging ideas of what we can do in this first Ubuntu Summit. And as he brought in that we could do 2-hour interactive workshops where attendees can try out the subject matter on their own laptops, I was immediately sold on that and formed the idea to do a workshop series on how to package applications as Snaps. Mauro liked this idea and I started to work on making it reality. And on the Ubuntu Summit 2022 in Prague, one year ago, it actually has taken place: One introduction panel and 5 workshops. All the speakers, including me, have put a lot of effort in designing the workshops and especially also the accompanying examples/exercises. Too much for presenting this only one single time ... The first workshop, the one to learn the basics, “Snapping like hell(sworth)”, originally given by Heather Ellsworth and Lucy Llewellyn, got already re-enacted as \"Snapping with Lucy\" soon after, only by Lucy on the DORS/CLUC in May 2023, in Zagrep, Croatia. Not actually knowing about Lucy's edition I also formed the idea to give Snap workshops. So I submitted \"Snapping like hell(sworth)\", renamed to \"Your app everywhere, just in a Snap!\" (the original name of the whole workshop series) on the Linux App Summit 2023 in Brno, the GUADEC 2023 in Riga, and the Ubuntu Summit 2023 in Riga, the latter 2 together with Heather. Only on the GUADEC it got accepted, but due to lack of audience I could not actually give it. But I have also organized my own conference this year, the Opportunity Open Source in the Indian Institute of Technology (IIT) Mandi in northern India. And there, after having done a quick pre-check, finding out that the 3 other employees of Canonical who also attended are interested and so I had an assured base audience, I actually gave it, but only the first half, as time restrictions only gave me a 60-min slot. I got a total audience of 12, what was very good, probably several got motivated by my talk introducing into Snap (video, slides). And finally I got the opportunity to give the workshop (video, slides) in its entirety on Canonical's internal Engineering Sprint, which happened in the week after the Ubuntu Summit 2023, also in Riga. Having ~700 engineers from Canonical on the event it was easy to get a significant audience, actually around 25 to 30 people showed up to get great snappers. And as there are only Canonical people, everyone had a suitable Ubuntu version on their laptop where they could install snapcraft and do the exercises. Nobody needed the virtual machine (~6 GB) which I have prepared already before the GUADEC. And so I found out how long the complete workshop actually takes. I made it in 2:10 hours. And on the Ubuntu Summit 2023 I actually got accepted for a Snap workshop, but for a more advanced one, \"Improving Snap maintenance: Automating tag updates on new upstream releases of the app\" (video, slides). I originally submitted it together with Heather, who originally created the update automation, but as she left Canonical, she was not on the Summit and I had to replace her by Jesús Soto. Some people were complaining that we had no beginner's workshop for Snap on this year's Summit. We are looking into fixing this in 2024 ... So together with the \"Daemon Snapper's Workshop\" (slides) I have now a repertoire of 3 (see below) and I will continue to give them on conferences and Engineering Sprints. Update: Now on snapcraft.io As one can easily also do these workshops by oneself at home, studying the slide decks and trying out the linked examples, the slides and examples should be made available on a place in the internet where interested people can easily find them. Therefore I have posted this section with all the links to slides, examples, and videos on the snapcraft.io Forum in the \"doc\" category. In addition I have pinned the post to keep it prominently visible. Thanks to Graham Morrison, responsible for Snap documentation at Canonical, for his support. We also plan to put everything onto a GitHub repo. And this will not only help to learn snapping, also everyone who likes to give a Snap workshop on a conference by himself could make use of these materials. On the snapcraft.io forum thread where I asked for help with the problems I talked about here last month a conversation with James Henstridge from Canonical's Desktop Team started. I have explained how CPDB exactly works, how it finds the available backends and how it communicates with them during the print dialog session in order to actually print a job. He also brought up some security concerns and I told him how we address them. Especially we found out that CPDB needs some changes: The printFile method of backends needs to pass the job data as stream (file descriptor or domain socket), not as file specified by a file path. The D-Bus methods getActiveJobsCount, getAllJobs, and cancelJob need to get removed from CPDB The file backend of CPDB cannot be used. We should discontinue its development and tell that it is for development and documentation only. Filtering of the printer list in the dialog should be completely managed by the frontends, and not by sending signals to the backends, to allow different filtering on print dialogs which are open to the same time. Add newly appearing backends while the dialog is open. Suggestions about how to make CPDB acually work with Snap were not made. I have asked Biswadeep to work on these changes and he will do so in December after his end-semester exams. PAPPL v1.4.3 is now available for download and is a bug fix release. Changes include: Added \"smi55357-device-uri\" and \"smi55357-driver\" Printer Status attributes to Get-Printer-Attributes responses. Fixed missing mutex unlock in DNS-SD code (Issue #299) Fixed \"printer-id\" value for new printers (Issue #301) Fixed DNS-SD device list crash (Issue #302) Fixed Set-Printer-Attributes for \"output-bin-default\" and \"sides-default\" (Issue #305) Fixed default \"copies\" value with papplJobCreateWithFile()."
+ },
+ {
+ "id": "post:OpenPrinting-News-October-2019",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - October 2019",
+ "url": "/OpenPrinting-News-October-2019",
+ "headings": [
+ "Linux Plumber's Conference 2019",
+ "Google Summer of Code 2019",
+ "Google Summer of Code 2020",
+ "Gutenprint as Printer Application",
+ "Avahi local service support",
+ "OpenPrinting web site",
+ "CUPS",
+ "cups-filters",
+ "ippusbxd"
+ ],
+ "tags": [],
+ "snippet": "Linux Plumber's Conference 2019 with OpenPrinting Micro-Conference, first project ideas for Google Summer of Code 2020, Gutenprint as native Printer Application, Avahi local service support continued, OpenPrinting web site switched over to the new design, cups-filters 1.25.7",
+ "content": "Till Kamppeter, Aveek Basu, and Rithvik Patibandla have held an OpenPrinting Micro-Conference on this year's Plumber's which has taken place in Lisbon, Portugal. Here we have discussed the current work of OpenPrinting: Driverless IPP Printing Driverless IPP Scanning Common Print Dialog Backends Printer (Scanner) Applications replacing current drivers Future of Printer Setup Tools 3D Printing Jake Edge wrote an excellent article on LWN. Thanks to Kate Stewart and Jeff Licquia for inviting us. Till Kamppeter and Aveek Basu will attend the Mentor Summit in Munich next week. We are looking into giving a lightning talk there. With the standards work of the PWG and after our discussion on the Linux Plumber's Conference, first ideas for next year's Google Summer of Code have come up: SANE driver for existing SANE-using apps to be able to access driverless IPP scanners (including Scanner Applications) Scanner Application Framework, to make Scanner Applications from SANE drivers Extend Printer Application Framework from a converter for legacy drivers to a general Printer/Scanner Application SDK, including direct, PPD-less printer applications, IPP System Service, web interface, C API library, ... Make a Gutenprint Printer Application but without PPDs and without Dheeraj's legacy printer driver converter, use only libgutenprint to get the printer capabilities. A built-in web admin interface could allow configurability. Turn cups-browsed into a Printer Application: Instead of creating a local CUPS queue for a printer cluster emulate an IPP printer which prints to the cluster (and local CUPS picks it up automatically, but how to prevent local CUPS from seeing the member printers directly). Can also pick up legacy CUPS broadcasts (or BrowsePoll from legacy servers) and provide these printers as IPP printers. Any further project ideas for the next GSoC are welcome. The developers of the Gutenprint printer driver suite started to discuss the development of a Gutenprint Printer Application to replace their current, classic printer drivers. The discussion is on the Gutenprint developer mailing list in this thread. The link will lead you to the message which started the discussion, go down the thread for the further messages. Trent Lloyd had some time again and promised to get the localhost support issue solved soon. He has answered on my pull request mid-September. He has even bought an IPP-over-USB printer for doing further work, but since then no futher reaction. After updating the web app for the printer/driver database for the new web site and the new OpenPrinting logo we have finally switched www.openprinting.org over to the new web site design! From now on the monthly news (like this page) and news items in general will be posted under \"News & Events\". No further release. Currently released is 1.25.7. Many releases happened during the short time to get bug fixes into the upcoming Ubuntu 19.10 (Eoan), to be released on Thu, Oct 17. 1.25.7: Bug fix release, fixing several crashes, pdftoraster not working with monochrome jobs, printing to clusters. 1.25.6: Bug fix release which especially fixes a bug when printing into a cluster but also soives other minor issues. 1.25.5: Bug fix release, mainly for cups-browsed not to die on left over locally generated queues of unclaen shutdown of the previous session. No further news."
+ },
+ {
+ "id": "post:OpenPrinting-News-October-2020",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - October 2020",
+ "url": "/OpenPrinting-News-October-2020",
+ "headings": [
+ "First year of monthly news posts completed!",
+ "Google Summer of Code 2020 Mentor Summit",
+ "Google Summer of Code 2021",
+ "Google Season of Docs 2020",
+ "Linux Foundation Mentorship Program",
+ "CUPS Snap",
+ "PostScript Printer Application",
+ "Driverless Scanning and IPP-over-USB",
+ "CUPS",
+ "cups-filters"
+ ],
+ "tags": [],
+ "snippet": "PostScript Printer Application, GSoC 2021, GSoD, LFMP, PAPPL, CUPS fork, cups-filters 1.28.5",
+ "content": "It was exactly one year ago, October 2019, when I posted my first monthly OpenPrinting news here on our web site! Some will tell me now that I already started in September 2019, but the September 2019 news post was only a test for the new platform and it was already October when I wrote it as an exact copy of the original mailing list news post. Due to COVID-19 this year's Mentor Summit was much smaller and totally virtual, an 4-hour event. Aveek Basu and me have participated, leading a breakout session and having a lightning talk. Here also the GSoC 2021 and its new mode was announced. There will be a Google Summer of Code next year again, but it will be different. The 3-months student projects will be replaced by part-time projects, 6-weeks full-time-equivalent, to be done in a 10-week time-window. Stipends are appropriately reduced to the half amount, leading to the smae per-hour value. Google hopes to attract more students by this mode. For us as org admins and mentors it means more work, as we have to select more students and we have to work with more students when mentoring. Also we cannot post bigger projects. So let us hope that there will also be a Linux Foundation Mentoring Program for the larger projects. Our OpenPrinting project Tutorial and Design Guidelines for Printer/Scanner drivers in Printer Applications is going well. Piyush Goyal has already written a lot and will continue until December 5. He regularly posts Pull Requests on our web site GitHub and we have merged them. See his work on our web site. He gets currently a lot of input, from me with my PostScript Printer Application as example for a non-Raster and CUPS-driver-retro-fit Printer Application and from Michael Sweet by adding documentation to his PAPPL project. In our first LFMP project also Nidhi Jain has withdrawn, also due to suddenly re-started classes in her college and a COVID-19 case in her family. Our second LFMP project about IPP Scan is going on. Abhik Chakraborty on the server side and Rishabh Arya on the client side are in the middle of their work and have passed their first evaluations. We had some discussion between Alexander Pevzner, Michael Sweet, and me whether we should actually use IPP Scan as network protocol for sandboxed packaging of scanner drivers/Scanner Applications or better eSCL instead, as eSCL is already implemented as client and as server, but we came to the final conclusion of continuing with IPP Scan. We only will move the assignment of the remaining work somewhat. Alexander will complete the IPP Scan support in sane-airscan by himself and both students will work on the server side. The CUPS Snap project is currently still waiting for the snapd project to add the needed API extensions. After the Pull Request for the implementation of the interfaces got merged we are still waiting for the completion of the pull request for adding the API functionality so that a Snap can check whether a client Snap plugs the needed interfaces is still in the works. After having all needed filter functions and PPD file collection handling implemented in cups-filters and having the HP PCL Printer Application as example I have created a Printer Application for PostScript printers. It is now available as the ps-printer-app repository on the OpenPrinting GitHub. Currently it is a first working model, it will get much more functionality, especially for best user experience, added in the near future. See all the details of properties, planned features, known issues, and how to use in the README.md file. This Printer Application is especially a working model for A non-raster Printer Application: Destination format is PostScript, a high-level/vector format. Input data in PostScript or PDF is accepted and needed conversion is not done through an inbetween raster step. A Printer Application which uses the new filter functions of cups-filters 2.x. Filter functions are library functions derived from cups-filters and contain decades of development and refinement starting from the introduction of CUPS in 2000. A retro-fit Printer Application for classic CUPS drivers, in this case the simplest form of only PPD files for PostScript printers. It lists PPD files from repositories included in the Snap, loads the PPD needed for the actual printer, extracts options from the PPD to display them in the web interface, accepts job settings as IPP attributes, and inserts the PostScript code provided by the PPD correctly into the output data stream. A Printer Application which does not pass through raw (input format is printer's native format) jobs. To assure that always the PostScript code of the PPD file is inserted into the output stream, we call the printer's native format \"application/vnd.printer-specific\" which does not exist as input format, so \"application/postscript\" input is forced through the pstops() filter function. To do not need to re-invent the code for forking into sub-processes so that we can pass data through a sequence of filters, we create a filter function to send the data off to the printer and form a chain of the actually converting filter function (one of pstops(), pdftops(), imagetops(), rastertops()) and the with this filter function using the filterChain() filter function. The PostScript Printer Application has all PostScript PPD files of the foomatic-db and HPLIP projects built-in, so most PostScript printer PPDs which usually come with Linux Distributions. Note that some PPDs use certain CUPS filters for extra functionality. These filters are not included. The user can add additional PPDs without needing to rebuild the Snap. The Main Inclusion Requests (MIR) to get ipp-usb passed the Ubuntu security team and so made it to be the default IPP-over-USB implementation in the Groovy Gorilla, Ubuntu 20.10, released October 22, some days ago. So we have reliable IPP-over-USB in Ubuntu now. Unfortunately, the security team was swmped with requests and so did not come to processing the MIR for sane-airscan. So it will only get into the Main repository in Ubuntu 21.04, to be released in April 2021. As it is already in the Universe repository, it can still get easily installed in 20.10. Also upstream is always supplying the newest version in packages for common Ubuntu releases. Alexander Pevzner is continuing to take user reports and make the packages working with as many devices as possible. IPP Scan support is currently still worked on in sane-airscan. Currently released is 2.3.3. Due to dormant upstream development we have created a fork an OpenPrinting which will replace the original repository if Apple does not come back with the development. So for the time being CUPS is maintained by Michael Sweet and me. Michael Sweet has already committed a lot of changes and fixes and Debian has put the first packages of the fork into Experimental. Apple having stopped CUPS development got also talked about at Phoronix, at the German Linux Magazin, and on the Register. I have answered on the former two, telling that we have started the fork and that CUPS will live on. Currently released is 1.28.5. On the way towards 2.0.0 we have converted many filters to filter functions, having now pstops, pdftops, pdftopdf, ghostscript (replaces gstoraster, gstopdf, gstopxl), pclmtoraster, rastertopdf (replaces rastertopdf amd rastertopclm), rastertops, imagetopdf, imagetops, imagetoraster, and filterChain. With the PostScript Printer Application the filter function concept got its first real life use. Due to this I found and fixed many bugs, especially filterChain() got actually tested for the first time and so found some important bugs and fixed them so that filterChain() actually works now. Also the functions for handling PPD file collections in libppd got actually used for the first time and I spotted and fixed some bugs in them. The release of Ubuntu 20.10 (Groovy Gorilla) also made me fix some bugs in the 1.x series of cups-filters. 1.28.5: Bug fix release for a quick, potential crasher correction in cups-browsed 1.28.4: Bug fix release, mainly to solve CUPS performance problems caused by the IPP fax support of the \"driverless\" utility 1.28.3: Bug fix release to solve problems caused by an inconsistency between the resolvers for DNS-SD-based URIs"
+ },
+ {
+ "id": "post:OpenPrinting-News-October-2021",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - October 2021",
+ "url": "/OpenPrinting-News-October-2021",
+ "headings": [
+ "Ubuntu 21.10 (Impish Indri) is coming!",
+ "OpenPrinting Micro-Conference on the Linux Plumbers 2021",
+ "The Summer of Printers in the Ubuntu Office Hours",
+ "Print Management GUI in Flutter",
+ "pappl-retrofit - The CUPS Driver Retro-Fit Library",
+ "ipp-usb Snap",
+ "CUPS-driver-retro-fitting Printer Applications",
+ "Printer Applications in the OpenPrinting printer/driver database",
+ "Gutenprint Printer Application",
+ "HPLIP Printer Application",
+ "CUPS Snap",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/8ZTI7kdPFLc/hqdefault.jpg",
+ "snippet": "OpenPrinting/GSoC in Ubuntu Office Hours, Gutenprint Printer Appl., HPLIP Printer Appl. supports HP's plugin, new print GUI in Flutter, CUPS' release plan",
+ "content": "This Thursday, October 14, 2021, is Ubuntu release day again! Ubuntu 21.10! Not a lot of new stuff in terms of printing (in addition to all printing- and scanning-related packages being up-to-date) but at least some nice things: The GTK print dialog finally lists virtual/temporary queues which CUPS generates for driverless IPP printers and Printer Applications. So if one uses only GTK-based applications, one does not need cups-browsed any more. But for now I continue providing cups-browsed, as Qt's print dialog is not cute. libcups is patched with the same algorithm for mapping standard IPP attributes to PPD option settings as I have created in libppd in cups-filters for the Printer Applications. So you can print to shared CUPS queues from your phone or IoT device and easily get the printout as you like it. And there will be a virtual release party on YouTube! Our micro-conference on Linux Plumbers 2021 was a success! We discussed a lot on our development plans. Especially Michael Sweet has presented his plans on how to go on with the CUPS development and the next releases. See the CUPS section below, Bhavna Kosta has presented her GSoC work on scanning with PAPPL. Here is the Recording on YouTube. We had the following sessions: Introduction
Presenter: Aveek Basu
Slides
CUPS 2.4/2.5
Presenter: Michael Sweet
Slides
CUPS 3.0
Presenter: Michael Sweet
Slides
Print Management GUI
Presenter: Till Kamppeter
Slides
Common Print Dialog Backends
Presenter: Till Kamppeter
Slides
Printer/Scanner Driver Design and Development
Presenter: Till Kamppeter
Slides
Scanning in PAPPL
Presenter: Bhavna Kosta
Slides
Closing Session
Presenter: Aveek Basu
On last week's episode of the Ubuntu Office Hours we have talked about our success with the Google Summer of Code (see also the announcement here last month). Not only me and Aveek Basu have been in the virtual studio but also two of our GSoC 2021 students, Divyasheel (Printer management GUI) and Pranshu Kharkwal (Universal CUPS filter). Our conversation with host Monica Ayhens-Madon why and how we are doing GSoC, finding students, introducing them to our projects, getting them as developer community members, ... The students also told about their experience with us, we all have also given some tips to everyone who wants to participate in the GSoC, as student, mentor, or organization, and in the end we answered some spectator's questions from the Live Chat. And here is the Recording on YouTube. Thanks a lot to Monica Ayhens-Madon for inviting us! As Michael Sweet and me talked about the New Architecture (Driverless IPP, Printer Applications, R. I. P. PPD files, ...) in the Ubuntu Indaba in August and I also mentioned that the printer setup tools need to change for this, the host, Heather Ellsworth from Canonical, brought me together with Frederik Feichtmeier, who is writing a replacement for the GNOME Control Center completely in the Dart programming language with the Flutter GUI toolkit (the GitHub). He showed much interest in making the printing part of his tool to work with the New Architecture. I introduced him into everything, giving him links to my news posts, our GutHub, the slides (especially these ones) and video of the Linux Plumbers conferences, the Indaba, the Office Hours, ... His tool is a good candidate to soon get a printer management tool of the new generation. Thanks a lot to Heather Ellsworth for this contact! The retro-fitting library is practically complete and is used by 4 Printer Applications now: PostScript, Ghostscript, HPLIP, and Gutenprint. In the last month it only received some minor improvements, mainly to fit the needs of our 4 Printer Applications: If all page sizes of the PPD file have zero margins (especially no variants of the same size with and without margins) we do not show \"Borderless\" check boxes on the \"Media\" web interface any more, as there is nothing to switch (commit). Raster input resolutions are limited now, to avoid overloading clients by requesting extremely high PPD resolutions from them (Gutenprint PPDs have up to 5760x2880dpi). High quality is limitted to 1440dpi, normal to 720dpi, and draft to 360dpi. 1440dpi is good enough for drawings and 720dpi good enough for photos (commit, discussion on the Gutenprint mailing list). Remove duplicate entries in lists of media sizes, media types, and media sources (commit). Explicitly shut down CUPS backend on end of job before the dynamic data structure of the job is taken down, to avoid a crash when the Printer Application by itself closes the backend later (commit). Allow setting callback functions for extra system and printer setup steps. Especially extra buttons and pages can be added to the web interface. We use this for example in the HPLIP Printer Application to add a web interface page to install HP's proprietary plugin, and to auto-update the plugin when starting the Printer Application (commit). Further development of the library will go with the development of PAPPL and the needs of the Printer Applications. Especially the following features will get implemented/supported as soon as they are implemented/fixed in PAPPL: Support for scanning. Needs support in PAPPL (Bhavna Kosta's GSoC project). Support for string/text-style vendor options. Needs support in PAPPL (Patch already applied in the Printer Application Snaps). Human-readable strings for vendor options. Needs support in PAPPL. Ink level check via ps_status() function. Needs support in PAPPL. ipp-usb is also available as a Snap in the Snap Store (229 downloads in the first 2 weeks) now! So making use of IPP-over-USB for easy driverless printing and scanning on USB-connected devices, one only needs to install the Snap and connect the printer to USB. You get an emulation of an IPP network printer and CUPS and SANE find it automatically. The Snap also offers configurability, logging, and user-editable quirks as a classic installation (see README.md). Note that the Snap is usually not needed on Linux distribution which have ipp-usb already installed and in working condition. Only if you have problems with the installed ipp-usb or simply want to always have the newest version, install this Snap then. Make sure to uninstall the system's ipp-usb (and also the obsolete ippusbxd). The challenge of making this Snap was to trigger ipp-usb on the appearing (and also the presence) of IPP-over-USB devices. In the classic installation of ipp-usb (via make install or RPM/DEB package installation) a UDEV rules file and a systemd service file (in systemd-udev/) are installed, so that the system automatically triggers the launch of ipp-usb when an appropriate device is connected or already present. A Snap is not able to do so. It cannot install any files into the system. It can only bring its own, static file system and create files only in its own state directory. These locations are not scanned for UDEV rules. So the Snap must discover the devices without its own UDEV rules, but it still can use UDEV. The trick is to do a generic monitoring of UDEV events and filtering out the USB devices with IPP-over-USB interface (7/1/4). If such a device appears, we trigger an ipp-usb launch. We also check on startup of the Snap whether there is such a device already and if so, we also trigger an ipp-usb launch. ipp-usb is run, as in the classic installation, with udev argument. This way it stops by itself when there is no device any more (and we do not need to observe the disappearal events of the devices) and it is assured that only one single instance of ipp-usb is running. To do this with low coding effort I use the UDEV command line tool udevadm in a shell script (snap/local/run-ipp-usb in the source repository). Once it runs in monitor mode to observe the UDEV events. Then we parse the output lines to only consider the ones for a device appearing and run udevadm info -q property on each device path, to get the properties and filter the 7/1/4 interface. In the beginning we use udevadm trigger in dry-run mode to find the already passed appearal event of a device which is already present. So the shell script is an auxiliary daemon to start ipp-usb when needed. We use the same method in the HPLIP Printer Application to automatically load firmware files into USB devices. See also the README.md file and the \"How to add or workaround a udev rule\" thread on the snapcraft.io forum. I came to the idea with udevadm monitor by myself, but Oliver Grawert (\"ogra\" in the snacraft.io thread) came to the same idea earlier. I got only aware of it by him reacting to this thread. On all the 4 currently available retro-fitting Printer Applications, PostScript, Ghostscript, HPLIP, and Gutenprint, the following improvements were done: No log rotation: As PAPPL rotates already after a rather small portion of log, we decided to de-activate PAPPL's log rotation completely in the Snaps. To avoid filling up the disk, the default log level is \"Error\" (can be changed in the web interface of the Printer Application). Maximum of 256 instead 32 vendor-specific options in PAPPL: As the Snaps of the Printer Applications build PAPPL by themselves, I have patched the hard-coded maximum for the number of vendor-specific options in PAPPL (a single number) as many PPD files (especially Gutenprint but also some high-end PostScript printers) have more options. This assures that always all options get available. See also our discussion on the Gutenprint mailing list. Use CUPS' backends and not PAPPL's: This gives the following improvements: Quirk workarounds for USB printers with compatibility problems are used. The quirk rules can get edited or new rule files added in /var/snap/*-printer-app/common/usb/ Additional network protocols: IPP, IPPS, LPD. Especially one can send PostScript output to the printer via encrypted IPPS. The SNMP discovery can get configured via /var/snap/*-printer-app/common/cups/snmp.conf Stop building libjpeg9 in the Snaps: The libjpeg8 from Ubuntu Core 20 works well enough and the Snap Store's build servers have difficulties to load the upstream source tarball from the original web site, requiring triggering several rebuilds manually until the Snap gets into the Snap Store. The libjpeg9 build was overtaken from the hp-printer-app Snap (where it also had been removed later). I had also posted a request for the Snap Store allowing auto-connections of all interfaces of the Printer Application Snaps and it got approved. So the Snaps can get easily installed from the Snap Store. To help users finding the correct drivers for their printers we always had the OpenPrinting printer/driver compatibility database. Now, as most of the legacy drivers listed there are in one of the four retro-fitting Printer Applications, we have now links to the appropriate Printer Application in each of the driver entries of drivers which are contained in one of the Printer Applications. So now people can finally install the desired driver on practically any Linux distribution (HPLIP, Gutenprint, pxlcolor, hl7x0, Ricoh PostScript). Gutenprint Printer Application in the Snap Store, 520 installations via Snap Store One of the most important printer driver suites in free software has made it into a Printer Application (and also into the Snap Store) now. It is known for its high output quality, adjustability, and support for third-party papers and ink sets. Now one can easily install its newest version on nearly any Linux distribution and easyily print from any IPP-capable device (like phones) but adjust all its options via web interface. It supports more than 3000 different printer models, especially inkjet printers from Epson and Canon, dye-sublimation photo printers, PCL 4/5c/e laser printers, but also some other printers. In addition it provides generic support for the different PCL flavors, everything which is supported by the Gutenprint CUPS Raster driver. Some of these printers are probably also driverless IPP printers, but you can still use this Printer Application then as perhaps you could get better output quality. The challenge when encapsulating this driver in a PAPPL-based Printer Application was that some PPDs (higher-end Epson inkjets) have around 120 options whereas PAPPL only supports 32 vendor-specific options by a hard-coded array. Fortunately, one only needs to change one number in PAPPL's source code to change this limit. So at least in Snaps, which build their own copy of PAPPL one can adjust the limit. So in all retro-fitting Printer Application Snaps I have changed it to 256. It is more a problem in distribution packages, where the PAPPL package is not modified. Here the Printer Application automatically switches to the simplified PPDs of Gutenprint. Another point which could cause problems are the high resolutions (uo to 5760x2880 dpi) which the driver uses. If we let the Printer Application simply use these, this can make clients (those which send jobs in Apple Raster or PWG Raster) render their jobs in such extreme resolutions and slow down the devices, slow down the printing and the data transfer, or even crash the client device. Therefore we limit now all retro-fitting Printer Applications to 1440 dpi for high, 720 dpi for normal, and 360 dpi for draft quality. 1440 dpi is good enough for fine drawings and 720 dpi good enough for photos. The higher resolutions are used only internally now, for the driver to use a sophisticated, fine-grained dithering. Both these issues got discussed on the Gutenprint mailing list (free-of-charge subscription required to discuss on the list). HPLIP Printer Application in the Snap Store, 1316 installations via Snap Store The HPLIP Printer Application experienced two substantial changes during the last month: The Snap uses the source code of the Debian package and not the upstream one and the Printer Application supports installing the proprietary plugin via web interface now, also in the Snap. Source code from Debian HPLIP's original source, as it comes from HP's web site has many bugs, unfortunately. The HPLIP developer team has a bug tracker at Launchpad and the bugs got reported there but it seems thatb the developers are not reviewing and merging the proposed patches. Therefore the Debian package of HPLIP (which is also used by Ubuntu) has 81 patches, partially originating from the Debian and Ubuntu developers but also from RedHat/Fedora developers. As it would be a lot of work to add the patches to the HPLIP Printer Application repository to be used in the Snap build, we have simply switched to Debian's GitLab repository as source instead of the original upstream tarball, as on Debian's repository the patches are already applied. This way in the HPLIP Printer Application Snap all these bugs are fixed and thanks to Debian's re-packaging of the original source, the code is totally free software (HP's original code contains a closed-source library even without the proprietary plugin). Support for the proprietary plugin Unfortunately, HP has some (cheaper) laser printers which do not work with totally free software. They either need their firmware loaded everytime when they are turned on ot they need a closed-source driver for their proprietary print data format. For this HP has issued a proprietary plugin which joins all these extensions for all devices needing it in a single package. On a classic HPLIP installation (as it usually comes with Linux distributions) one can install the plufin with the hp-plugin utility, or when setting up the printer with hp-setup. Now the plugin can also be used with the HPLIP Printer Application Snap. In the web interface (see screen shots in the Snap Store), on the front page, under \"Other Settings\" there is an \"Install Proprietary Plugin\" button now (and at the entries of all printers which need the plugin is a \"Plugin\" button). Clicking one of these leads to a web interface for installing the plugin, and also for updating, removing, and re-installing. One needs only to click the appropriate buttons, accept the license (on initial install) and the plugin gets installed. Once the plugin in place, the USB is observed (as with ipp-usb above, as we cannot install UDEV rules out of a Snap) to upload the appropriate firmware file if a USB printer which needs it appears (or is already there when starting the Snap). If the Snap gets updated by one with a newer HPLIP version, the plugin gets updated automatically. When installing the HPLIP Printer Application classically one can also install the plugin via web interface, but only if the Printer Application is running as root. Automatic updates of the plugin only happen when (re-)starting the Printer Application, also only as root. Running as non-root the web interface page only shows the status of the plugin, and the user has to install with ho-plugin of the (then also classically installed) HPLIP. As scanning support in PAPPL is not ready yet, scanning on multi-function printers is not yet supported. CUPS Snap in the Snap Store, 2832 installations via Snap Store I am still waiting for the snapd team to implement the security concept on the snapd side, but unfortunately, they are very busy currently but the merging into snapd is expected still in October, so that for the full developemnt cycle of Ubuntu 22.04 LTS (J. J.), starting end of October, it will be available for testing and deciding whether said Ubuntu version will come with the CUPS Snap as standard printing environment, and naturally uploading of applications which print into the Snap Store will get easy and fully automatic, without any manual review and permission needs. Michael Sweet has done some clean-up on the Snap support of CUPS and I have tested it with the CUPS Snap. All is working correctly. Main TODOs are: Complete the security concept on the snapd side, especially implement the content interfaces (see above) Testing Turn classic CUPS drivers into Printer Applications (see progress above) Add a migration script so that OS distributions can easily switch over from classic packages to the CUPS Snap From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|2832| |ipp-usb|ipp-usb|229| |ps-printer-app|PostScript Printer Application|1663| |ghostscript-printer-app|Ghostscript Printer Application|318| |hplip-printer-app|HPLIP Printer Application|1361| |gutenprint-printer-app|Gutenprint Printer Application|520| Currently released is 2.3.3op2. Development of CUPS 2.4 is in progress, currently mainly fixing of bugs which were reported to Apple's CUPS GitHub in the last 20 months. Ubuntu Impish Indri (21.10, release this Thursday, Oct 14) will also come with CUPS 2.3.3op2, the CUPS Snap and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master. As outcome of our OpenPrinting Micro-Conference on the Linux Plumbers 2021 on Sep 20, 2021 (see Michael Sweet's slides) we will proceed with the development of CUPS as follows: CUPS 2.4 Feature highlights: Official AirPrint/Mopria printer sharing support OAuth support Explicit container support (Snap for now) pkg-config support Deprecated cups-config and Kerberos (will be removed in 3.0, replaced by OAuth) Release schedule: Beta in the end of September 2021 Release Candidate in October 2021 2.4.0 in November 2021 Patch releases every 2 months from January 2022 on 2.4.1 or 2.4.2 in Ubuntu 22.04 LTS Release Manager: Most probably Zdenek Dohnal (RedHat) CUPS 2.5 Feature highlights: OAuth support in cupsd OAuth callback for desktop - D-BUS API - Good for containers to do it with DBUS-API TLS/X.509 improvements Centralized localization - OSes usually have their own localization services Other container technologies - Docker, AppImage, Flatpak Release schedule: Beta in the end of September 2022 Release Candidate in October 2022 2.5.0 in November 2022 Patch releases every 2 months from January 2023 on 2.5.1 or 2.5.2 in Ubuntu 23.04 Release Manager: Most probably me (Till Kamppeter) 2.5.x is probably the last 2.x. CUPS 3.0 Feature highlights: 100% free of PPDs! New architecture of separate modules: Command line utilities: lp, lpstat, lpadmin, lpinfo, ... Local server: Runs as normal user, only temporary/virtual (auto-generated queues) pointing to IPP printers/Printer Applications, spooling filtering, only on domain sockets, D-Bus (protocol similar to CPDB backend, merge with it?) Sharing server: Runs as root, only permanent queues, web interface, network, accounting CUPS library, to be used by all the components above Release schedule (development together with 2.5): Beta in March 2023 3.0.0 in October 2023 Ubuntu 24.04 LTS is the first PPD-free Ubuntu! Currently released is 1.28.10. Current development work is finishing up, testing, debugging this year's GSoC student projects, improving and optimizing the rules for mapping job IPP attributes to PPD option settings, and smaller feature needs appearing during the CUPD driver retro-fitting work (but most is already done for this). Now we also need to clean up and sort out things to be able to do a first 2.x release of cups-filters. Merged Pratyush Ranjan's Pull Request for converting the texttotext CUPS filter into a filter function. Now the filter function conversion work is completed! Make cupsRasterParseIPPOptions() work correctly together with printers with PPDs, especially to not mis-interprete the weird \"Resolution\" variant choice names of Gutenprint (like \"301x300dpi\"). Clean \"Eastmak Kodak Company\" to \"Kodak\". In IPP-attributes-to-PPD-options auto mapper rules considering “ColorMode” also with prefix (like “cupsColorMode”) now. Fixed PPD URIs when generating dynamic PPDs, so that they do not depend on the absolute path of the dyanamic PPD generator. Deal with too large custom page size limits in PPD files when creating PPD cache Also several minor bug fixes were done. Michael Sweets PDF file handling library PDFio is a good candidate to replace QPDF in cups-filters, to eliminate the need of C++ and therefore make the code easier to maintain. I discussed this with Michael on the Linux Plumbers and we discovered that two important features were missing and he suggested me to post feature requests: Generate streaming output (vs. file output) (Feature requst, already implemented) Flattening filled interactive PDF forms and annotations in PDF files to get a static PPD file with fields filled (Feature requst, Michael is investigating) Ubuntu Impish Indri (21.10) will come with cups-filters 1.28.10. The CUPS Snap currently uses 1.28.10. The Printer Application Snaps use the current GIT master of cups-filters. Currently released is 1.1b2. After this release mainly only bug fixes and additions for Windows compatibility got added. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-October-2022",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - October 2022",
+ "url": "/OpenPrinting-News-October-2022",
+ "headings": [
+ "Today is Release Day, of Ubuntu 22.10 (Kinetic Kudu)!",
+ "Ubuntu Summit 2022",
+ "Google Summer of Code 2022",
+ "Common Print Dialog Backends 2.0",
+ "CUPS Snap and snapd printing interface",
+ "Approaching cups-filters 2.0",
+ "pappl-retrofit",
+ "OpenPrinting web server",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "snippet": "Ubuntu 22.10 Kinetic Kudu, Ubuntu Summit, GSoC 2022, CPDB 2.x, \"cups\" snapd interface, cups-filters 2.0, retro-fitting Printer Applications, foomatic-db daily snapshots, PAPPL 1.2.3",
+ "content": "It is not yet switching to the New Architecture for printing and scanning, but has a lot of nice new features, mainly GNOME 43 with a new quick settings panel, Ubuntu Desktop section in System Settings, Nautilus and System Settings with window layout adapting to the window size, improved dock, ... Also the audio stack is based on the new PipeWire which has less bugs than the old PulseAudio and makes especially Bluetooth audio devices work more reliably. To learn more about the new Ubuntu release, watch tomorrow's Desktop Team Indaba about the Kinetic Kudo release. Heather Ellsworth will receive Philipp Kewisch, Adam Szopa, Oliver Smith, and Ken VanDine from Canonical to tell about the new features of Ubuntu itself and Rudra Saraswat from Ubuntu Unity, which got official flavor with 22.10. And as always, if you are watching live via YouTube or Twitch, you can use the chat facility to ask questions. Update: Ubuntu blog about 22.10 There are less than 3 weeks now until the first Ubuntu Summit! And you really should come to Prague and attend it. There are a lot of good reasons. Update: The exact schedules are available now!! All sessions in the Ballroom (plenary room) will get broadcasted/streamed live and recorded, all sessions in the breakout rooms (Karlin 1-4) will get recorded, workshops (Palmkova 1, 2) are interactive, hands-on sessions and so remote participation does not make much sense. Therefore they will not get recorded. But if you come to Prague, have your laptop (with EU plug adapter) handy if you want to attend one or another workshop. Call for Proposals has ended Two weeks ago, the call for proposals has ended and we got a lot of exciting submissions! Nearly all the submitters got already informed whether their proposal got accepted or not, and now a part of the organization team is solving the difficult puzzle of scheduling all the workshops (90 min, interactive), talks (50 or 25 min), and lightning talks (10 or 5 min) into 7 rooms and 3 days. Especially important is to fulfill the many dependencies between the sessions, not only that 1 speaker cannot present in 2 rooms at the same time, but also that a talk about a given subject has to be delivered before the workshop of the same subject or the workshop for the basic knowledge of a subject has to come before all the advanced-topics workshops ... And if you really cannot make it to this exciting event, there is some limited remote access to it, too. All the sessions happening in the plenary room (the largest of all the rooms) are broadcasted and one can ask questions via chat (like on the Ubuntu Indabas). Unfortunately, we cannot have remote live speakers and we cannot broadcast the sessions in the breakout/workshop rooms (and for the workshops it does not make much sense to attend remotely anyway). OpenPrinting is in Prague, too Yes, we are always in need to extend our developer, designer, document writer, ... community and the Ubuntu Summit is all about that kind of community. Therefore we will present our activity, our plans, and our needs in the session OpenPrinting - Join the team to make printing just work! Update: Wednesday, Nov 9, 14:00 - 14:50 CET, Karlin 2 There I will be accompanied by Zdenek Dohnal from Red Hat, Johannes Meixner from SUSE, and Deepak Patankar, former GSoC contributor and now mentor, presenting about their contributions and their integration in OpenPrinting. And after our presentations, we have an extended questions and discussion part. Depending on the room where this session will take place, we can also connect Aveek Basu from OpenPrinting and one or another (former) GSoC contributor. And if there is more discussion time needed, we can create spontaneous BoFs to continue the discussion. Unfortunately, I was not able to get BoFs pre-scheduled. We also will help all these attendees who have relatives or friends who are still stuck in Windows (and also WSL developers who need to boot into Windows for testing), to make their old printers working again. I will show in a 10-min lightning talk that one can easily run our Printer Application Snaps in WSL under Windows, as described in our HOWTO. So do not miss Save Legacy Printers under Windows with WSL and Printer Applications Monday, Nov 7, 17:40 - 17:50 CET, Ballroom Carlos Nihelton, author of the HOWTO, will also be present. Let's build a plotter! Tired of listening to four people talking about paper I/O? Do you prefer to do it with your own hands? No problem, Daniele Procida, director of documentation at Canonical, has created a DIY plotter made out of parts for ~12.50 EUR, the Brachiograph, and in the workshop Let's build a pen-plotter Tuesday, Nov 8, 16:00 - 17:30 CET, Palmkova 1 he will teach the attendees to build such a plotter by themselves. Control unit for the device is a Raspberry Pi, and the device itself consists of cheap servos, clothes pegs, paper clips, wood sticks, and a pen. And did you remember that refills for commercially available printers are usually expensive? For this device the refill is free, you find it all over the conference hotel ... I will attend the workshop and report about it next month ... Your application everywhere, just in a Snap! Or are you developer of a free software application and need a way to easily distribute it to as many users as possible? Without need of the goodwill of distribution package maintainers, without the requirement of your users to install the newest version of their distro in order to get the newest version of your application? Without you needing to test your application on 10 or more different distros and platforms? And as a little extra, your application can also be used easily under Windows, via WSL, without you needing to ever touch Windows for testing it. The solution is to package your application as a Snap (we also say \"snapping it\") and put it up in the Snap Store. The basic idea is similar to smartphone applications in the App Store or Google Play Store, its origin is even in the good old times when Canonical was developing a smartphone running Ubuntu Touch. The Snap is an encapsulated, distribution-independent package containing everything what it needs and which can be easily installed in many OS distributions, like a smartphone app. And even system services can be distributed as Snap, like CUPS and our Printer Applications. Do you want to learn how? Then do not miss our series of Snap tutorial workshops. In each workshop one topic of snapping applications is treated and they are not simply talks, but hands-on workshops. You bring your laptop and do the exercises and examples by yourself! And we will answer your questions ... Intro panel session: Your application everywhere, just in a Snap! Monday, Nov 7, 14:30 - 15:20 CET, Karlin 3 Following workshops are available: Snapping like Hell(sworth) Monday, Nov 7, 16:00 - 17:30 CET, Palmkova 2 The basics of snapping, for everyone who is new to Snap ROS Deployment Workshop Tuesday, Nov 8, 14:00 -15:30 CET, Palmkova 2 Also for those who are new to Snap, but here Snap is used for IoT/Robotics Daemon Snapper's Workshop Wednesday, Nov 9, 11:30 -13:00 CET, Palmkova 1 Snapping of system services and utilities Snapping Desktop Applications Wednesday, Nov 9, 14:00 -15:30 CET, Palmkova 2 Make Snap packages of GUI applications, based on either GNOME/GTK or KDE/Qt Deploying Flutter apps on Linux Desktop Wednesday, Nov 9, 14:00 -15:30 CET, Palmkova 1 Snapping Flutter-based applications Note that if you have no knowledge about Snap, you should first attend one of the first two workshops before you dive into the advanced topics of the other three. And to get some deeper knowledge, there are also many talks about Snap available. And do not forget to bring your board games, gaming-related tinkering, and your knitting projects (life jackets are supplied, though)! And there is no conference without social events/evening events. On the Ubuntu Summit we will have: Sunday, Nov 6, 18:30 CET: Sunday evening reception - Many of us arrive already on Sunday, so meet and greet, get your badge, and avoid the lines on Monday moring. Monday, Nov 7, 20:00 CET: Kinetic Knitter's Session - Knitting together, bring your project (Knitting needles are allowed in your carry-on) Tuesday, Nov 8, 19:00 CET: Gaming night - Games, games, games, both analog and digital! Bring your board/tabletop/card games but also your gaming-related tinkering projects, (like Raspberry Pi for retro-gaming). We have many tables for playing and also monitors, keyboards, mice, and a projector for bringing your digital gaming contributions onto the large screen. Wednesday, Nov 9, 20:00 CET: Closing party on a boat - To celebrate the (hopefully successful) completion of the first Ubuntu Summit. And we are not docked, we are actually cruising. I hope to see you all in Prague and not that you will read here next month what you have missed ... For the first time we are in the forth month of coding, as all the OpenPrinting projects got extended by at least 4 weeks. The 4 projects extended by 4 weeks have ended now and all the contributors have passed. Links to the work products are below. In our GNOME Control Center sub-team (Mohit and Shivam) we have no news from the UX/UI design team from GNOME, but I have reported the UX design needs inside Canonical and it will get worked on them in the development cycle for Ubuntu 23.04 (the design work will naturally also get upstreamized). And now we have forth editions of the contributor's little summaries (and results/work products if available): Converting Braille embosser support into a printer application
Contributor: Chandresh Soni
Mentors: Till Kamppeter, Samuel Thibault
Work Product PASSED As now our gsoc work have been submitted i have created the printer apllication which is now working with detecting various printer using web interface. raw printing can be done using printer application for format such as .brf .ubrl, and debugging is going for filter conversions. Adding Common Print Dialog Backends (CPDB) support to existing Print Dialogs
Contributor: Gaurav Guleria
Mentors: Till Kamppeter
Work Product PASSED I have added CPDB support to the Qt print dialog after discussion with the Qt development team and opened a merge request: https://codereview.qt-project.org/c/qt/qtbase/+/437301. I have also fixed some bugs with the CPDB backend of the GTK print dialog. Discussion with the Qt upstream developers on their mailing list: Initial post, thread \"Adding CPD support to Qt print dialog\" Merge request for CPDB support in the Qt print dialog: Qt Merge Request #437301 Merge request for CPDB support in the GTK print dialog (a lot of discussion with maintainer Marek Kasik has happened here): GTK Merge Request #4930 Scanning Support in PAPPL with eSCL Support
Contributor: Rishabh Maheshwari
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
Work Product PASSED I have completed developing the functions required for the eSCL parser and I have defined the data structures and helper utilities to use them. Along with Deepak, we will successfully implement a scanner application which uses eSCL protocol. Add Avahi calls for discovering and resolving driverless IPP printers and Optimize the processes
Contributor: Sachin Thakan
Mentors: Till Kamppeter, Michael Sweet, Deepak Patankar
Work Product PASSED Last month I worked on driverless utility. I have completed the new implementation for service discovery which removes ippfind as a dependency for discovering ipp/ipps printing devices and uses avahi APIs directly. It also includes optimization of the discovery process, which is only resolving relevant services but not all browsed services. Currently, I am working on moving this optimization logic to a commonplace similar to other avahi APIs. Scanning Support in PAPPL
Contributor: Deepak Khatri
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
(See Rishabh Maheshwari) GNOME Control Center GUI for discovering non-driverless printers and finding suitable Printer Applications for them
Contributor: Mohit Verma
Mentors: Till Kamppeter, Michael Sweet, Pranshu Kharkwal, Divyasheel, Deepak Patankar
Work Product (preliminary)
I have completed the work of implementing the functionality for querying the OpenPrinting web server to get the details of supported Printer Application. The list of supported apps are displayed in a window which has the most appropriate app preselected along with a \"Recommended\" tag. With the work on our request on adding IPP operations to request discovered devices and available drivers from Printer Application as the server completed , we will now be able to make IPP requests to discover devices and add them . This also means that from G-C-C we can now make IPP requests for adding a device. I will be moving ahead and updating the method of discovery of devices of Printer Application by creating IPP requests to Printer apps. I will also be expanding the cups-pk-helper DBUS interface to get details of Printer Apps in G-C-C via a DBUS call. With this, we will complete the functionality of Adding a new printer in a Printer App, along with opening their web interfaces from G-C-C. Further discussion happened on Mohit´s issue report: GNOME Issue report #1878: Allow to add new printers via Printer Applications cups-pk-helper changes: cups-pk-helper PR #7: Added discovery of Printers via lpinfo, PAPPL and Printer Applications Create new printer setup tool for the GNOME Control Center
Contributor: Shivam Mishra
Mentors: Till Kamppeter, Pranshu Kharkwal, Divyasheel, Deepak Patankar
Hi, I have completed the integration of functionality of listing available IPP services with the GUI functionality of managing IPP multi function devices using IPP system service and also done with fine tuning of the hybrid module. Currently I'm working on integrating Mohit's work of getting details of discovering devices to add them. Feature requests so far: #1877: Improve setting of IPP options #1879: Do not show setting of drivers for IPP printers #1911: Printers: Make adminurl available for IPP printers While our GSoC contributor Gaurav Guleria is working on adding CPDB support to the print dialogs (see above) he has continued to do fixes and improvements on the CPDB framework itself: Fix for new requirement of glib that the glib headers should no longer be included inside extern \"C\" { ... } blocks (PR #11) Fixes for code reliability, like crash guards, function reporting success/failure, ... (PR #12) In the discussion on the merge request for CPDB support in the GTK dialog, Marek Kasik asked about how tto handle translations of option/choice names and here I suggested that they should be provided from CPDB (and the CPDB CUPS backend takes them from CUPS) and Marek Kasik agreed with that. I also presented the API functions of cups-filters to obtain these strings, which the CPDB CUPS backend could use. Gaurav Guleria will now work on the implementation. The API in cups-filters is implemented in the files cupsfilters/catalog.[ch] and it uses the translation tables of CUPS, which also contain the strings for all standard IPP attributes and their enumerated values, and it also can obtain printer-specific strings from a printer via IPP. I had originally designed it for the PPD file generator for driverless IPP printers which is used by cups-browsed and by the driverless utility. I am also thinking about later creating a separate IPP strings/translations project on OpenPrinting which collects translations via Weblate (we are already using Weblate for system-config-printer). Also this functionality to provide human-readable strings and their translations will get included in the 2.0 release of the Common Print Dialog Backends. CUPS Snap in the Snap Store Last month we told here that there is a bug in snapd due to which seeded Snaps (being part of the standard installation/ISO image of the OS) cannot use the cups interface (and have to stay with cups-control for now. There will be no rush to fix this bug. Instead, we have planned to let snapd handle the dependency of the cups interface on the CUPS Snap internally to not need the pseudo-content interface any more and that to be implemented within the Ubuntu 23.04 development cycle (before Feature Freeze mid-February 2023). This also does not only work around the bug but pone also needs to only plug cups in snapcraft.yaml, no additional section for the dependency on CUPS is needed. But note that the bug really only concerns the Snaps contained in the standard installation of Ubuntu, if you Snap your application, you can use the cups interface for printing without any problems. We get even closer now. I have done most of the cleaning up of all the code to get a unique coding style and to make it more readable, as described last month. This has now be done for the complete libcupsfilters, libppd, and for foomatic-rip. When the complete code is cleaned, the current cups-filters project will be split into several parts, similar to CUPS on its transition to the 3.x series. There will be the following parts: libcupsfilters: The central library with the filter functions and some useful functions for printer drivers, human-readable strings and translation handling for IPP attributes, ... It does not contain any support for PPD files. libppd: PPD file support library providing the complete support for PPD files from libcups (2.x and earlier), the CUPS PPD compiler and utilities (ppdc) and functions to convert PPD Options into IPP attributes, to add PPD file support to the filter functions of libcupsfilters, to handle collections of PPD files, ... This library is only for legacy PPD and driver support, it should not motivate anyone to create new PPD files! cups-filters: Legacy CUPS filter/backend executables for CUPS 2.x and earlier. Uses both libcupsfilters and libppd. Any XXXtoYYY filters, foomatic-rip, driverless, ... braille-printer-app: The Braille embosser driver code plus Chandresh Soni's GSoC work to turn this code into a Printer Application. cups-browsed: Daemon to automatically create local print queues for network printers and remote CUPS queues and allows to create printer clusters. Will be turned into a Printer Application later (GSoC project?). libcupsfilters is completely free of PPD file support, same for braille-printer-app. libcupsfilters can be used for all kinds of Printer Application and wherever print data or scanned data has to get converted. The Braille Printer Application is a native Printer Application, it does not use PPD files internally. libppd contains the complete PPD file support for Printer Applications which retro-fit PostSctipt PPD files or classic CUPS drivers. These Printer Applications are usually created based on pappl-retrofit. Distributions using the New Architecture for printing and scanning will not install libppd by default, as it is not needed any more. cups-filters provides the filter executables needed by CUPS 2.x or earlier. Most executables are just simple wrappers and all the internal workings have moved into the filter functions in libcupsfilters, and the PPD file support into libppd. This package requires libppd, but it is for PPD-based classic CUPS versions only anyway. cups-browsed is currently supporting and generating PPD files (for CUPS 2.x), and therefore also depending on libppd. In a later version, when it is turned into a Printer Application, the PPD file support be removed. An important goal of the separation is to put all PPD support in their own project so that they can get discontinued later and this way we can easily stop maintaining the PPD file support code will all the other useful code of the former cups-filters will live on. libfontembed is merged into libcupsfilters now as it is only used by the cfFilterTextToPDF() filter function, really nowhere else, it has also no package which depends on it in Ubuntu (neither in Main nor in Universe). Its code (a lot for being a part of the texttopdf CUPS filter GSoC project) has also a lot of TODOs, so it probably is not ideal for general use but serves well in the text filter function (commit). As a last change/improvement in the functionality I moved the filter functions for calling external filter executables back from libppd to libcupsfilters (now with the name cfFilterExternal() and ppdFilterExternalCUPS() being a wrapper), as it is also useful in native printer applications, as it allows using filters written in non-C languages or proprietary, closed-source filters. Also added support for System V interface scripts to the function (they are similar to CUPS filters but take input from named file, not from stdin). This was inpired by the work of GSoC contributor Chandresh Soni on the Braille Printer Application where he needs to embed shell-script filters into the native (not using PPD files) Printer Application (commit). Also several smaller fixes got done, like removing some unneeded, leftover portability code files commit and header files (commit). libcupsfilters needs the new Ghostscript 10.00.0 now. This got reflected now in the README file and in comments in the source code (commit). cupsfilters/catalog.h received a comment telling where the human-readable and translated strings for the IPP attributes and enumerated values come from. This information was only in ppd/ppd-generator.c (commit). There was also a bug report about pages in custom sizes rotated by 90 degrees for fitting the orientation. This came from the fact that Ghostscript's built in CUPS/PWG/Apple Raster output device tries to match the given page size dimensions with the ones of the PPD file, even if the size is custom. I have fixed this by not matching the page size dimensions against the PPD if the size is custom (commit). Michael Sweet released PAPPL 1.2.3 with a correction for string-type user-settable options (passwords, fax numbers, ...). With this and after getting some help from him I am noe able to do the Printer Applications without patches on PAPPL and pappl-retrofit! I updated pappl-retrofit and the Printer Applications appropriately (commit). I also updated all the 4 retro-fitting Printer Applications for last API changes in cups-filters (Merged libfontembed, cfFilterExternal() in libcupsfilters, see above) and updated the included Ghostscript to version 10.00.0, which has especially a faster PDF renderer and latest support functionality for PPD-less printing. Michael Swwet also added a feature to auto-select the A4/Letter default by locale and earlier there was already support for localization/human-readable strings and SNMP-based ink-level checking. So now I have everything to be able to get all my planned features into pappl-retrofit and the retro-fitting Printer applications, but cups-filters 2.0b1 first ... On the OpenPrinting web server the daily snapshots of foomatic-db are back, s it is easy again for distributions to package foomatic-db. Thanks a lot to Violet Kurtz from the OSUOSL for implementing this! From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|87811| |ipp-usb|ipp-usb|2956| |ps-printer-app|PostScript Printer Application|2595| |ghostscript-printer-app|Ghostscript Printer Application|1967| |hplip-printer-app|HPLIP Printer Application|6097| |gutenprint-printer-app|Gutenprint Printer Application|4911| Currently released is 2.4.2. There will be further bug fix releases in the 2.4.x series. Some bug fixes were done during the last month, see changes below. Ubuntu Kinetic Kudu (22.10 got released today with 2.4.2. The CUPS Snap (in the Edge channel) and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master of CUPS. The CUPS Snap in the stable channel is version 2.4.2. Currently released is 1.28.16. The restructuring of the code to separate the siamesian twins of the filter functions and PPD file support is completed and we also have done a lot of testing and bug fixing. Now we are finally polishing the coding style and updating the license/copyright headers for the 2.0.0 release. See above for more details. As cups-filters 2.0.0 will not make it into Ubuntu 22.10 we have continued with further bug fix backport releases in the 1.x series. Ubuntu Kinetic Kudu (22.10 got released today with 1.28.16. The CUPS Snap is currently locked to the /e496badbf2 commit (from May 20) of cups-filter's GIT master (2.x) until the restructuring gets more tested. The Printer Application Snaps use the current GIT master of cups-filters and so are the first application for real-life testing. Currently released is 1.2.3. In the last months the development of the 1.3.x series has already started. See changes below. 1.2.3 General bug fix release. See changes below. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-October-2023",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - October 2023",
+ "url": "/OpenPrinting-News-October-2023",
+ "headings": [
+ "Ubuntu Summit 2023 in Riga",
+ "Google Summer of Code 2023",
+ "CPDB CUPS backend Snap",
+ "libcups3 support",
+ "CUPS 2.4.7",
+ "PAPPL 1.4.2",
+ "libcups 3.0b2"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/-fx_T4GIsX4/hqdefault.jpg",
+ "snippet": "Ubuntu Summit 2023 in Riga, GSoC 2023, CPDB CUPS backend Snap, libcups3 support, PAPPL 1.4.2, CUPS 2.4.7, libcups 3.0b2",
+ "content": "Probably many of you are using a modern driverless multi-function printer and scanner device, and it does not only print but also scan perfectly on your Linux system, or you have your driverless printer connected via USB and it also just works without any device-model-specific driver. This works especially thanks to Alexander Pevzner's excellent voluntary work of creating the IPP-over-USB daemon ipp-usb and the SANE backend sane-airscan for driverless scanning with both the eSCL and the WSD standards. For a longer time he has been very busy with other things and so he was keeping his OpenPrinting work in \"maintenance mode\", but now he showed up again and worked on some issues in CUPS and cups-filters. And he has also written an amazing article (Original, Google-translated to English) about his work, how he got into it, and especially praising me for my cooperation with him. And thanks a lot to Anton Gladky, without his hint on the DebConf2023 I had never got note of it. Some days ago, Alan Pope (\"Popey\"), a former colleague of mine at Canonical, and owner of the ubuntu.social instance of Mastodon, posted on Mastodon asking for help which printer to buy. I read the busy thread and answered several times, telling about OpenPrinting's list of driverless printers, confirming that the Xerox somebody else suggested is actually on the list, warning about (mainly HP and Canon) printers which stop scanning when they run out of ink/toner, ... Confirmed by most people answering down the thread it turns out that currently Brother is the best choice, and there especially laser printers. These are reliable printers which perfectly work as driverless IPP printers and scanners with all operating systems and devices, and especially they seem just to be designed to do their job of printing and scanning and not to suck lots of money out of the users by making them buying lots of over-expensive ink and toner. Especially I found another thread about a purchase of a color laser multi-function printer from Brother and also answered there, telling that we have currently 657 Brother printers on our list and this answer was my most successful Mastodon post! 21 people favorited and 16 people boosted my post! And here is a YouTube video where someone is showing how to set up printers with YaST (SUSE) but there is something wrong with it ... Just watch the video, read the description only afterwards... So let us now start with what we did at OpenPrinting in October ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. The Summit is coming close, I am already in Riga since yesterday and today at 2pm EET (CET) it will actually start. A lot of exciting stuff is waiting there in 5 rooms for 2.5 days. And there will be also a surprise! The best of all is that one will meet each other again, like last year on the Ubuntu Summit 2022 in Prague in these 3.5 days (many arrived early, to enjoy Riga, get rid of jet lag, have a margin for flight delays, attending the Canonical-internal Sprint before the Summit ...). And on the conference itself I will give my third Snap workshop! It is Improving Snap maintenance: Automating tag updates on new upstream releases of the app On Saturday, November 4, at 12:00 - 13:00 EET in Beta 2 It is all about having your Snap get automatically updated in the Snap Store when any of the underlying upstream projects issues a new release. This helps users of Snaps to always have the latest and greatest versions of their apps. It is an easy-to-apply GitHub action/workflow, developed by Heather Ellsworth who was in Canonical's Desktop Team, in the Snap Squad. If you are developing an application and snapping it or are snapping applications for developers who do not snap by themselves (like the Snapcrafters do) you should not miss this session, as applying the automation will ease youe life. If you want to attend it, to make use of the time (60 min) efficiently, I want to ask you to download the slides and follow the instructions under \"Setup\", so that you have forked the example GitHub repositories. Also it is easier to do the exercises when having the slides at hand to browse and copy-and-paste. By the way, I plan to apply the method also on the OpenPrinting Snaps. Especially the Ghostscript Printer Application with its ~20 parts will benefit a lot from it. But it will us also get an Ubuntu Core Desktop with always up-to-date printing stack. And do not think that this will be an Ubuntu Summit without any OpenPrinting session, GSoC contributor Akarshan Kapoor will tell about his GSoC work on scanning support in PAPPL in the talk ScaniVerse: A New Horizon in Unified Scanning for Linux Systems On Sunday, November 5, at 11:30 - 12:00 EET in Sigma Akarshan presents his work on scanning support of this summer, the addition of scanning support to PAPPL to be able to make scanner drivers available as Scanner Applications, emulators of deriverless scanners (PAPPL PR #249), the retrofit of SANE drivers (GitHub repo), and his new MetaScan (GitHub repo). I will be in the room with him and help answering the questions. There are a lot of great sessions to choose from, often several in parallel in different rooms. To help attendees through all this, the schedules display, nicely hacked by Canonical's Community Team manager, Philipp Kewisch, has a facility that you can mark interesting sessions with a star. These will get listed under \"My Conference\" in chronological order then, so that you do not miss what you plan to attend. I have marked up to now (only to get an inspiration, not sure whether I will attend them all): From origins to open source: The journey of DreamWorks Animation's production path tracer, MoonRay, Randy Packer (DreamWorks Animation), Fri 11/3, 15:00 EET Introducing Ubuntu Core Desktop, Ken Vandine (Core Desktop development lead, Canonical), Oliver Smith (Product Manager Desktop, Canonical), Fri 11/3, 16:30 EET Alioli ROV Submarine Drone, Juanmi Taboada, 11/3, Fri 17:00 EET What It's Like to Build an Open, Repairable Laptop, Daniel Schaefer (Framework Computer), Sat 11/4, 9:00 EET Windows Subsystem for Linux (WSL) - Make an awesome Linux environment directly on Windows, Craig Loewen (Microsoft), Sat 11/4, 9:30 EET Feature detection for games, letting machines figure out system requirements, Mathieu Comandon (Lutris), Sat 11/4, 11:30 EET Container craftsmanship: from a Pebble to a ROCK - Interactive Workshop, Cristovão Cordeiro (Canonical), Sat 11/4, 14:00 EET Dark matters: The security abyss of distroless containers, Cristovão Cordeiro (Canonical), Sat 11/4, 16:00 EET Snapshot in time: Leveraging Snap and Flatpak to preserve our software legacy, Mathieu Comandon (Lutris), Sat 11/4, 16:00 EET How to launch an open source software?, Ömer Faruk Aydin, Sat 11/4, 16:30 EET Join the RISC-V revolution, Heinrich Schuchardt (Canonical), Sat 11/4, 17:00 EET Skynet or Star Trek, what’s the future of AI? - Panel session, Graham Morrison (host, Canonical), Andreea Munteanu (Canonical), Craig Loewen (Microsoft), Frank Karlitschek (Nextcloud), Juan Luis Cano Rodríguez (QuantumBlack, AI by McKinsey), Pablo Ruiz-Múzquiz (Kaleidos/Penpot), Sun 11/5, 9:00 EET ScaniVerse: A New Horizon in Unified Scanning for Linux Systems Akarshan Kapoor (Indian Institute of Technology, Mandi, India), Sun 11/5, 11:30 EET Bringing Windows applications to Linux app stores, Merlijn Sebrechts (Ubuntu Community Council, Snapcrafters), Sun 11/5, 12:00 EET Open Source for Sustainable and Long lasting Phones, Luca Weiss (Fairphone), Sun 11/5, 12:00 EET Behind the Scenes of tox: The Journey of Rewriting a Python Tool with Over 10 Million Monthly Downloads, Jürgen Gmach (Canonical), Sun 11/5, 14:30 EET Linux Lads live podcast recording, Shane Kitt (Linux Lads Podcast), Sun 11/5, 16:00 EET In addition to these lots of awesome talks and workshops and hopefully also a great hallway track, there are also 3 evenings and on all these there will also be events not to be missed. On Friday, right after leaving the last session at 18:00 EET in the hallway between the conference rooms you will directly be on the first one, the Welcome Reception/Opening Mixer Have some after-session chat with appetizers and form groups to have dinner in the nice old town of Riga afterwards. Saturday evening, from 20:00 - 23:00 we will be gaming like hell in the Gaming Night In the 2 workshop rooms (Beta 1 & 2) opened up to one we will play board games, video games, Foosball, and Air Hockey. And you can contribute: Bring your board games, gaming consoles, and other gaming devices!! Also on Saturday there will be a Special Demonstration What exactly, will be told through the event. There are 2 sessions of it, at 21:00 and 22:00, room to be announced. And after two and a half days of amazing, exciting, eshausting, ~~boring~~, ... talks and workshops, we will celebrate the success of the second Ubuntu Summit on the Closing Party on 19:00 - 23:00 EET in the Digital Art House, walking distance from the venue (so no party buses). Drinks and a dinner buffet will get served. So see you in Riga! Or attend remotely via live streams and recordings. And keep up-to-date via Mastodon: #UbuntuSummit, #UbuntuSummit2023 Now we are close to the end. Having extended the deadline for all the now 5 OpenPrinting contributors it is time to write the final reports. Their deadline is Nov 6, Monday next week. Due to his participation in the Ubuntu Summit Akarshan Kapoor already finished one week earlier and so his report is already posted. He succeeded with the addition of scanning support to PAPPL and so we will soon see first Scanner Applications. And from Kushagra Sharma, GSoC contributor on CPDB support in the print dialogs I got a last write-up before the end of the GSoC: Implementation for CPDB pkg config support is completed which allows autoninja to set flags for CPDB allowing its import into the system. Currently implementing all the virtual functions for print backend as of now I am able to display all thé available printers for different print backends on the print dialog using CPDB, working on fetching their print capabilities and semantics. This will conclude CPDB support for print dialog in chromium. Thanks Till Kamppeter and Gaurav Guleria for all the support, I hope we keep working on CPDB and one day all software use CPDB for print dialog. Next month I will post an overview with links to all the final reports. And I was in Sunnyvale at Google on the Mentor Summit meeting my fellow mentors again, especially also Deepak Patankar, who was lucky to get a spot through the waitlist. The event was smaller than the 2018 edition which has taken place in the same location, as each mentoring organization got only one guaranteed delegate spot and not two. But nevertheless it was still fun. Especially I have given a 3-min (!) lightning talk about the participation of the Linux Foundation and the Opportunity Open Source in the IIT Mandi. It was in one of two sessions where every mentoring organization could give a brief presentation about something interesting or important, usually success stories about exceptional contributors. So mine was somehow different, but in some form also a success story of a contributor, of Akarshan doing the excellent local part of the organization of the event ... And even quicker was the self-presentation of each of the 175 attendees. We only could use 4 words! I used OpenPrinting - Snap - Ubuntu - Community. But the rest went much more easily, mostly hallway chat but also the un-conference, BoF-style sessions planned on the spot. Two boards, one for each conference day, with squares for each hour and each of the 5 rooms where people could post a paper announcing their session. No pre-planning, no CfP. A little like the Ubuntu Developer Summits many years ago. In addition, I departed to the US two days earlier, to not miss the event if flights are late or canceled, to have the jet lag go down a bit, and also to have a short touristic visit in San Francisco, and luckily enough, on the evening before the Mentor Summit, there happened the Annual Celebration of the Internet Archive, a great organization conserving everything which appears on the internet, even if popping up only shortly, and making it available via the Wayback Engine, preserving a lot of history. I met also some of the Mentor Summit attendees that evening, especially Robert Kaye from Metabrainz/Musicbrainz who works closely together with the Internet Archive. To complete the printing stack in the all-Snap experience of Ubuntu Core Desktop we still need one more Snap, the one of the CUPS backend for the Common Print Dialog Backends (CPDB). This is needed as all the application's print dialogs also need to get switched over to the New Architecture of not having PPD files any more, but instead, IPP print destinations. And exactly this we have implemented in the CPDB backend for CUPS, and now making the dialogs using CPDB we will make them not only working with the upcoming CUPS 3.x and with the CUPS Snap, but also assure that they stay working with further changes in CUPS and also being open for new print services, like for example cloud services. Luckily I was successful with my talk about Snap and Ubuntu Core Desktop and my Snap workshop on the Opportunity Open Source in Mandi, as Biswadeep Purkayastha, one of the candidates for this year's GSoC, attended and stepped up as a volunteer for OpenPrinting. Right after the conference he studied the rest of the workshop (In Mandi I had only 60 min for the workshop which was originally designed for 90 min - 2 hours), my Daemon Snapper's Workshop from the Ubuntu Summit 2022, and Ken VanDine's blog about Ubuntu Core Desktop. Then he asked me what he could do for OpenPrinting and I offered him to snap the CPDB backend for CUPS. He is really enthusiastic about OpenPrinting, especially he ported the cupstestppd utility's core functionality into a library function in libppd (Pull Request #6) and when he got the message of not having been selected for GSoC, he asked me right away what he could do voluntarily and I talked with him about OCI containers and Snap and also about my planned sessions in Mandi. Biswadeep accepted the snapping task and started right away creating the snapcraft.yaml. He asked me when he got stuck and I helped him through several quirks, including libcups2 of CUPS 2.5.x having removed some things which were marked deprecated in CUPS 2.4.x. Later on we both got stuck as the CPDB backend is entering a new area: It is a user daemon, triggered via the session D-Bus (see Ken VanDine's second blog). There is support for such a thing by snapd but it is still considered experimantal and not really well documented, and it only supports a client application to call one pre-defined D-Bus service, not as we have with CPDB that the client (in our case a print dialog) is looking for all suitable D-Bus services (in our case the CPDB backends) which are installed and does not know beforehand which these are (in our case a new cloud printing service with its CPDB backend could appear). So I asked for help on the snapcraft.io forum, but did not get any answer yet, neither from Canonical's snapd and snapcraft developers nor from the community ... So now I will have to make the developers aware in-person, on the Canonical Engineering Sprint, Canonical's internal meeting of their around ~700 engineers, in the week right after the Ubuntu Summit, also here in Riga. Thanks a lot, Biswadeep, for all your great work on this! Michael Sweet is not only deep into the development of libcups3, the CUPS library of the new CUPS 3.x, but he is also already switching PAPPL to it. The current stable release 1.4.2 can be built with either libcups2 or libcups3, the library being autodetected by the ./configure script, and the master branch in the GIT repository which is approaching version 2.0 is even libcups3-only. So Michael seems to be eager to switch us into the New Generation of all-IPP, PPD-less printing as soon as possible and probably also considers Printer Applications as a thing of the New Generation CUPS 3.x world. Akarshan Kapoor has added scanning support to PAPPL during this year's GSoC and posted a Pull Request for its inclusion. As it is a significant new feature it will most probably not be accepted into the 1.4.x series but only into 2.x which would require that PAPPL-based Scanner Applications will háve to use libcups3. As we do not want to only support writing new scanner drivers from scratch but also retro-fit all drivers which are already there, which are SANE backends, we need SANE support and this we want to do in pappl-retrofit where we are already supporting PPD-based legacy printer drivers. But pappl-retrofit also uses the libcups2-based libcupsfilters and libppd libraries, and pappl-retrofit also uses libcups2 by itself. This made adding support for building with libcups3 to the libraries libcuppsfilters, libppd, and pappl-retrofit getting more urgent. Work on libcupsfilters got already started by Gayatri Kapse during the selection process for the GSoC earlier this year (Pull request #24) and as Biswadeep Purkayastha got stuck with snapping the CPDB backend for CUPS I asked him to work on the addition of libcups3 to the libraries. He did all the renamings to the new libcups3 function names and the #defines for converting to the libcups2 names when building with libcups2, taking Gayatri's work and also PAPPL 1.4.x as example and in the end I completed it by doing the more tricky parts. But the worst thing was already done much earlier, copying all PPD file support code into libpppd. This way all the libraries did not contain any calls of PPD-related functions in libcups2 any more. The only code I still had to copy from libcups2 was the code to support the back channel and the side channel for communication between CUPS filters and CUPS backends. I have taken the files cups/sidechannel.h, cups/sidechannel.c, and cups/backchannel.c and copied their content over into the new files pappl-retrofit/cups-side-back-channel.c and pappl-retrofit/cups-side-back-channel-private.h in pappl-retrofit. After that I renamed all the functions, data types, and constants to the scheme of pappl-retrofit. pappl-retrofit builds with either libcups2 or libcups3 now, always using its own copies of the back/side channel support functions. All the libcups3-support-related changes are done now and available in the master branches of the three libraries. They still need more testing before the 2.1.0 releases of libcupsfilters and libppd and the 1.0.0 release of pappl-retrofit. Scanner Applications being forced to use libcups3 instead of libcups2 are no problem at all if they are provided as Snaps or otherwise packaged in some sandboxed format (like Docker/OCI containers). In all these formats each application brings its own dependencies (needed libraries, ...), so the system can use libcups2 while the encapsulated Scanner Application uses libcups3. Even classically installed the Scanner Applications can use libcups3, as libcups2 and libcups3 can co-exist on classically installed distributions, at least if they use DEB or RPM. Even more this works as current libcups3 uses the 3 actually in its name, having the library file libcups3.so.3 and the compiler argument -lcups3. Only disadvantage against using libcups3 is that libcups3 is still in its beta phase, but Michael Sweet's code quality is very high, so it is not such a problem. Michael Sweet has already started the development of CUPS 2.5.x but not stopped releases of of 2.4.x yet. Latest release is 2.4.7 including the fix for CVE-2023-4504 and other changes, like adding OpenSSL support for the cupsHashData() function and bug fixes. List of changes from the original announcement: CVE-2023-4504 - Fixed Heap-based buffer overflow when reading Postscript in PPD files Added OpenSSL support for cupsHashData (Issue #762) Fixed delays in lpd backend (Issue #741) Fixed extensive logging in scheduler (Issue #604) Fixed hanging of lpstat on IBM AIX (Issue #773) Fixed hanging of lpstat on Solaris (Issue #156) Fixed printing to stderr if we can't open cups-files.conf (Issue #777) Fixed purging job files via cancel -x (Issue #742) Fixed RFC 1179 port reserving behavior in LPD backend (Issue #743) Fixed a bug in the PPD command interpretation code (Issue #768) Also PAPPL received a bug fix release, 1.4.2. Fixed potential crash while listing devices (Issue #296) Fixed potential deadlock issue (Issue #297) Fixed loading of previous state (Issue #298) By the way, the 1.4.x series of PAPPL can be built with either libcups2 or libcups3, while the master branch (2.x) is libcups3-only. And last but not least, Michael also released the second beta of libcups3, for more API modernization, improvement, and clean-up. Added the ipptransform command to replace/upgrade the ippevepcl and ippeveps commands (Issue #65) Added cupsFormDecode and cupsFormEncode APIs (Issue #49) Added cupsJWT APIs to support JSON Web Tokens (Issue #50, Issue #52) Added ippAddCredentialsString and ippCopyCredentialsString APIs (Issue #58) Added cupsCreateCredentialsRequest and cupsSignCredentialsRequest APIs and updated cupsCreateCredentials API to better support X.509 certificates (Issue #59) Updated the configure script to add _FORTIFY_SOURCE=3 (previous level was 2) when not using address sanitizer and when it hasn't already been added (Issue #51) Updated the httpAddrListen function to use the maximum backlog value. Fixed ipptool limit on the size of an attribute value that would be printed (Issue #5) Fixed some configure script issues (Issue #48) Fixed JSON output bug in ipptool. Fixed CUPS_DNSSD_IF_INDEX_LOCAL when using Avahi."
+ },
+ {
+ "id": "post:OpenPrinting-News-October-2024",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - October 2024",
+ "url": "/OpenPrinting-News-October-2024",
+ "headings": [
+ "Festa do Software Livre/UbuCon Portugal 2024",
+ "Ubuntu Summit 2024 in the Hague",
+ "4 times in Podcast Ubuntu Portugal",
+ "Google Summer of Code 2024",
+ "New Releases"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/_NMKUHkZ0i8/hqdefault.jpg",
+ "snippet": "5 years of OpenPrinting News, Festa do Software Livre/UbuCon Portugal 2024, Ubuntu Summit 2024, 4 times in Podcast Ubuntu Portugal, GSoC 2024 completed, new releases",
+ "content": "This month we have the 5th anniversary of the OpenPrinting News! For 5 years now, starting October 2019, I have posted here every month, to tell what we are doing at OpenPrinting and what we are planning to do: Our design and development work, new releases, vulnerabilities and security issues, our GSoC participation, conferences we attend and talks we give, what people say and write about us, and also important things which happen in the free software world in general. This is not only useful for those just interested in OpenPrinting, but it also helps us to attract and onboard volunteer contributors and it is an easy way to find out what we have done at which point in time. This facility is unusual for free software projects, probably due to the fact that it requires some work. So far I got only positive feedback, so I will continue. It also probably has potential for improvement, so please tell us your suggestions through the communication channels mentioned below. Last month, I have been on two conferences: The Festa do Software Livre/UbuCon 2024 in Aveiro, Portugal and on the third Ubuntu Summit, in den Haag, in the Netherlands. The Festa was done principally in Portuguese language and my 3 sessions I have given in Portuguese, whereas the Summit is the big community event organized by Canonical, this time with less talks but with booths instead. On the Festa do Software Livre we recorded 2 episodes of the Podcast Ubuntu Portugal and on the Ubuntu Summit another episode, so there are 4 episodes with my participation now. The GSoC has ended and our 11 contributors have all done amazing work to put together our most successful GSoC year. We had never that many contributors and all have actually done code which we can merge upstream. And there were also several new releases at OpenPrinting, starting with the 2.1.0 releases of libcupsfilters, libppd, and cups-browsed to include the fixes for the recent vulnerabilities and updates of libcups3 and PAPPL. Videos of the talks on the UbuCon Asia 2024 and on the Open Source Summit Europe 2024 are available now. See links to the recordings of my talks in the appropriate sections in the August News. So let us see what happened at OpenPrinting in October ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat After 20 years I was again on a a conference held in Portuguese laguage, this time on the Festa do Software Livre in Aveiro, Portugal, a 2-day conference with a main track and several sub-conferences co-located by different open-source organizations: Drupal, Flutter, WikiMedia Portugal, Inêrcia, and the UbuCon Portugal. I followed the invitation of Diogo Constantino. I was departing early in the morning, on the day before the conference started, and when telling to my colleagues in Canonical's Desktop Team, that I am heading to Aveiro, Ana Sereijo, UX designer, spoke up telling me that she came from there. So, as I was arriving in Aveiro at lunch time, I asked her for restaurant recommendations and this way got to an excellent, delicious place for classic Portuguese food. I ate grilled sardines and it reminded me to when I lived in Portugal for a year back in 2007. Diogo and the others of the organizing team was still at their day jobs, so I have finished translating my slides to Portuguese in the afternoon (that is really a lot of work, feels like more than creating the talk in the first place) and met them for dinner. The conference has taken place in the Departamento de Eletrónica, Telecomunicações e Informática (DETI) of the University of Aveiro, in up to 6 rooms, 2 lecture halls and 4 classrooms in parallel. There have been up to 2 plenary tracks and sub-conferences by Drupal, WikiMedia Portugal, Flutter, Inêrcia, and the UbuCon Portugal. Here are the schedules: Festa do Software Livre, UbuCon Portugal I have given 3 sessions, all in Portuguese, as announced last month. On the first day, Friday, I gave my talk about the history and the current work of OpenPrinting, but in Portuguese: OpenPrinting - A boa impressão do software livre Video I have given it in the main track. I ended up talking about how I got into free software, the history of OpenPrinting, our current work on CUPS 3.x including its integration in the desktop, Windows Protected Print, ... for 70 minutes and afterwards did a 14 min Q&A session. I also got some printing-related questions during the coffee breaks on both days. And I did not talk about the recent vulnerabilities and nobody asked me about them during the Q&A (if you want to hear me talking in Portuguese about that, see my Podcast Ubuntu Portugal participation, episodes E321 and E322). On the second day, we had the UbuCon Portugal, where the morning part was all about Snap. First, I gave a Portuguese version of my talk in which I explain what Snap is, how it works and how it is motivated, and about the Snap-only operating systems Ubuntu Core and Ubuntu Core Desktop: Linux para desktop, fácil como um smartphone! Graças ao Snap! Video I also mentioned how the work of OpenPrinting comes into play for Ubuntu Core Desktop and after the talk we had a 20-min discussion about the quality control of Snaps, initiated by an attendee who installed the nextcloud-client Snap and it did not work for him. After a coffee break people could make their hands dirty with snapping by themselves, in an interactive workshop to learn how to package applications as Snaps: O seu aplicativo para todo mundo! Graças ao Snap! - Oficina interativa Video This is the workshop which I have given several times on other conferences, but this time I have given it in Portuguese. After lunch there was a workshop about developing games with Godot (Video parts 1, 2) and after that there was the talk \"Uma história de vida usando Linux e Debian\" (video), José M Calhariz talking about how he got into computers and free software, and in the end, the two graybeards who having told about their free software history throughout the conference have met to make the happy end of the UbuCon. On the two conference days in the evenings, dinners were organized in a nearby restaurant. The first one was to celebrate the Oracular Oriole (24.10) release of Ubuntu and the second was the \"closing party\" of the Festa do Software Livre. We were 10-15 people on each of them, the organizers of the event and some others. Each night we have produced an episode of the Podcast Ubuntu Portugal, E320 and E321, resp. There not only the usual hosts, Diogo Constantino and Tiago Carrondo were speaking, but we all got involved. And Diogo brought for everyone a little rubber duck, and one really hears them often in the two podcasts ... Therefore they got the duck (with a beer bottle cap as hat) as avatar. At the second day's dinner we had also a post-conference meeting talking about what went well and what not so well at the conference and what one can improve in the next edition. And before the dinner Diogo and me exchanged our experience in recording and live-streaming the Festa do Software Livre and the Opportunity Open Source resp. Diogo fell in love with the wireless clip-on mic kits (from Tonor) which I brought (and used several times on the conference) and bought such a kit right when he got home. And we concluded that we need to develop a better method for live-streaming/recording/remote speaking and document it somewhere. Update: Complete session video playlists for Plenary and Workshop rooms and all links to session recordings here point to the individual videos now. Recordings of the conference days in the plenary room: 25th, 26th, 27th Playlists of all session recordings: Plenary room, Workshop room Pictures: Photographers, Photographers Hi-Res unedited, Attendees Aftermovie When I refer to talks or workshops in this section, I always link to the slides, exercises, and recordings, if possible, so if you have missed a session, you can watch it, read the slides, and also do the workshop's exercises, whenever you like. The third Ubuntu Summit in the Hague, Netherlands, was again a success! During the years we made a move from having lots of talks and workshops to making the hallway track the central part of the event. 2022 there were still 7 rooms in parallel (1 plenary, 4 breakout, 2 workshop), 2023 5 rooms (1 plenary, 2 breakout, and 2 workshop), and now there was only the plenary room, 1 workshop room and ... an exhibition consisting of 26 booths! It got much harder to get a talk or workshop proposal accepted, only talks of general interest, breaking news, and with the \"Wow\" effect made it into the conference, special interest topics got discussed at the booths now. Here are the schedules. Before it started As I am part of the organization team of the Summit, as I was in the previous 2 years, too, I had arrived early, already in the afternoon of the 22nd of October, to help on the preparations, together with Mauro Gaspari, principal organizer of the event, and also Aaron Prisk, Jason Nucciarone, and Jesús Soto. These extra days gave me also the opportunity to meet people, also due to the fact that in the week before the Summit the Canonical-internal Roadmap/Product Sprint, to be attended by all the managers, has taken place. So I have especially also met Ken VanDine and some people of Canonical's desktop team. And I also met the non-Canonical Summit attendees of the free software community as they were rolling in. Soumyadeep Ghosh from the Snapcrafters already joined us at dinner of the 23rd, and on the 24th in the morning I went to the hotel where most of the community people were accommodated, principally to prepare for the Snapcrafters booth and the Snap workshops with Soumyadeep, Merlijn Sebrechts, and Lucy Llewellyn from the Snapcrafters. There I met also many others, especially Heather Ellsworth from Thunderbird, Akarshan Kapoor the master of the Scanner Applications, Mathieu Comandon from Lutris, Martin Wimpress (\"Wimpy\") from NixOS, ... And on the 25th, the Summit finally took off ... Last preparations at the venue in the morning, and as soon as the Roadmap Sprint ended at noon, the booth staff from the community arrived and the preparation of the booths started. Many busy people in the main foyer of the venue, the place looking somewhat chaotic, and one started to meet more people. It was originally planned to open the exhibition only after the opening plenary, but the booths got already busy right in the beginning, as the exhibition ground was between the main entrance and the plenary room. Snapcrafters Booth and Workshops I was participating in the Snapcrafters booth, together with Soumyadeep Ghosh, Merlijn Sebrechts, Lucy Llewellyn and so we were also setting up our booth. As I have already run a Snapcrafters booth with Soumyadeep on the UbuCon Asia Soumyadeep had already a slide show for the booth screen where he only needed to update the workshop announcements. Our booth tables were full of Snapcrafters stickers and Origami Snapcraft birds. With the same people I was also participating in the organization of the two Snap workshops: \"Crafting snaps quickstart guide 101\" (Slides, Exercises, Video) and \"How to build and test your snaps automatically using GitHub actions\" (Slides, Exercises, Video) I did not do the presentations themselves, this was done my Soumyadeep Ghosh and Merlijn Sebrechts, but I have given a short introduction telling how the Snap workshops had their roots in my Snap workshop series on the Ubuntu Summit 2022 and the first one being based on Heathers's original workshop \"Snapping like Hell(sworth)\" which was afterwards given on many other conferences, mainly by me but also by Lucy and by Soumyadeep. In the second workshop, in the end of the presentation part, I have also told about our plans to merge the Snapcrafter's GitHub action with the Canonical Desktop Team's GitHub Action. I (and several other Snap experts) have also been in the room to help on the exercises, as these workshops were, in contrary to several others, really interactive. Talks and Workshops During the event I was most of the in the exhibition area, but I also made it into some of the talks and workshops. I attended following sessions, including all those sessions where our GSoC contributors and mentors were the speakers: \"Inkscape for Everything\" by Christopher Rogers (Video) The session was announced as a workshop and had taken place in the workshop room. In the beginning I installed Inkscape expecting that there are exercises, but actually it was only a demo of most of the functionality of Inkscape, which is a lot, allowing for really professional artwork, doing nearly everything which has to do with graphics: Non-destructive photo editing, slides for presentations, ... Christopher tells that if he had given exercises he could only treat a very small part of the whole session's content. \"Live build your submarine step-by-step\" by Juanmi Taboada (Video) Here I was in the good hope to put my hands on some hardware, but, as the Inkscape \"workshop\" this was also only a demo. Juanmi, who brought his remote-operated and free-software-controlled submersible already to last year's Summit explained the free-software-driven hardware-components, showed them and put them together, but there were no extra copies for the audience to try it by themselves. \"Fuzzing in the open: Integrate your project in OSS-Fuzz for continuous fuzzing\" by Dongge Liu, George-Andrei Iosif, Jiongchi Yu (Slides, Exercises, Video) Finally, an actually interactive workshop, but this one was also with my mentoring, as the speakers are no less than our GSoC team for deploying OSS Fuzz on the OpenPrinting repositories, contributor Jiongchi Yu and mentors George-Andrei Iosif and Dongge Liu. Unfortunately Jiongchi could not come to the Summit in-person as he was on another conference in the US. So after a short introduction by me, George Andrei and Donggi were explaining the steps for the attendees to do on their laptops, with the Heartbleed on OpenSSL being the example. Jiongchi was connected via video meeting and in the end he told in a ~12-min talk about the OSS Fuzz deployment on OpenPrinting. \"The Journey of KDE Plasma on Ubuntu Core\" by Kevin Ottens (Slides, Video) This is all about the development of an Ubuntu Core Desktop distro with KDE instead of GNOME as desktop session. The architecture is shown and the challenges encountered and how they got solved. Soumyadeep Ghosh, GSoC-2024 contributor of the Snap backend for KDEs software manager Discover, mentored by Scarlett Moore, asked several interesting questions. \"Unstoppable Force Behind Linux on RISC-V\" by Gordan Markus and Yuning Liang (Slides, Video) Gordan Markus, Director Silicon Alliances at Canonical, and Yuning Liang, founder of Deep Computing, tell about Deep Computing's efforts to create consumer-ready laptops with RISC-V architecture and Ubuntu as operating system. \"Re-inventing distroless with Chiselled Ubuntu containers\" by Cristovão Cordeiro (Slides, Video) In this talk Cristovão Cordeiro, manager of a containerization team at Canonical, tells about freeing containers from unnecessary files, not only to save storage space but also to reduce the attack surface of the containerized applications. He uses the chisel tool which allows the installation of parts of Debian packages (so-called \"slices\"). Cristovão was also GSoC mentor at OpenPrinting this year for the project of Rudra Pratap Singh, to create OCI container images of CUPS and Printer Applications. \"Building secure and minimalistic Docker images for Data and ML with Rockcraft\" by Anas El Husseini, Zhijie Yang (Slides, Exercises, Video) Right after Cristovão's talk one could get hands-on with his subject matter in this workshop. And it was really interactive. On one of the first slides there are instructions on which packages to install and a link to a GitHub repo with all the example files for the exercises in a subdirectory for each task. I have actually done the exercises during the workshop and they all worked as designed. \"Flush with Innovation: Revolutionising Train System Toilets with Embedded Technologies\" by Akarshan Kapoor (Slides, Video) Our GSoC contributor Akarshan Kapoor was on the Ubuntu Summit again, but not with a talk about Scanner Applications. Doing his second exchange semester in Germany, he also did an internship where he worked on the free software stack used in the monitoring system of the toilets in the trains of the German railway. Christian Ehrhardt, MC of the day, announces this talk so nicely: This is AK, who will revolutionize my personal live. Because train travel in Germany really is not, what you want it to be, and if it is really not what you want it to be, you at least want to have the toilets working ... And Akarshan, when he introduced himself in the beginning, he told that he was already speaking on the Summit last year, about his Scanner Application work for OpenPrinting, and he shouted me out! Lightning Talks I have also attended the lightning talks, especially \"Making the Thunderbird snap a first class citizen\" by Heather Ellsworth (Slides, Video): Heather, who formerly worked in Canonical's Desktop Team and had moved on to Thunderbird, is snapping Thunderbird in close collaboration with her former colleagues from Canonical. \"How I built Check-in Kiosk for UbuCon Korea\" by Youngbin Han (Slides, Video): On-the-spot printing of conference badges with a self-service kiosk setup with a label printer, created by Youngbin. \"Back to the Future of Open Source 3D Printing Hardware\" by Yatin Khurana (Slides, Video): Indian manufacturer makes true open-source hardware components for 3D printers. \"Open Source DJing: bringing hardware compatibility to the Linux platform\" by Jesús Soto (Slides, Video): Before Jesús performs it live on the closing party he tells in the last lightning talk of the conference, right before the party, how DJing with free software is done. and the lightning demo: \"Modifying a Framework Laptop from x86 to RISC-V live on stage\" by Nirav Patel (Video): Framework's CEO is showing how easy it is to make changes on the hardware of a Framework laptop, thanks to their modularity. And with Deep Computing having presented their RISC V mainboard for Framework, it is exactly this which makes it into the sample laptop within the 5 minutes of a lightning talk slot. Unfortunately no boot test is demonstrated ... But the demo was already impressive this way. Should we try to get a lightning workshop next year? Exhibition On the exhibition I have not only received visitors at the Snapcrafters booth but also visited several booths: Deep Computing: I met the founder of Deep Computing, Yuning Liang, and he showed me the RISC-V-based Roma laptops and also the RISC-V mainboard for Framework laptops, and at the same time there was also the 14-year old Gabriel Ozkan who was very interested in participating in Open Source. I told that I am leading OpenPrinting and that I am fellow of the Linux Foundation, and to Gabriel I also told about Rudra Saraswat who is also 14 years old and he is leading Ubuntu Unity and has created blendOS. Yuning gave a RISC-V SBC to both Gabriel and me, and I contacted him some days ago how to get it working and he put me in contact with the right people. The board can be useful for me to test the printing stack on RISC-V. Yuning has also given the talk about RISC-V, together with Gordan Markus from Canonical (see above). Framework: Right nect to the Deep Computing booth was the Framework booth where you could see and try out their laptops and their laptop's modularity. Naturally, they also had Deep Computings RISC-V board on their booth. Nirav Patel, their CEO, has done the lightning demo of changing the motherboard in five minutes (see above). UBPorts: This was the place where you could find Diogo Constantino (of the LoCo Portugal) most easily, as participant of this booth and Ubuntu Touch enthusiast who even uses this system as daily driver. Also Alfred Neumayer, master of Snap on Ubuntu Touch was participating (and giving a talk, Slides, Video). Back to the Future of Open Source 3D Printing Hardware: Here I met Yatin Khurana, from Boltz R&D in India, developing truly Open-Source hardware for 3D printers, in contrary to most manufacturers going more and more closed-source. I am looking into getting him onto the next Opportunity Open Source conference. Yatin has also given a lightning talk (see above). Thunderbird: For me visiting the Thunderbird booth was less because I use Thunderbird for more than 20 years already (I started as it was still the mail part of Netscape Communicator), but more to meet old friends, Heather Ellsworth and Monica Ayhens-Madon. As last year, Monica has bought a penguin for Jill again and let Mathieu Comandon again bring it to its Destination. The Thunderbird booth was right next to UBPorts and Heather made the mobile version of Thunderbird working on Ubuntu Touch. Hallway Track When Diogo Constantino showed up at our Snapcrafters booth I started chatting with him, in Portuguese, and not taking it actually seriously, telling him that we should record an episode for Podcast Ubuntu Portugal on the Summit, and he found that a good idea, and then he asked the organizers for a room and we started gathering people who speak Portuguese end ended up to produce episode E322 with Diogo, Cristovão Cordeiro (Canonical Containerization/Rockcraft), Carlos Nihelton (Canonical Desktop Team/WSL), Diogo Sousa (Canonical Security Engineering), and me. This was the 4th time of me being in the Podcast Ubuntu Portugal. On the UbuCon Asia in Jaipur, where I met Soumyadeep Ghosh for the first time and I was talking with him about a lot of my free software activity and experience, he came to the idea to create a monthly Ubuntu podcast, probably because I told him also about Heather's famous Indabas. On the Summit he was then looking for help on how to do the logistics of a podcast, and it was great that Diogo as experienced podcaster was there and he explained everything to Soumyadeep and we created a room on Matrix for further planning. And I also met our famous vulture, Liam Proven, the Reg FOSS desk from The Register, again, exactly at the dinner of the 26th, which I had with him and Soumyadeep, in an Indian restaurant. As Soumyadeep, he likes the really spicy Indian food and so they asked the restaurant staff to do it really as in India and not adapted to Europe. Liam told a lot about his long life, his accidents and all the steel in his body holding together his broken bones, and so he got the \"Iron Man\" for me ... Hacker Spaces On the evening of the 26th, right after the talks, meeting rooms were set up for the Hacker Spaces, informal meetings of some of the participating free software organizations and groups, for hacking, debugging, planning, ... The groups who got a room were Ubuntu Flavours, Governance & Autoinstall, Open Source Security, Linux Gaming, Juju & Friends, and the Open Documentation Academy. As OpenPrinting is participating as organization in the Open Documentation Academy (ODA), I have participated in their room. Our activity was running an episode of the weekly Open Documentation Hour live session (Episode 35, Video). Graham Morrison, at Canonical responsible for the Snap documentation and also project lead of the ODA (at the very right in the frame, but not visible in the first few minutes), is hosting the session. At 2:00 min we discussed the use of GIT to manage the documentation and I (second to the right in the frame, in the beginning at the very right) am telling that I use it for all content on OpenPrinting without problems. Right after (3:18 min) Graham is introducing me as responsible for OpenPrinting and then I tell what OpenPrinting is, about CUPS, Michael Sweet, and our need of documentation and that therefore I joined the ODA as the first non-Canonical organization. I also tell that Michael Sweet is an excellent example of a programmer who is also doing all the documentation for his work. Graham tells that Thunderbird is also joining, as the second non-Canonical organization. My part ends at 10:23 min. Coverage Here are some blogs, articles, videos, and podcasts about the event (taken from the internal list of the organization team): The Source - Canonical on LinkedIn Thank YOU for open source: Canonical's official report of the Summit on LinkedIn, featuring Ngazetungue Muheue’s talk on open source in Africa, the work of the Hack Club, creating free software with high school teenagers, including the talk about the Boreal Express, by Zach Latta, founder of the organization, Akarshan's talk about the free software use in train toilet monitoring (see above), Juanmi Taboada's submersible workshop, and as the higlight at the end, the Framework lightning demo (see above). Soumyadeep Ghosh on GitHub Ubuntu Summit 2024: A joyful experience filled with sorrow: Soumyadeep's second conference in his life (The first was the UbuCon Asia 2024) and his first international trip, was the Ubuntu Summit. He tells about his arrival, the people he met, the Snapcrafters booth, the Snap workshops, the sessions he attended, with many photos of the people ... But he also tells that his grandpa passed away while he was on the Summit. R. I. P. Akarshan Kapoor on LinkedIn That’s what happens when you combine a love for OpenSourcery with the celebration of 20 years of Ubuntu: Akarshan giving a nice short summary of the people he met on the Summit by doing one-line-shoutouts of each of them. And I got shouted out near the top of the long list! The Register An awful lot of FOSS should thank the Academy: About the presentation \"Open Source Software for Motion Pictures\" by the Academy Software Foundation. Why we're still waiting for Canonical's immutable Ubuntu Core Desktop: State of the art of Ubuntu Core Desktop, especially the challenge of having different desktop sessions, as KDE in our case. A sit-down with Ubuntu founder Mark 'SABDFL' Shuttleworth: The vulture has interviewed Mark about major happenings during the 20 years of Canonical. Framework laptops get modular makeover with RISC-V main board: About the lightning demo of getting Deep Computingś RISC-V board into a Framework laptop (see above) and about the RISC-V board itself. Gaming on Linux Ubuntu Summit 2024 highlights - Linux gaming talks on UMU and Heroic Launcher: Short article about the 2 gaming-related talks, Paweł Lidwin about Heroic and Thomas Crider (\"GloriousEggroll\", \"Eggy\") about UMU, with links to the talks in the recording videos. The gaming booth and hacker room got not mentioned though. Late Night Linux Podcast Episode 307: Report from the summit at 18:50 min to 22:00 min. Fedora Podcast Gaming with ProtonGE: Eggy gets interviewed about his work on Linux gaming and he tells about the Summit in the \"Future of Gaming\" section near the end. Canonical Open Documentation Academy Open Documentation Hours episode 35: The episode which we have produced in the Open Documentation Academy hacker room, see above. Podcast Ubuntu Portugal (in Portuguese) E322: Na Ubuntu Summit 2024 (Haia): The episode we have produced live on the Summit, by Diogo Constantino, me and 3 other Portuguese-speaking guests. E323: Balanço de Cimeiras: About both the Festa do Software Livre and the Ubuntu Summit. At 8:30 min - 13:20 min Diogo Constantino tells about the wireless clip-on mics which I brought and which we used for my Snap workshop and some other sessions. As reported in July, Diogo Constantino, leader of the Ubuntu local community (LoCo) Portugal, had interviewed me in the Podcast Ubuntu Portugal, a podcast in Portuguese language about Linux and especially Ubuntu. In the end of the interview Diogo invited me to the Festa do Software Livre/UbuCon Portugal in Aveiro in Portugal, where on both conference days I had dinner with Diogo and the organizers of the event and some others, and after each of the two dinners we recorded an episode of the podcast. Two weeks after that, I met Diogo again, on the Ubuntu Summit in the Hague in the Netherlands. Not really taking it seriously I told him that we could record an episode of the podcast on the Summit, and he told that is a good idea and so we looked for Portuguese-speaking people on the Summit, and put together a group of 5: Diogo, me, Diogo Sousa (Canonical Security Engineering), Cristovão Cordeiro (Canonical Containerization/rockcraft), Carlos Nihelton (Canonical Desktop/WSL) We got a meeting room from the organizers and produced another great episode. So this way I made it into the Podcast Ubuntu Portugal 4 times: E310: I got interviewed by Diogo E320: Festa do Software Livre, day 1 E321: Festa do Software Livre, day 2 E322: Ubuntu Summit If you feel more comfortable to listen to people speaking Portuguese and not English, together with the recordings of my talks on the Festa do Software Livre, there are a lot of opportunities to listen to me now. Also if you feel more comfortable to get the recent vulnerabilities explained in Portuguese, I did so in E321 and E322. Now the GSoC 2024 has finally completed, also those contributors who got the longest possible coding period of 22 weeks had to submit their final reports now. This was the most successful Google Summer of Code for OpenPrinting. 11 contributors is the highest count we reached so far and they all did amazing work! We plan to get each one's project into the respective upstream code. With all our great mentors we have worked in an excellent OpenPrinting team of more than 20 persons.! 10 of the 11 contributors have passed the final evaluation, but the one who has failed, Shivam Sharma (OAuth2 support in print GUI), and his mentor, Deepak Patankar want to finish the project after GSoC. Also all the others want to finish their missing pieces and get their code upstream. And we got excellent feedback from all the 11 contributors. Each of them has praised our work as mentors and at OpenPrinting a lot in their final evaluation, and many also already in their midterm evaluations. Now we have a lot of pull/merge requests, both on OpenPrinting itself and also on external projects. We are now working on getting them all merged. Thanks a lot to all the contributors and mentors for their work, confidence, and patience with us! Here are the results, work products, and links to their code: Packaging CUPS and Printer Apps into OCI images
Contributor: Rudra Pratap Singh
Work Product
PASSED To complete this task, the repositories need to get transferred to OpenPrinting or merged into the appropriate repositories of OpenPrinting and also an OpenPrinting account on the DockerHub needs to get created and the container images uploaded to there. Code: CUPS Rock PostScript Printer Application Rock Ghostscript Printer Application Rock HPLIP Printer Application Rock Gutenprint Printer Application Rock GitHub action update automation for Rocks GitHub action versioning automation for Rocks GitHub action rock-version-schema addition CPDB support for the LibreOffice print dialog
Contributor: Biswadeep Purkayastha
Work Product PASSED To complete this task, Biswadeep’s changes linked above need to be merged into LibreOffice upstream. All pull requests on CPDB are already merged. Code: Pull request on Gerrit Integrating C-based OpenPrinting Projects in OSS-Fuzz Testing
Contributor: Jiongchi Yu
Work Product PASSED OSS-Fuzz testing is now active on the CUPS (2.x) and libcups (3.x) repositories. Development will go on: Based on existing fuzzing projects, integrating more harnesses is more convenient, especially with the help of LLMs. More C/C++-based projects are needed to be integrated, such as cups-browsed and cups-snap Integrating OSS-Fuzz into OpenPrinting projects written in other languages such as Python (pyppd) and Go (ipp-usb), is feasible. More effective fuzzing seeds and dictionaries for specific OpenPrinting functionalities are required. End-to-end testing methods can help identify more exploitable bugs in OpenPrinting projects. Manual security audits can also help. Code: Source Code for Fuzz Harnesses OSS-Fuzz Projects cups libcups PAPPL API Bridging for Scanner Applications
Contributor: Akarshan Kapoor
Work Product PASSED To complete this task, the following steps have to be done: Create a test suite/test driver (PAPPL Issue #134) Retrofit API Completion: It must be assured that all SANE drivers work smoothly in Scanner Applications Rebase to PAPPL v2.0: Developing and testing have been done with PAPPL 1.4.x. In the mean time feature development concentrated on the 2.x branch Kshitij Sharma has stepped up as a volunteer contributor to help on the Scanner-Application-related work. He will help Akarshan to complete his work and also on the further development of Scanner Applications. Code: Scan API PR in PAPPL: Laying down the framework to make scanning work as seamlessly as printing (PAPPL Pull request #371) PAPPL Retrofit Interface PR: Aiming to replace SANE with a more universal PAPPL interface, moving scanning closer to true driverless operation (pappl-retrofit Pull request #23) Last year's eSCL Work in GSoC 2023: A deep dive into building groundwork for driverless scanning, covering our approach to sandboxing scanners (GSoC 2023 final report) Akarshan's GIT repo CPDB support for the print dialog of Mozilla
Contributor: Kushagra Sharma
Work Product PASSED To complete this task, the following steps have to be done: Implementing additional features from the CPDB API, ensuring that the print dialog can dynamically fetch printer properties and settings Conducting thorough tests to verify that the dummy printers are recognized correctly and that their properties are displayed accurately in the print dialog Upstream merge in Mozilla Uddhav Phatak (GSoC contributor for PDFio support in libcupsfilters) is volunteering to help finishing these tasks. Code: Code review request at Mozilla Desktop Integration: Update system-config-printer for the New Architecture of printing
Contributor: Shivam Jaiswal
Work Product PASSED To complete this task, the following steps have to be done: Finalising the \"Add Printer\" part Merge Pull request #378: Adding Feature of IPP Service Discoveries Code: Pull request #378: Adding Feature of IPP Service Discoveries Make a native printer Application from Gutenprint
Contributor: Ankit Pal Singh
Work Product PASSED The project is completed so far, it only needs to be merged upstream, ideally in the Gutenprint project. Further development plans are to add option preset functionality, so the complex options can be set in preset profiles in the web interface of the Printer Application and the presets can then be selected for each print job via IPP. Code: Ankit's GitHub repository GNOME Control Center: Finalizing the New Printing Architecture for GNOME
Contributor: Kaushik Vishwakarma
Work Product PASSED To complete this task, the following steps have to be done: The code needs to get migrated to the current development branch (47.3) and a merge request posted A feature request for PAPPL needs to be posted to allow triggering auto-addition of printers via IPP request Code: Kaushik's Github repository User interfaces for using OAuth2 with printers and scanners
Contributor: Shivam Sharma
Work Product FAILED To complete this task, the following steps have to be done (these are very important for the usefulness of the work, therefore the fail): Complete the functionality, for example the access token is not sent to the printer with every request. Document how the code is tested, or ideally add test scripts. Shivam promised to fnish his project after GSoC. Code: Shivam's GitHub repository of cpdb-backend-cups Pull request #37 on cpdb-backend-cups Converting Braille embosser support into a Printer Application
Contributor: Arun Patwa
Work Product PASSED The project is completed so far, but there are some plans to improve it, especially adding support for more Brialle embossers, adding more filter chain options, and more customization for users. Code: Arun's Github Repository Pull request Replace QPDF by PDFio as PDF manipulation library in libcupsfilters
Contributor: Uddhav Phatak
Work Product PASSED To complete this task, the following steps have to be done: Port cupsfilters/pwgtopdf.cxx Intense testing of the ported functions Code: Uddhav's work on GitHub. libcupsfilters Pull request #71 And here are the write-ups for October: Packaging CUPS and Printer Apps into OCI images
Contributor: Rudra Pratap Singh This month, I tested the ps-printer-app rock using an example daemon printer emulator, which forwards print jobs to an output file through a simple C script. With minor modifications to ps-printer-app.c, I was able to add a generic printer, but I am still working on forwarding the print job to our printer emulator. Integrating C-based OpenPrinting Projects in OSS-Fuzz Testing
Contributor: Jiongchi Yu In October, the primary focus of the OpenPrinting fuzzing project is to triage and submit bug reports to development teams for addressing issues identified by existing OSS-Fuzz harnesses. Notable fixes include changes in the CUPS repository, such as the commits 80fe6815d5941ef8a812087af7869f4c02779f1d and 7a2d383ee59a90f41d482476edb909165ea9565d, resulting in over 5,000 lines of code changes. https://github.com/OpenPrinting/cups/commit/80fe6815d5941ef8a812087af7869f4c02779f1d https://github.com/OpenPrinting/cups/commit/7a2d383ee59a90f41d482476edb909165ea9565d Additionally, the OpenPrinting fuzzing team shared our integration experience on developing fuzzing for open-source software at the Ubuntu Summit 2024. Till, Andrei, and Dongge participated onsite, deliverred a successful workshop and shared insight for open source developers in securing their projects. After wrapping up the work in GSoC, we are focusing on incorporating more practical fuzzing harnesses into the OpenPrinting projects. CPDB support for the print dialog of Mozilla
Contributor: Kushagra Sharma The work on adding Common Print Dialog Backends (CPDB) support to Mozilla Firefox focused on setting up foundational elements and preparing the backend for seamless integration. Key accomplishments include configuring CPDB dependencies within Mozilla's build system and implementing a dummy print backend to simulate basic CPDB operations, allowing for initial testing. This backend interacts with nsPrinterBase and nsPrinterListBase to ensure compatibility with Firefox’s printing framework. Currently, the dummy backend is under code review, while the next phase will replace placeholder values with real CPDB data. I have added a work in progress code review for progress made so far (Code review : https://phabricator.services.mozilla.com/D227780 ) Also published GSoC’24 report (Report :https://github.com/kushagra20251/GSoC24 ). Desktop Integration: Update system-config-printer for the New Architecture of printing
Contributor: Shivam Jaiswal I have added the IPP Service Discovery part and created a pull request. Here is the link to the PR: https://github.com/OpenPrinting/system-config-printer/pull/378. In this PR, I included code for the asynchronous discovery of IPP services and for the UI part as well. I'm currently working on the \"Add Printer\" functionality, using methods suggested by @tillkamppeter and discussed with @Mohit. I have also created the final report for my GSoC project. Here is the link to the final report: https://github.com/TheJayas/GSoC-2024-Final-Report GNOME Control Center: Finalizing the New Printing Architecture for GNOME
Contributor: Kaushik Vishwakarma I had an online meeting with Mohit, and we decided to remove the second option—installing printer apps from the internet—since implementing this concept isn’t entirely feasible. I’ll provide all the code next week. Once you successfully test my code, I’ll migrate it to the current GCC, which I believe is 47.3. I’ll also raise an issue in Pappl regarding the auto-add method to expedite this feature. I plan to continue contributing to this project until it’s officially released with the upcoming GCC User interfaces for using OAuth2 with printers and scanners
Contributor: Shivam Sharma This month I performed several tests to check the status of the code and apart from this I also fixed some bugs. I also made changes to the existing function on_handle_print_socket(). The change was to merge the OAuth file with the CPDB_print_backend file. I also called a function for smooth transition. The question was where the access token will be stored and for how long the client can use that code? So to fix this I made changes to Auth.c code to save the access token in the access_token.txt file and the file can only be accessed by the client requested for it. By this way the security is also improved. I also created a pull request and the code is ready to review. Converting Braille embosser support into a Printer Application
Contributor: Arun Patwa I introduced a spooling_conversions array, enabling the addition of MIME filters to handle conversions between source and destination types. This setup streamlined the process of iterating through filters to change file types as needed, facilitating the integration of multiple filters, including \"texttobrf\" and \"imagetobrf.\" I also removed PPD support in favor of IPP options, focusing solely on default IPP configurations. Additionally, I implemented the mime_cb() function using libmagic to dynamically identify the MIME type of input files. This approach allowed me to successfully print various file types, such as .txt, .pdf, .html, and .jpg, enhancing the flexibility and functionality of the printer application. Replace QPDF by PDFio as PDF manipulation library in libcupsfilters
Contributor: Uddhav Phatak I have successfully ported all the files in the cupsfilters/pdftopdf/*, cupsfilters/pdf.cxx, cupsfilters/pclmtoraster.cxx from C++ to C, all the tests are passing using the \"make check\" command. Even though I have wrapped up my GSoC journey officially by passing the final submission, the conversion of 1 file (cupsfilters/pwgtopdf.cxx) is remaining, which I will complete soon. Since the last OpenPrinting News we had again several releases: libcupsfilters, libppd, cups-browsed 2.1.0 First of all, we have done upstream releases of the packages which got fixed because of the recently reported remote code execution and DDoS vulnerabilities. We have especially removed support for legacy CUPS browsing and for LDAP from cups-browsed to eliminate the entrance point for the attacks, the acceptance of UDP packages from arbitrary sources on port 631. In addition we validate and sanitize incoming IPP responses and PPD file entries in both libcupsfilters and libppd. After the 2.0.0 release we had also added some new features during all the months up to now. In libcupsfilters and libppd we have added support for building with libcups3, and INSTALL.md files instead of INSTALL. libcupsfilters received a facility for CI/build/unit testing of filter functions using an easily-editable table describing the test cases. This was Pratyush Ranjan's GSoC 2023 project at OpenPrinting. libcups 3.0rc1, 3.0rc2, and 3.0rc3 The development of libcups3 has reached release candidate (RC) state. Then usually all planned features should be included band final testing and bug fixing will happen. So it now will not take long any more until the first stable release of a CUPS-3.x component. The last feature additions are here: Added cupsFormatString and cupsFormatStringv APIs to safely format UTF-8 strings. Added support for per-user instances of cups-locald (Issue #69) Added httpConnectURI API. Added \"end\" argument to cupsParseOptions API. Renamed httpReconnect to httpConnectAgain. Updated cupsDestInfo to accept a cups_dest_flags_t argument. Updated cupsCopyString and cupsConcatString APIs to safely terminate UTF-8 strings. Updated list of attributes included in the destination options. Updated cupsAddIntegerOption and cupsGetIntegerOption to use the long type. Updated httpAddrConnect() to handle POLLHUP together with POLLIN or POLLOUT. Updated the various tool man pages, usage output, and examples. Updated ippCreateRequestedArray for the Get-Documents and Get-Output-Device-Attributes operations. Updated ipptool to validate IPP, PDF, and .strings files using the \"WITH-[ALL-]CONTENT\" predicate (Issue #87) Now use installed PDFio library, if available. Now use NotoSansMono font for ipptransform text conversions. Brought back IPP/2.x and related conformance test files (Issue #85) The ipptransform program now supports uncollated copies. In addition. many bugs got fixed. PAPPL 1.4.7 and 1.4.8 These releases fix several bugs, including a security issue: If a password is set for the web admin interface, it got ingnored when logging in and so anybody could log in."
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-3.0-Call-for-Proposals-extended-to-July-16",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 3.0 - Call for Proposals extended to July 16",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-3.0-Call-for-Proposals-extended-to-July-16",
+ "headings": [],
+ "tags": [],
+ "snippet": "A conference is great because its content is amazing, therefore we need more ...",
+ "content": "We are currently in the middle of the preparations for another awesome Opportunity Open Source, this time co-located with the first UbuCon India. We have already reserved the space in the IIT Kanpur (where we have also been last year), lined up a volunteer team for all the on-location organization work, contacted potential sponsors and potential speakers, announced the event on several platforms, ... But the most important is to deliver amazing content: Talks, workshops, panel sessions, demos tables/booths, and ... Meet-ups and BoFs This year we accept meet-ups and BoF sessions as a new session format and plane to make available an extra room for them. This way you can meet for informal discussions, like for example planning Ubuntu community activity in India, working out a new free software application project, establishing free software use in schools or public administration, ... It is also a chance for leading developers of an open-source project coming from overseas and meeting their Indian developer community. And, as we are always dealing with free and open-source software anybody is highly welcome to join these sessions, learn about the work of free software organiations and getting involved ... But, was there not already the submission deadline today? Yes, but we have extended it by one month, to give you enough time for planning. The Call for Proposals is now open until Wednesday, July 16, 11:59pm IST (18:29 UTC) So we are eager to see your proposals. And last, but not least, we keep you up-to-date on LinkedIn: LinkedIn page of the Opportunity Open Source: @opportunity-open-source Event web site UbuCon India Practical info: Location, remote attending/speaking, ... Call for proposals Mastododon: #OpportunityOpenSource and #UbuCon LinkedIn: @opportunity-open-source And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-3.0-No-UbuCon-India-co-hosted-with-us",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 3.0 - No UbuCon India co-hosted with us",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-3.0-No-UbuCon-India-co-hosted-with-us",
+ "headings": [],
+ "tags": [],
+ "snippet": "We will just run the OOSC, as last year, without UbuCon ... And we need more session proposals ...",
+ "content": "Unfortunately, due to some unavoidable circumstances we are not having a joint event. Therefore, we will have the Opportunity Open Source, as originally planned, on September 5-7 in the IIT Kanpur, but without UbuCon India. We will focus, as in the first two editions, in 2023 and 2024, on introducing students, and also professors and researchers, at universities and colleges in India. Your proposals for talks, workshops, meet-ups, BoFs, booths, demos ... An important part of a conference is that we convey great content, for attendees to learn what one can do with free and open source software and how to contribute to it. As in the previous editions we will have talks and lightning talks, both from in-person and remote speakers, and interactive hands-on workshops, where attendees can try out and experience the subject matter on their own laptops. But we also accept informal meet-ups and BoFs, where a leader in an open source project can meet the local community and, by the session being open for everyone, give insight into the project to people who like to contribute. And to stimulate the hallway track we are looking for booths and demo tables, to show off your open-source work and motivate people to participate. So please post your ideas on our Call for Proposals, until Wednesday, July 16, 11:59pm IST (18:29 UTC) We are eager to see your contributions. Event web site Practical info: Location, remote attending/speaking, ... Call for proposals Mastodon: #OpportunityOpenSource LinkedIn: @opportunity-open-source And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-3.0-No-deadline-for-Call-for-Proposals",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 3.0 - No deadline any more for Call for Proposals",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-3.0-No-deadline-for-Call-for-Proposals",
+ "headings": [],
+ "tags": [],
+ "snippet": "We accept proposals up to the conference dates, but we already start accepting and scheduling",
+ "content": "The Opportunity Open Source comes closer, but after our first extension of the deadline for the Call for Proposals we still have a lot free space in our schedule. Therefore we do not stop our Call for Proposals at all, but leave it just open. We will start accepting session proposals in the next days and do a preliminary schedule at the end of this month/beginning of next month, and we will keep our eyes on new proposals and accept them when they are interesting. So last-minute proposals are welcome. We will have a room for talks, a room for workshops, and a room for BoFs. If one of them runs full, we consider putting some sessions of that type into one of the other rooms. We also consider closing the CfP should we get too many proposals. So do not wait too long with your submission to secure your spot. So we are eager to see your amazing content: Talks, workshops, panel sessions, demos tables/booths, BoFs/meet-ups, ... Here is our Call for Proposals. see you all in Kanpur ... Event web site Practical info: Location, remote attending/speaking, ... Call for proposals Mastodon: #OpportunityOpenSource LinkedIn: @opportunity-open-source And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-3.0-Schedules-and-contributions-published",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 3.0 - Schedules and contributions published",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-3.0-Schedules-and-contributions-published",
+ "headings": [],
+ "tags": [],
+ "snippet": "Have a look into the amazing presentations and workshops, plan your participation!",
+ "content": "Only 10 days left to the Opportunity Open Source 3.0 in the IIT Kanpur in India! Now we got all the session proposals which got promised to us and so we have scheduled the contributions now and published everything. Here are the full schedules and the list of contributions. Click on the entries to read the abstracts and get more details about each session. Note that the schedules are subject to change, as for example remote speakers are perhaps not able to give their presentation at the scheduled time. Also watch out for further info on our site, about the location, about remote attending, and speakers could add slides, preparation instructions and exercise repositories for workshops, ... See you all in Kanpur ... Event web site Practical info: Location, remote attending/speaking, ... Call for proposals Mastodon: #OpportunityOpenSource LinkedIn: @opportunity-open-source And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-3.0-We-are-looking-for-sponsors",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 3.0 - We are looking for sponsors",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-3.0-We-are-looking-for-sponsors",
+ "headings": [],
+ "tags": [],
+ "snippet": "No conference without solid support - Wide range of sponsorship packages available",
+ "content": "The Opportunity Open Source is not only an awesome conference because of its speakers, or its audience, but also because of its sponsors. Without them, the event would not be possible, or at least not such a success ... Last year's sponsors did not only cover the costs of the beautiful posters announcing the event with all its speakers, the schedules, and all information handy for the attendees, and the accommodation of speakers in the guest house, but also an unforgettable conference dinner/closing party. They also have supported the hackathon, not only covering costs but also providing problem statements. And this year we are looking for sponsors again, and to make sponsoring easier, we offer a variety of sponsorship packages. Depending on the amount you provide to us, you get valuable perks: Visibility of your logo, getting mentioned in announcements, but also exhibition booths, stage time for talks an workshops, the opportunity to provide a problem statement for the hackathon, ... The packages are: Title Sponsor Amount: ₹5,00,000+ (USD 6000) Perks: Booth size L Keynote 30 min Workshop 90 min OR Talk 30 min OR BoF 40-50 min Problem Statement for Hackathon Logo exposure at many places, especially also on t-shirt/swag and in size XL on web site Recognition on social media, blog, and during opening and closing plenaries Co-Title Sponsor Amount: ₹4,00,000+ (USD 4800) Perks: Booth size M Workshop 90 min OR Talk 30 min Logo exposure at many places, especially also on t-shirt/swag and in size L on web site Recognition on social media, blog, and during opening and closing plenaries Platinum Sponsor Amount: ₹3,00,000+ (USD 3600) Perks: Booth size S Talk 30 min Logo exposure at many places, especially also in size M on web site Recognition on social media and during opening and closing plenaries Gold Sponsor Amount: ₹2,00,000+ (USD 2400) Perks: Booth size S for ₹30,000 (USD 500) extra Lightning Talk 5 min Logo exposure at many places, especially also in size S on web site Recognition on social media and during opening and closing plenaries Bronze Sponsor Amount: ₹1,00,000+ (USD 1200) Perks: Logo exposure at many places, especially also in size S on web site Recognition on social media and during opening and closing plenaries If interested, please fill the form on our sponsorship page to contact our marketing team. For details about the packages and more information about our events and sponsoring, see our Sponsorship Prospectus. See you all in Kanpur ... Event web site Practical info: Location, remote attending/speaking, ... Call for proposals Call for sponsors Sponsorship Prospectus Mastodon: #OpportunityOpenSource LinkedIn: @opportunity-open-source And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-3.0-in-the-IIT-Kanpur,-India",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 3.0 in the IIT Kanpur, India",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-3.0-in-the-IIT-Kanpur,-India",
+ "headings": [
+ "From Nepal to India ...",
+ "The Sessions",
+ "The Resonance",
+ "Opportunity Open Source 2026 - Call for Locations",
+ "Thank you"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/NAamSJlVTEc/hqdefault.jpg",
+ "snippet": "For our third edition we returned to Kanpur",
+ "content": "As reported in my previous blog I had also attended the UbuCon Asia in Kathmandu, in Nepal, on August 30-31. We have set the date for the Opportunity Open Source on the following weekend, September 5-7, to give the possibility to attend both doing one single round trip, which had especially made sense if we had co-hosted UbuCon India. So at least I have made said round trip and traveled from Kathmandu in Nepal directly to Lucknow in India, on September 2, the day after the day trip of the UbuCon in Nepal. Then I have stayed in Lucknow for tourism for 2 nights and the traveled with Aveek Basu with a hired driver to Kanpur. There we met the local organizers Sanskar Yaduka (does also GSoC for OpenPrinting) and Shreya Shree, and also Akarshan Kapoor. We originally wanted to do the final testing of A/V for the live streaming and remote speaking, but we ended up fixing the schedules. Originally, we had the 3 conference days, September 5-7 for the talks and workshops, as nobody provided a Hackathon to us. So I accepted all the proposals on the CfP and scheduled all the sessions into plenary room, breakout room and workshop room over the 3 days, taking into account speaker's requirements when they are not there all the days, time zones of remote speakers, talk before workshop, no 2 talks of one speaker to the same time, ... Then, just when I arrived in Kanpur, they told me that they got a Hackathon and to have the 7th for doing it, we had to re-schedule all the sessions to squeeze them into the first 2 days. Fortunately, I did not need to re-schedule from scratch, as Sanskar did a first draft of a new schedule, but I had to correct several things to re-assure the speaker's wishes and I had to transfer everything into the Indico site of the event, ending up to have only 2 hours of sleep the night before the event. Also, we had originally planned to start the conference only at noon on Friday, to give participants more time to arrive at the venue and also us more time to prepare the conference rooms. The re-scheduling required us to start already 11:00 in the morning and so having even less preparation time in the rooms. But on the other side, Akarshan Kapoor stepped in to help with adjusting last-minute schedules and announcing sessions on the Telegram channel for the attendees, especially also if we had delays. Thanks a lot, Akarshan, for doing so! Also some others, not only the organizers, started announcing the talks on the Telegram channel. Schedules Despite getting most of the proposals only lately, 3 weeks or less before the event, we got an amazing selection of sessions. Aveek and me, we naturally brought our own sessions about OpenPrinting, Snap, Google Summer of Code, and first contributions, but we had subject matters of a wide range of areas, a lot about the area everybody talks about, Artificial Intelligence and Machine Learning, ... and naturally also coding and development, security, Zephyr, ... Also non-coding-related subject matters of community building, switching to open source, funding, ... Some highlights: As this conference is primarily to introduce students into FOSS and how to contribute to it, we had several presentations about the basics of open source and how to join the contributor community: Aveek Basu has given an overview in how to do so right after the opening of the event, with \"Starting the Open Source Journey\". \"My LFX Mentorship Journey: From Application to KubeEdge Contributor\" (Slides) and \"From Zero to LFX: How Three Friends Cracked Open Source and Landed KubeEdge Mentorships\" (Slides) by Abhishek Kumar are both about his experience with the Linux Foundation's mentoring program LFX and KubeEdge as mentoring organization. Kernel developer and Linux Foundation fellow Shuah Khan showed in her talk \"Six years of empowering open source communities\" which learning opportunities the Linux Foundation provides to open source newcomers. Aveek Basu and me as experienced GSoC org admins and mentors hosted again a Google Summer of Code panel, with GSoC contributors Akarshan Kapoor, Mohammed Imaduddin, and Sanskar Yaduka as guests and answered the questions of the audience. In \"The Dark Side of Free and Open-Source Software (FOSS)\" Ayush Ghai talked about the problems occurring in FOSS development communities, like hobby developers ending up with responsibility on essential system components, burnout, commercial companies publishing under \"Open Core\" models keeping their stand out parts proprietary, ... (Blog) Aveek and me have naturally have made OpenPrinting one of the central parts of the conference: To start, I introduced into OpenPrinting by telling about how it all started, what we are doing currently, the New Architecture with CUPS 3.x doing away with PPDs and classic drivers and Microsoft's Windows Protected Print with which they do away with classic drivers, PAPPL not only for Printer Applications but also as base for the CUPS 3.x daemons, OSS-Fuzz, rust and Python bindings, ... and how to contribute. All this in my talk \"OpenPrinting - We make printing just work! - 25 years of printing for FOSS\" (Slides, Blog). Akarshan Kapoor has presented his OpenPrinting work of the last 2 GSoCs, \"Scaniverse Universal Scanner Drivers: One Solution for Every Distro\" (Report 2023, Report 2024), showing how the driverless scanning protocol eSCL can be used to create Scanner Applications, sandboxable scanner drivers. Alexander Pevzner (creator of ipp-usb and sane-airscan) is enthusiastically working on his \"Behaviorally Accurate Simulator for Multifunction Printers and Scanners\" (slides, GitHub) and told in his talk about it. This improves the possibilities of automated testing at OpenPrinting a lot, especially for device discovery, and whether the print output is correct. It is also very useful for development and debugging. To not let automated testing (CI, unit testing, fuzz testing) stop at crashes and errors but also allow testing of actual print output, Sanskar Yaduka is working on a GSoC project about visual analysis of print output. And this was subject of his talk \"From Open Source to OpenPrinting: My GSoC Journey and Project on Image Output Evaluation\" (GitHub) The successful efforts on fuzz testing and OSS-Fuzz integration of the GSoC 2024 continued in this year's GSoC, by contributor Mohammed Imaduddin. And he gave the talk \"Fuzzing Go and Python Projects in OSS-Fuzz: The OpenPrinting Case Study\" (Slides, GSoC Report 2025) about his work. Artificial Intelligence (AI) and Machine Learning (ML) are talked about a lot and this is also reflected by the many CfP submissions we got for this subject matter, and so we had a good amount of great sessions: In \"Can human intelligence show the way for artificial intelligence?\" Francis Steen (UCLA, Red Hen Lab) and Prof. Mark Turner (CWRU) suggest that based on the higher efficiency of human intelligence a new generation of AI should be developed and that not by the tech giants but by independent open source projects. Neeraj Poddar's and Saiyam Pathak's talk \"Future of Open Source AI: From Cloud to the Edge\" shows how AI can be deployed with open source, both in the cloud and in edge computing (processing takes place near the data source, locally deployed AI). In the talk \"Building Adaptive, AI-Native Experiences with On-Device Intelligence\" Neeraj Poddar shows how with the open-source platform DeliteAI AI can be deployed on local devices instead of cloud services being used to improve performance and privacy. And other awesome success stories of FOSS to motivate the students: Oliver Völckers presented \"How we built a pump monitoring system for Deutsche Bahn with wireless sensors using Zephyr RTOS\" (Slides), the subject of Akarshan Kapoor's internship which brought him into the world of Zephyr. Sumanto Kar and his colleagues have shown in the talk \"From Containers to Chip Design Classrooms: Leveraging Snap and Docker to Enable Open-Source EDA with eSim\" (Slides) how sandboxed packaging methods, Snap and Docker, allow for distributing the complex electronics design application eSim, consisting of many components to be easily installed in different Linux distribution environments without running into dependency hell. And in the second talk \"An Offline AI Assistant for eSim: Easier, Accessible, Open-Source Circuit Design and Debugging\" (Slides) they showed how eSim uses locally implemented AI. Mikhail Novosyolov told in is talk \"Migration of whole country to GNU/Linux\" about Russia's move to FOSS and digital sovereignty where ROSA Linux is playing the central role. And to get interactivity and action into the event one cannot run it without Workshops. We had one room dedicated for workshops and they all got well accepted. Here is especially to mention: Akarshan Kapoor with \"Zephyr RTOS: Building the IoT Future from the Ground Up\" (Slides, Exercises: Getting Started Guide) explained what an RTOS (Real-Time Operating System) is compared to a standard system and how to use the development tools. In the end he gave away some sample boards to attendees who asked questions. Sagar Sundaray and Swaraj Pande, both from Red Hat, showed how to deploy AI on automotive-grade systems, in \"Accelerating AI Deployment in Automotive: A Unified Approach\". They brought also a lot of demo hardware. For the app developers who have attended Mohammed Imaduddin talk about his OSS-Fuzz work for OpenPrinting to do the same on their app, Mohammed has given the workshop \"Intro to OSS-Fuzz: Build, Break, and Harden Open Source Software \" (Slides). In the session \"MicroCeph: Build your S3 app without AWS!\" Utkarsh Bhatt from Canonical's Ceph Engineering Team let his attendees self-host their S3 (Simple Storage Service) with MicroCeph. YouTube links: Note that, unfortunately, some sessions are missing and on some there is no audio. YouTube channel with the recordings Fri, Sep 5 Morning Plenary Breakout Afternoon Plenary Breakout Workshops Sat, Sep 6 Morning Plenary Breakout Workshops Afternoon Plenary Breakout Workshops After the event it was talked a lot about it and organizers and speakers got a lot of kudos, especially on LinkedIn. Most mentioned and cited persons in the reactions were me, Aveek Basu, Akarshan Kapoor, Ayush Ghai, Mikhail Novosyolov, Neeraj Poddar, Mohammed Imaduddin, Utkarsh Bhatt LinkedIn There are many more posts related to the OOSC 3.0 on LinkedIn. I am just listing the most interesting ones. Aveek Basu: \"What started in 2023 as a small student meetup at IIT Mandi has now grown into a vibrant community — with the 2024 and 2025 editions hosted at IIT Kanpur.\" (10 photos, 87 reactions, 2 comments, 2 reposts) Akarshan Kapoor: \"If you weren’t living in a cave, you have probably already seen my name pop up on your feed lately\" (8 photos, 193 reactions, 12 comments, 4 reposts) Akarshan Kapoor: \"GitHub doesn’t build communities. People do.\", \"Code changes fast. Communities last.\" (9 photos, 176 reactions, 17 comments, 10 reposts) Shrishti Gaikwad has praised me and my sessions a lot! (1 photo, 99 reactions) Shrishti Gaikwad has also praised Akarshan and his 2 sessions as well (4 photos, 85 reactions, 2 comments) Shrishti Gaikwad was selected as the media and publicity partner of the OOSC by the local organizers, probably therefore she wrote in more detail about some important speakers and sessions, also about Ayush Ghai, Utkarsh Bhatt, and Sagar Sundaray/Swaraj Pande. Yash Mishra presented his research on Deep Learning (1 photo, 22 reactions) Ayush Ghai about the LinkedIn reactions on his sessions (4 photos, 72 reactions, 3 comments, 2 reposts) Prajwal Kumar K (6 photos, 142 reactions, 12 comments) Varun Khandelwal: \"From the moment I entered the IITK campus, it felt surreal\" (4 photos, 51 reactions, 2 comments) Diksha Parulekar: \"Some highlights that stayed with me: Till Kamppeter (Leader OpenPrinting, Linux Foundation Fellow) Showed how even small experiments, done consistently, can grow into impactful contributions and meaningful open-source careers. His journey proved persistence matters more than perfection when starting out. ...\" (10 photos, 87 reactions, 2 comments, 2 reposts) Gauri Singh: \"WHAT.AN.EXPERIENCE!!\", \"Till Kamppeter – The Linux Printing Wizard and Project Lead at OpenPrinting. His insights? Next level.\" (4 photos, 74 reactions, 6 comments, 1 repost) Mohammed Imaduddin about his sessions about his GSoC work with OSS-Fuzz (5 photos, 201 reactions, 3 comments) Sumanto Kar about his talks about eSim (4 photos, 196 reactions, 12 comments, 6 reposts) Aakarsh Gupta from the Jaipur Engineering College and Research Centre (JECRC, where UbuCon Asia 2024 took place, good candidate for OOSC 4.0) (7 photos, 63 reactions, 5 comments, 2 reposts) Owais Tabrez: \"Open source isn’t just about code — it’s about community, collaboration, and shaping the future of technology.\" (5 photos, 36 reactions, 1 comment) Lucky Tiwari about meeting me and many others on the conference dinner (5 photos, 29 reactions) Ansh Goel Tells about his hackathon experience, nearly quit early, but ... (7 photos, 42 reactions) Vedika Chaudhary and Abhishek Sharma, posting on LinkedIn is not a college exam, so please do not copy from each other. But Abhishek, you won with 107 reactions and 4 comments against Vedika's 31 reactions ... Some other sites Best Sensor Zephyr Project Photos Coverage-OOSC (Google album) After 3 successful Opportunity Open Source conferences we want to continue, and so we want to do an Opportunity Open Source 4.0 in 2026, most probably around the same date as this year but we are open for different dates. As we want to reach young people and students to present to them what FOSS is and how they can participate and contribute, we want to run it in a city in India where there are several universities and colleges with undergraduate programs in engineering and especially computer science. The actual venue in that city is ideally a university or college with strong engagement in FOSS. Also important is that we, Aveek and me, cannot organize the whole conference remotely. We need an enthusiastic team of local organizers at venue. Their task is to negotiate with the administration to get all the needed local resources, as conference rooms (lecture halls, class rooms), and accommodation in gust houses and dorms, to get the needed permissions from the local government, find local sponsors, ... Right before and during the event the local organizers need to make sure that everything is going smoothly. A/V in the rooms needs to get tested, volunteers have to be lined up to make up the crew for each room and also to prepare things like decoration, booth space, front desk, ..., accommodation needs to get reserved, ... So if you are interested, please discuss it in your university or college, and contact Aveek and me to show your interest and get your questions answered. More detailed instructions for applying will come soon. Thanks a lot to the local organizers Sanskar Yaduka, Shreya Shree, and all the volunteers who joined. Especially also thanks to Akarshan Kapoor for helping with the last-minute schedule adjustment and announcements of sessions on Telegram. Also thanks a lot to the speakers: Aveek Basu, Akarshan Kapoor, Alexander Pevzner, Sanskar Yaduka, Mohammed Imaduddin, Francis Steen, Prof. Mark Turner, Neeraj Poddar, Saiyam Pathak, Oliver Völckers, Sumanto Kar, Mikhail Novosyolov, Sagar Sundaray, Swaraj Pande, Utkarsh Bhatt, Ayush Ghai, Abhishek Kumar, Shuah Khan, Bhavanishankar Ravindra (Bhavi), Divy Srivastava, Akash Sankaranarayanan, Nikitha Dhanabal, Jiongchi Yu, Priyam Chakraborty, Prof. Suman Chakraborty, Manuel Haro, Yash Mishra, Jayanth Tatineni, Aishwarya Sinha, Varad Patil, Shanthi Priya, Prof. Kannan M. Moudgalya, Manvith Kumar, Prajwal Kumar Karnad, Shaun Sebastian, Saquib Akhtar, Adlair Cerecedo-Mendez, Aditya Bhattacharya, Rudra Mani Upadhyay, Myo Thinzar Kyaw, Arjun Kumar Manav, Paritoshik Paul, Hardik Jinda, Abelardo Valdez Poot, Anmol Sharma, Siddharth Bhat, Lakshay Bandlish, Vidushi Sharma, Diptangshu Dey, Aaryan Khandelwal, Pavan Kumar Kondeti, Viswanath Kraleti And also thanks to the sponsors and to the IIT Kanpur! And especially thanks to Canonical for funding my trip, and also to Mauro Gaspari and Gemma Mulcahy for making this going smoothly and helping quickly where needed. And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions"
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-3.0",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 3.0",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-3.0",
+ "headings": [
+ "IIT Kanpur",
+ "Ubuntu meets Opportunity Open Source",
+ "Call for Proposals is open",
+ "Let us celebrate a great event!"
+ ],
+ "tags": [],
+ "teaserImage": "/assets/images/oosc-2.0-2024-1.png",
+ "snippet": "Opportunity Open Source 3.0, again in IIT Kanpur in India, on Sep 5-7, co-located with the first UbuCon India",
+ "content": "Some pictures of the OOSC 2.0More pictures of the OOSC 2.0 After two great Opportunity Open Source conferences we go into the third round! With the success we had last year in the IIT Kanpur, especially also because of the great on-location organization team of the IIT Kanpur (thanks again), and them having offered to us to organize the conference again, we have decided to do it in Kanpur a second time. Sanskar Yaduka and Shreya Shree, students at the IIT Kanpur are leading the on-location organization, setting up a team of volunteers and looking for local sponsors. As in the other years we want to motivate students (and also professors and researchers) to learn about free and open-source software and to join the community of developers and contributors. Not only coding and debugging can be contributed, but also designers, technical authors, evangelists, ... are highly welcome. Last year, we had the Opportunity Open Source one week before the UbuCon Asia 2024 which had taken place in Jaipur, also in India. Having people of the Indian Ubuntu community organizing the event and also others attending it, they decided to reactivate the Ubuntu Local Community (LoCo) India. Bhavanishankar Ravindra (\"Bhavi\") and Soumyadeep Ghosh are currently leading these efforts. They also want to have an UbuCon India conference and I suggested to co-locate it with the upcoming Opportunity Open Source, as many UbuCons are co-located (UbuCon North America on SCaLE, UbuCon Portugal on Festa do Software Livre, UbuCon Europe on OpenSouthCode, ...), they accepted my suggestion, and we started planning ... Canonical also offered to sponsor a conference in India, Opportunity Open Source or UbuCon India, and now with the co-location both. Setting the date for our event right one week after the UbuCon Asia 2025 in Kathmandu, Nepal we can have some speakers doing the Nepal/India round trip and this way enrich our event with more international speakers. But to make the event really great, we need your contributions: Talks, panels, workshops, demo tables, lightning talks ... Show us how you are contributing to free and open-source software, how you make our lifes better with it, You do not need to be a coder. also sessions about documentation, design, community, success stories, ... are highly welcome. Our Call for Proposals is open! Until June 16, 2025! So please post your proposals. We (and also our attendees) are eager to have your contribution on our conference. Please pay special attention to the new \"UbuCon India\" track. Your Ubuntu-related submissions to here will make up the first UbuCon India. We will again have many sessions about OpenPrinting, Zephyr, Google Summer of Code, Snap, ... Many workshops and this time also several Ubuntu-related ones. We also want to have some demo tables, where things can be tried out hands-on and conversations will fuel an exciting hallway track. And if it works out, we will also offer a Hackathon again. Also, this time, we are not coinciding with any exam periods at The IIT Kanpur and so expect significanly more attendeeds as last year. And the first UbuCon India will also attract people from other places all over the country. We hope to see you all in India ... ... but you are also welcome to attend and/or speak remotely Event web site UbuCon India Practical info: Location, remote attending/speaking, ... Call for proposals Mastododon: #OpportunityOpenSource and #UbuCon And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-4.0-Call-for-Locations",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 4.0 - Call for Locations",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-4.0-Call-for-Locations",
+ "headings": [
+ "Requirements",
+ "City",
+ "Venue",
+ "Date",
+ "Local organization team",
+ "A/V Requirements",
+ "Accommodation for speakers and non-local attendees",
+ "Meals",
+ "Conference dinner/closing party",
+ "Hackathon (optional)",
+ "Sponsoring",
+ "Participation fees",
+ "How to place your bid?",
+ "Till Kamppeter",
+ "Aveek Basu",
+ "Opportunity Open Source on LinkedIn"
+ ],
+ "tags": [],
+ "snippet": "Where will the 4th edition take place? Please send us your proposal!",
+ "content": "The Opportunity Open Source conferences which take place every year in a university/college/IIT/… in India are for showcasing free and open source software (FOSS) and for motivating students, professors, and researchers to participate in its development, by contributing code, design, documentation, … With talks and hands-on workshops a wide range of FOSS topics is covered, and often also a hackathon (coding competition) day is added. In the last year we got around 300 attendees, and many of them showed interest and started to get involved. And so after 3 successful editions of the Opportunity Open Source conferences in India (1.0 in Mandi, 2.0 in Kanpur, 3.0 in Kanpur) we want to celebrate the fourth one. For that we need a place to do so. It should be somewhere in India and to give people all over India this opportunity of experiencing open source, we want to run each edition at a different place and therefore we are looking for a new location for this year's edition. If you are interested, we want to hear from you. First just tell us that you are interested and then we will ask you, and also guide you, for your detailed bid. We will close the call for locations on March 15, 2026, 23:59 IST The content for the conference days, talks, workshops, and booths will be supplied by the global organizers of the Opportunity Open Source. Once we have selected the location we will publish a Call for Proposals (CfP) so that people who want to contribute content can propose their talk, workshop, or booth. We will select an appropriate amount of the most interesting proposals to fill the given rooms during the given amount of conference days then. The city (must be in India) where the event will take place should be easily reachable from all over India, by plane or by train, so that speakers and non-local attendees can participate without problems. We also prefer cities where not just your university/college/IIT is located but also others (also in nearby cities), as people from there will also attend the Opportunity Open Source. We like to run the conference at universities, colleges, IIT, … places where one can study computer science as here we expect a large audience. Naturally students, professors, and researchers from other areas and people from other institutes nearby can also attend. For the conference days we will need three rooms for the sessions: A plenary room and a breakout room for the talks, plus a room for the workshops. The 2 rooms for the talks can be lecture halls, the workshop room is ideally a classroom with tables and where one could provide power outlets or power strips for the attendee's laptops. We expect typically around 300 attendees, so the plenary room should fit this amount of people. There should also be some area for the \"hallway track\" where people hang out and chat. There should also be located any exhibition booths, from sponsors and/or from open-source projects. Also tea, coffee, and snacks for the tea breaks could be provided here. Ideally the 3 rooms are directly connected to this area, but they should at least be nearby. For a hackathon day we need one big hall (like a gym hall) where tables for each participating team can be placed. The tables need to get supplied with power strips for the participant's laptops. The conference should take place on a weekend between mid-August and end-September, or in November. Before mid-August it is too close to the summer holidays and so the local team has not enough time on campus for preparing the event. October is the festive season in India. Also exam weeks need to be avoided. Not only that the students are preparing themselves for their exams and not attending but also rooms reserved for the conference can get suddenly taken for exams, even on Sundays. Also exam weeks of nearby institutes should be taken into account. Also to be avoided are the dates of other important conferences, especially the UbuCon Asia which takes place on August 8-9 in Taipei, Taiwan and the India FOSS by FOSS United (date and location TBD). The most important part of a successful conference is the on-location organization team, a group of volunteers, in our case usually students, but could also be some local open source organization, who do everything needed at the conference location. This is especially talking with the institute's administration to reserve conference rooms, guest rooms in the on-campus guest house and in student hostels for speakers and non-local attendees, arranging lunch on the conference and hackathon days, organizing the conference dinner/closing party, finding (local) sponsors to cover the costs, assuring the needed technical setup of the rooms: Internet (wired for streaming, wireless for attendees), A/V, booth space, power strips, …, lining up a team of volunteers, including crews for the rooms, local marketing of the event in social media … A lot of things which have to be done on-site … Here is an example of the organization team of last year. In each of the 3 conference rooms we do not only want to make the slides of the talks being visible for everybody and the speakers being heard by everybody, but we want to, as it is done on practically all conferences nowadays, stream the sessions live, record them, and also allow remote speaking. For this, each of the 3 rooms will need: A projector (to project image from laptop, usually built into the room) Speakers (to output audio from laptop, usually built into the room) Microphones (wireless clip-on, headset, hand microphones, which can send audio to a laptop, usually provided by the room) 1 or 2 cameras (which can send video to a laptop) A powerful laptop which can do video streaming Wired internet connection (or phone or travel router which provides unlimited 5G cell data) A second laptop for the projection A third laptop for checking for questions of remote attendees via chat Note that the A/V setup should be centered by the A/V laptop to assure that the audio in the room and for the remote attendees and remote speakers is the same, without in-person speakers having to use 2 microphones. We will provide a (remote) server with Nextcloud and VDO.Ninja (planned for now, subject to change). Each room needs the following crew of volunteers (changing in half-day shifts): MC: They introduce into the talk, show \"15 min left\", …, manage Q&A A/V director: They take care of streaming, remote speaking, and recording, via the A/V laptop Mic runner: They bring the hand mic to people to ask questions, can also show \"15 min left\", … during the talk. Camera operator: Takes care that speaker is in the frame Remote chat manager: Checks whether remote attendees have questions The accommodation should be ideally on-campus so that there is no long commute needed, and especially not one which is partially outside and partially inside the campus to avoid that taxis or auto-rickshaws from outside have to go through the security of the campus. It gets much easier if one can walk to the conference rooms or use a campus-internal auto-rickshaw. For speakers and non-local organizers there should be single rooms in a guest house (where usually international guest professors and researchers stay). The guest house should have 24-hour service to quickly respond if there are any problems with the room. Non-local attendees can get accommodated in student's hostels. There needs to be breakfast available for those who are in the accommodations and lunch for all participants on the conference and hackathon days. After the second conference day we want to do a closing event, at least a conference dinner of all the organizers and speakers, but ideally a closing party for all participants. For this we need a suitable restaurant in case of a dinner or a suitable location/venue and catering for a party. In addition to the actual conference consisting of talks and workshops we also want to do (but it is not required) a hackathon, a programming competition. We as global organizers of the Opportunity Open Source will not organize the hackathon. The content/subject matter has to be organized locally. In the last 2 years sponsors were providing this. All the above usually cannot get supplied free of charge. So the costs of each item need to be estimated and an estimate of the total cost of the conference be made. To cover the costs sponsors are needed, principally local ones as the event is principally intended for local attendees. National or international sponsors are welcome. To make it easier for sponsors to contribute, sponsorship tiers (platinum, gold, silver, …) should be offered. Each tier requires to pay a given amount and the sponsor gets perks as compensation, like more or less prominently placed logos, on the web site, on posters at the venue, … mentions in the opening and closing plenaries, a booth of a certain size, … Dedicated sponsoring, like for the closing party, the hackathon, … should be also accepted. In the previous years we have taken fees from the participants for meals and for accommodation, the latter only if needed. Also the accommodation for attendees was a student hostel, so it was not very expensive. As most participants are students, we should try to cover as much as possible of the costs of the event by sponsors and keep the participation fees as low as possible. If you like to have the Opportunity Open Source 4.0 take place at your institute and you are able to provide the above-mentioned items, you should contact us with a first e-mail/message before end of February, but the earlier, the better, as we need your complete bid until March 15, 23:59 IST. Your complete bid should go through the above items and tell what you have available at your place and who will be the local organizer team, which organization, community and who will be responsible for which part. Please provide photos of the city and venue, floor plans, and other supporting images. If your organization/community already has experience with organizing events, especially conferences, perhaps even in the area of open source, please tell. Please also list estimates for all the costs and the total budget for the event. If you already have sponsors please tell who they are and how much they want to contribute. Your first message and your complete bid please send to the global organizers of the Opportunity Open Source, Till Kamppeter and Aveek Basu. e-Mail: till at linux dot com LinkedIn: https://www.linkedin.com/in/kamppetertill/ Telegram: https://t.me/tillkamppeter Matrix: @till-kamppeter:ubuntu.com e-Mail: basu dot aveek at gmail dot com LinkedIn: https://www.linkedin.com/in/basuaveek/ @OpportunityOpenSource
And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions"
+ },
+ {
+ "id": "post:OpenPrinting-News-Opportunity-Open-Source-4.0",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Opportunity Open Source 4.0 in the IIIT Allahabad",
+ "url": "/OpenPrinting-News-Opportunity-Open-Source-4.0",
+ "headings": [
+ "IIIT Allahabad",
+ "Selecting the date",
+ "Call for Proposals is open",
+ "Let us celebrate a great event!"
+ ],
+ "tags": [],
+ "teaserImage": "/assets/images/oosc-2.0-2024-1.png",
+ "snippet": "Opportunity Open Source 4.0, in the IIIT Allahabad in Prayagraj, Uttar Pradesh, India, on Aug 28-30",
+ "content": "Some pictures of the OOSC 2.0More pictures of the OOSC 2.0 After three great Opportunity Open Source conferences we will celebrate the forth one! Photos and description of the location contributed by Sudhanshu Sah Our Call for Locations showed a lot of interest. Several groups from different places in India have answered (mainly on LinkedIn). Some only told in a short answer that they are interested but did not follow up, and 4 groups gave more detailed information and had a video meeting with us. In the end, the most convincing bid came from the Google Developer Group (GDG) IIIT Allahabad and we settled with them. IIIT Allahabad stands among India’s premier technology institutes, located in the historic and intellectually vibrant city of Prayagraj, in the state Uttar Pradesh in India. Renowned for its rich cultural legacy, academic excellence, and deep-rooted scholarly atmosphere, Prayagraj has long been a meeting point of ideas, innovation, and learning. IIIT Allahabad: Main GateIIIT Allahabad: Clock Tower
IIT Allahabad: Main Gate and Clock Tower The region hosts some of the country’s most respected educational institutions, including MNNIT Allahabad, the historic University of Allahabad, SHUATS, and several other prominent institutes and research centres. Together, they create a dynamic academic ecosystem that attracts students, researchers, developers, innovators, and technology enthusiasts from across India. With this we also count with many more attendees than just those from IIIT Allahabad. The conference will be held across selected campus venues at IIIT Allahabad, including Computer Centre-3 (CC-3 / C. V. Raman Bhavan), the Auditorium (Plenary), and the Admin Auditorium (Breakout). These spaces will host talks, workshops, discussions, and other conference activities. The campus also provides suitable facilities for attendees, including dining options and other essential support for a smooth event experience. Main AuditoriumAdmin Auditorium
IIT Allahabad: Main Auditorium and Admin Auditorium Details regarding sponsors are currently being finalized and will be shared in due course. Rishu Kumar, Sudhanshu Sah, and Aditya Ajay will be the overall coordinators, and together with faculty coordinator Prof. Bibhas Ghoshal they will create a team of volunteers, mostly students who will do the on-location organization. They will look for local sponsors, reserve conference rooms and spaces for hallway track and exhibition, accommodation for speakers and non-local attendees, organize meals, prepare and test audio/video setup in the rooms, ... The date we have set to be some weeks after the summer break at the IIIT, so that the students volunteering in the organization team are back for some weeks already to have time to prepare the event. On the other side we also had to care not to fall into an exam week, so that students have time to attend. Another criteria for the selection of the event date are other national and international conferences happening at this time, especially the aKademy 2026 in Graz, Austria, on September 19-24, and the IndiaFOSS in Bengaluru, on September 26-27. And in October we have the festive season in India. So we ended up choosing August 28-30 (Fri-Sun), the last weekend of August. As in the other years we want to motivate students (and also professors and researchers) to learn about free and open-source software and to join the community of developers and contributors. Not only coding and debugging can be contributed, but also designers, technical authors, evangelists, … are highly welcome. And to make this event really great, we need your contributions: Talks, panels, workshops, demo tables, lightning talks ... Show us how you are contributing to free and open-source software, how you make our lives better with it, You do not need to be a coder. also sessions about documentation, design, community, success stories, ... are highly welcome. Our Call for Proposals is open! Until July 3, 2026! So please post your proposals. We (and also our attendees) are eager to have your contribution on our conference. We will again have many sessions about OpenPrinting, Zephyr, Google Summer of Code, AI/LLMs/ML, ... And especially we will again have many interactive workshops where you can learn new skills hands-on. So bring your laptop and experience it by yourself. We also want to have some demo tables, where things can be tried out and conversations will fuel an exciting hallway track. And if it works out, we will also offer a Hackathon again. We hope to see you all in India ... ... but you are also welcome to attend and/or speak remotely LinkedIn Site Practical info: Location, remote attending/speaking, ... Call for proposals Mastodon: #OpportunityOpenSource And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-September-2019",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - September 2019",
+ "url": "/OpenPrinting-News-September-2019",
+ "headings": [
+ "Google Summer of Code 2019",
+ "1. Generic Framework to turn legacy drivers consisting of CUPS filters and PPDs into Printer Applications",
+ "2. Improve the pdftoraster filter to not use undocumented/unstable APIs of Poppler",
+ "3. IPP: ipptool test suite updates for IPP errata updates",
+ "4. ipptool test suite for IPP System Service",
+ "5. Turn the scp-dbus-service of system-config-printer into C",
+ "Avahi",
+ "OpenPrinting web site",
+ "CUPS",
+ "cups-filters",
+ "ippusbxd",
+ "Common Print Dialog Backends"
+ ],
+ "tags": [],
+ "snippet": "End of Google Summer of Code 2019, Avahi, OpenPrinting web site work, CUPS 2.3.0 released, cups-filters 1.25.4, cpdb-backend-cups workaround for CUPS bug",
+ "content": "Coding ended and the final evaluations are completed, the completed projects officially announced by Google. For the Linux Foundation we got 12 student slots in the beginning and after 1 stucent dropping out before coding started we had 11 students working. 2 failed in the second and 2 in the final evaluations, leaving 7 having completed their GSoC projects. This is the worst year in terms of failing students for us. For OpenPrinting there started 5 students and and 1 failed in the final evaluation. The other 4 completed the program successfully. Here are the projects with their submitted work product links: Student: Dheeraj Yadav
Mentor: Till Kamppeter
Work Product PASSED Dheeraj will soon work with Sahil to get his Printer Application framework documented on the new OpenPrinting web site. Student: Tanmay Anand
Mentor: Sahil Arora
Work Product PASSED Tanmay completed his original project already in the first month. We asked him whether he would take a project for the rest of the time and he accepted. So he worked also on the adapter backend for the GTK3 print dialog to use the Common Print Dialog Backends (CPDB). Mentor for this project is Dongxu Li. He did not complete this at the end of the GSoC but promised to complete it after GSoC. Student: Sharad Shukla
Mentors: Smith Kennedy, Ira McDonald, Danny Brennan
Work Product PASSED Sharad will soon complete his not yet completed assignment of the bannertopdf filter also supporting the old bannertops input format. Student: Aakash Lahoti
Mentors: Smith Kennedy, Ira McDonald, Danny Brennan
Work Product PASSED Student: Sobhan Mondal
Mentors: Zdenek Dohnal
Work Product FAILED (final evaluation) Sobhan promised to complete his work after GSoC. The project results will also get added to the new OpenPrinting web site. Mike Sweet has posted on Avahi GitHub Issue #125 and he is of the same opinion as me that the DNS-SD records of local services via the loopback (\"lo\") device should carry the \"localhost\" host name and not the network host name of the machine: If Avahi returns 127.0.0.1 as one of the addresses for a .local lookup, that will cause some serious security problems when machine A (a.local.) looks up machine B (\"b.local.\") and gets its own loopback address. By returning localhost (\"localhost.\") that security issue is avoided. Keep in mind as well that when CUPS tries to connect to a printer/server, it tries all of the addresses returned by a lookup in parallel until one of the connections succeeds. Since CUPS also validates the Host: header in requests (and block any attempt to communicate with cupsd over the loopback interface if the hostname is not \"localhost\" or \"localhost.\"), this will result in a successful connection but a failed request, breaking printing. So you really do need to return \"localhost\" for services registered on the loopback interface. No reaction from Trent Lloyd yet. Now with the GSoC completed we are resuming our work on the web site with Sahil leading the project. Most of the site is in place, most important part to add now are the results of the 5 GSoC projects of this year. Also we need to link to the OpenPrinting database interface web app (Issue #55). We will continue using this web app and the MySQL database (which we now feed from the foomatic-db repository on GitHub) as it is not worthwhile (possible?) to implement a replacement on it running on GitHub. The web app needs to get the outfit of our new web site (Issue #58). 2.3.0 released. CUPS 2.3.0 is finally out! And the licensing resolved! With more than one year or 3 Ubuntu releases of delay it appeared on Fri, August 23, the day after Ubuntu Eoan (19.10) Feature Freeze. The license solution is that the Apache 2.0 license gets an exception added which allows linking with (L)GPL software, so cups-filters and other software using the CUPS library does not need any license change. For new features see Mike's slides of the last OpenPrinting Summit. No changes on 2.2.x branch. Currently released is 1.25.4. Many releases happened during the short time to get bug fixes into the upcoming Ubuntu 19.10 (Eoan). 1.25.5: Bug fix release, mainly for cups-browsed not to die on left over locally generated queues of unclaen shutdown of the previous session. 1.25.4: Bug fix release for the page geometry and CUPS Raster output issues in the imagetoraster, imagetopdf, and pdftoraster filters. 1.25.3: Bug fix release, especially to fix a compatibility issue with CUPS 2.2.12. 1.25.2: Improved cups-browsed's handling of the DNS-SD records of advertised local and remote IPP print services. Especially make sure that local queues do not get already removed when the service on a single network interface disappears (for example Wi-Fi turned off) while still present on other interfaces. Also let local services preferably be accessed through the loopback (\"localhost\") interface to avoid data leaks into the network. No further news. When packaging CUPS 2.2.12 for Ubuntu Eoan (19.10) the automatic tests of Ubuntu's build servers failed cpdb-libs and after several days of debugging I found out that libcups is not initializing some glbal variables with default host name, port, domain socket file for the local CUPS server in some cases. This prevented the CUPS backend from accessing the printer's capabilities via get-printer-attributes IPP request and I had to apply a workaround in the cpdb-backend-cups project. We have reported Issue #5642 on the GitHub of CUPS. A workaround for the time being was applied to cpdb-backend-cups, with this commit Released cpdb-backend-cups 1.1.1 with the fix:"
+ },
+ {
+ "id": "post:OpenPrinting-News-September-2020",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - September 2020",
+ "url": "/OpenPrinting-News-September-2020",
+ "headings": [
+ "OpenPrinting Microconference on Linux Plumbers Conference 2020",
+ "Google Summer of Code 2020",
+ "1. Extract raster data from PDFs for direct printing",
+ "2. General Printer Application SDK",
+ "3. Linux GUI application to admin MF devices using IPP System Service",
+ "4. Make Printer Applications Configurable",
+ "5. Speed/Scaling Optimisation of cups-browsed",
+ "6. Common Print Dialog Backends (CPDB) Qt Implementation",
+ "7. IPP Scan (or virtual MF device) server (Scanner Application)",
+ "Google Season of Docs 2020",
+ "Linux Foundation Mentorship Program",
+ "CUPS Snap",
+ "Printer Applications",
+ "Driverless Scanning and IPP-over-USB",
+ "CUPS",
+ "cups-filters"
+ ],
+ "tags": [],
+ "snippet": "GSoC final results, Linux Plumbers recording, GSoD, LFMP, CUPS temporary fork, cups-filters 1.x fork",
+ "content": "We successfully did our second OpenPrinting microconference! There is a complete recording on YouTube (same links as for the live broadcast during the conference). But note that this one is created automatically by the video conference system, and the edited version will get posted later. We talked about the following topics (links to the slides in PDF format): Introduction - Aveek Basu Printer Applications - A new way to print in Linux - Michael Sweet 3D Printing - Michael Sweet IPP scan (or virtual MF device) server (Scanner Application) - Alexander Pevzner Designing and Packaging Printer and Scanner Drivers - Till Kamppeter IPP Standards Landscape - Ira McDonald IPP Fax Out - A new reality - Aveek Basu 20 Years on Printing with Free Software - Till Kamppeter The video conferencing system and the live broadcast worked very well, having around 40 listeners in our virtual room and up to 17 listeners on YouTube. Thanks again to the great work of the organizers! But I hope we will be able to meet in person again in 2021. Coding ended and the final evaluations are completed, the completed projects officially announced by Google. For the Linux Foundation we got 15 student slots in the beginning and after 1 student dropping out after the first month we had 14 students reaching the final evaluations. 1 of them failed and the other 13 passed. For OpenPrinting there started with 7 students, 1 being the one who quit after one month and 1 failed in the final evaluations, having 5 who completed the program successfully. Here are the projects with their submitted work product links: Student: Vikrant Malik
Mentors: Sahil Arora, Till Kamppeter
Work Product PASSED Student: Jai Luthra
Mentors: Michael Sweet, Till Kamppeter
Work Product PASSED Jai has principally worked on PAPPL but also done an HP PCL sample Printer Application. In the end he has also worked on converting filters of cups-filters into filter functions. Student: Lakshay Bandlish
Mentor: Michael Sweet
Work Product PASSED Student: Sambhav Dusad
Mentor: Michael Sweet
Work Product PASSED Sambhav has also started to create a Gutenprint Printer Application. Student: Mohit Mohan
Mentors: Deepak Patankar, Till Kamppeter
Work Product PASSED Student: Priydarshi Singh
Mentor: Dongxu Li
Work Product FAILED (final evaluation) We are looking into finishing up CPDB after GSoC. Student: Aakash Lahoti
Mentors: Michael Sweet, Alexander Pevzner WITHDRAWN (shortly after first evaluation) We have replaced this project by a 2-student LFMP project (see below). Our OpenPrinting project Tutorial and Design Guidelines for Printer/Scanner drivers in Printer Applications got accepted! Piyush Goyal will write for us in the next three months (September 14 - December 5). In total we got 5 projects accepted for the Linux Foundation. In our first LFMP project Dipanshu Verma, working on retro-fitting proprietary classic printer drivers into Printer Applications had to withdraw, as his college suddenly re-established the classes after the pandemic interruption. In the first months he has done several tests of installing closed-source drivers into a chroot, see his work on GitHub. Nidhi Jain has successfully expanded the driverless tool of cups-filters (which allowed setting up driverless printers with classic printer setup tools) to also work for IPP Fax Out queues, allowing to use the Fax send facility of most modern multi-function printers easily, as devices supporting AirPrint usually support also IPP Fax Out. The functionality is fully working in cups-filters from version 1.28.2 on and will also be included in Ubuntu 20.10 (Groovy Gorilla). In the printer setup tool you find your printer under the discovered network printers (also if it is connected via USB, as IPP-over-USB is used then). Select this entry and when it comes to select the driver, select the entry with \"Fax, driverless\". If you want to fax print the document to this queue and in the print dialog (GTK/GNOME or LibreOffice) select \"Custom\" in the \"Phone Number\" option and enter the destination fax number. Parameters like sender info on the fax, default prefixes, repetition of failure, ... you configure with the devices web admin interface. Nidhi was supposed to add fax support to the Common Print Dialog Backends (CPDB) now, but as development did not make it far enough to do so and due to the withdrawal of Dipanshu we have asked her to carry on on retro-fitting classic printer drivers into Printer Applications. Update: Nidhi agreed and will now work on retro-fitting classic printer drivers. As a replacement for our incomplete GSoC project on IPP Scan we are running our second LFMP project. Here we have selected our students now and they have started working in the beginning of this month: Expand PAPPL for scan support, Scanner Applications (IPP Scan as a server)
Student: Abhik Chakraborty Expand sane-airscan to support IPP Scan (IPP Scan as a client)
Student: Rishabh Arya Abhik will get primarily mentored by Michael Sweet and Rishabh by Alexander Pevzner. The CUPS Snap project is currently waiting for the snapd project to add the needed API extensions. The Pull Request for the implementation of the new \"cups\" and \"cups-control\" interfaces got merged into snapd. The pull request for adding the API functionality so that a Snap can check whether a client Snap plugs the needed interfaces is still in the works. On the Printer Apllications side Sambhav Dusad, GSoC 2020 student, has started to work on creating a Gutenprint Printer Application. As Gutenprint provides all printer capability through its library (PPD files are auto-generated) this will be the first larger-scope native Printer Application. We also have already the following filter functions in cups-filters: pstops, pdftops, pdftopdf, ghostscript (replaces gstoraster, gstopdf, gstopxl), pclmtoraster, rastertopdf (replaces rastertopdf amd rastertopcl), rastertops, and filterChain Special thanks go to Vikrant Malik and Jai Luthra for their work on the filter functions. On the printing-architecture mailing list at OpenPrinting we had a discussion about whether CUPS is still needed with Printer Applications and IPP devices in place: Will IPP printer devices and Printer Applications obsolete the cupsd? Note that for participating in these discussions you have to subscribe to the printing-architecture mailing list. The Main Inclusion Requests (MIR) to get ipp-usb and sane-airscan into Ubuntu Main have passed the general checks of the Ubuntu MIR team and are waiting for the reviews of the Ubuntu security team. Alexander Pevzner is continuing to take user reports and make the packages working with as many devices as possible. IPP Scan support is currently added to sane-airscan as a LFMP project. Currently released is 2.3.3. Due to dormant upstream development we have discussed to create a (temporary) fork on OpenPrinting for bug fixes and distribution patches and Michael Sweet has done it now. Currently released is 1.28.2. On the way towards 2.0.0 we have converted many filters to filter functions, having now pstops, pdftops, pdftopdf, ghostscript (replaces gstoraster, gstopdf, gstopxl), pclmtoraster, rastertopdf (replaces rastertopdf amd rastertopcl), rastertops, and filterChain filterChain() is a special filter function which takes an array of filter functions as parameter and passes the input data to all these filter functions subsequently, allowing for conversions for which there is no single filter function available. Special thanks go to Vikrant Malik and Jai Luthra for thei work on the filter functions. To allow further releases of cups-filters during the transition from 1.x to 2.x I have created a 1.x branch into which I cherry-pick all the bug fixes and some smaller feature additions. This branch is especially the source for the current cups-filters packages in Debian and Ubuntu. Here I have especially added the driverless fax support and the IPP/IPPS support in the driverless utility, from Nidhi Jain's LFMP project (see above). Also many bug fixes, especially crashes and memory leaks of cups-browsed, are included here. 1.28.2: Bug fix release to mainly fix cups-browsed not shutting down and the driverless utility being slow when listing available printers/faxes 1.28.1: Bug fix release to fix several bugs in the new IPP Fax Out support by the \"driverless\" utility and also to fix some minor issues 1.28.0: Feature release (probably the last one before 2.0.0) which adds IPP Fax Out support, IPPS support, and a command line option to reveal standard IPP URIs to the \"driverless\" utility, added log file size limitation and command line options to control what happens to generated queues on shutdown to cups-browsed, fixed several bugs when printing PostScript input files, several bugs and memory leaks in cups-browsed, crashes on the presence of certain fonts, and many more fixes."
+ },
+ {
+ "id": "post:OpenPrinting-News-September-2021",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - September 2021",
+ "url": "/OpenPrinting-News-September-2021",
+ "headings": [
+ "Debian has a new printing maintainer!",
+ "OpenPrinting Micro-Conference on the Linux Plumbers 2021",
+ "The Summer of Printers in the Ubuntu Office Hours",
+ "Google Summer of Code 2021",
+ "pappl-retrofit - The CUPS Driver Retro-Fit Library",
+ "Ghostscript Printer Application",
+ "HPLIP Printer Application",
+ "PostScript Printer Application",
+ "CUPS Snap",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/5KogjLb1Hb4/hqdefault.jpg",
+ "snippet": "OpenPrinting Micro-Conference on Linux Plumbers, OpenPrinting in Ubuntu Office Hours, GSoC results, pappl-retrofit, Ghostscript and HPLIP Printer Applications",
+ "content": "Didier Raboud (\"OdyX\") is going on a 6-month sabbatical and therefore leaving his position as printing guru of Debian. Thorsten Alteholz is overtaking here. OdyX and me have introduced him and he already started off well. Thanks a lot to OdyX for all his work on Debian's printing part and the great collaboration with me and to Thorsten for overtaking where OdyX has left off. Linux Plumbers 2021 is approaching! It will start on Monday next week (Sep 20, 2021) right away with our OpenPrinting micro-conference on the first day! Yes, our micro-conference will take place on Monday, September 20, 2021, 7am - 11 am Pacific or 14:00 - 18:00 UTC The conference is all-online again, as 2020, due to the travel restrictions caused by COVID-19. Update: Recording of the micro-conference on YouTube We will have the following sessions: CUPS 2.4/2.5
Presenter: Michael Sweet
CUPS 3.0
Presenter: Michael Sweet
Print Management GUI
Presenter: Till Kamppeter
Common Print Dialog Backends
Presenter: Till Kamppeter
Printer/Scanner Driver Design and Development
Presenter: Till Kamppeter
Scanning in PAPPL
Presenter: Bhavna Kosta
Note that these sessions are not just slide presentations, there are some slides to introduce into the subject matter, but as the Linux Plumbers micro-conferences are intended for, we will discuss the about issues, decisions, design, ... to put our future work into the right direction, and for answering questions of the attendees. The exact schedule is posted on the Linux Plumbers web site. Registered attendees can participate interactively in the live discussions. Probably there will also be the possibility for non-interactive watching of the micro-conference on YouTube and a recording on YouTube after the micro-conference, as last year. Once a week, every Thursday in the US morning and the European afternoon on the \"Ubuntu OnAir\" YouTube channel of the Ubuntu community, the live event \"Ubuntu Office Hours\" is taking place. In each episode a free software community member is invited to tell about his project and what is happening in its community. In the October 7 episode (3 weeks from today) it is all about OpenPrinting. Organizer and host Monica Ayhens-Madon has invited me to talk about GSoC and the students I have mentored. There will not only Monica and me be on the (virtual) stage but also OpenPrinting program manager Aveek Basu and some of this year's (and perhaps also former year's) GSoC students. We will tell about our GSoC work and its achievements, not only of code but also the community growth, and what students have done after the summer, like mentoring the next students or creating our current web site. We will also call for volunteers to join OpenPrinting and to contribute, and also answer the spectator's question which they post on the YouTube Live Chat of the session. Please mark in your calendars: (CORRECTION) Thursday, October 7, 2021, 15:00 - 16:00 UTC It will take place on YouTube and everyone can participate, without registration and free of charge. Everyone can post questions on the YouTube Live Chat. For everyone who wants to get some technical background, Michael Sweet and me have talked about the ongoing changes in the architecture of printing with free software three weeks ago in the Ubuntu Indaba (recording on YouTube). See you there! The Google Summer of Code 2021 has ended successfully for OpenPrinting! All our 5 students have passed final evaluations and did great work. The projects are mostly completed, only some debugging and polishing is currently taking place. Most of the code is already committed to the respective upstream GIT repositories (and partially already in use in the CUPS-driver-retro-fitting Printer Application Snaps). There was a presentation of the GSoC projects on the PWG August 2021 Face-to-Face Meeting which has taken place online on August 17-19, 2021. There we have shown this video where every student has presented his project. Here are the projects with their submitted work product links: cups-filters: Make sure all filter functions work without PPD files
Student: Suraj Kulriya
Mentors: Jai Luthra, Till Kamppeter, Dheeraj Yadav
Work Product PASSED cups-filters: Convert filters to filter functions
Student: Pratyush Ranjan
Mentors: Till Kamppeter, Dheeraj Yadav
Work Product PASSED cups-filters: Create a single, universal CUPS filter to replace the chain of individual filters
Student: Pranshu Kharkwal
Mentors: Till Kamppeter, Dheeraj Yadav
Work Product PASSED GUI for listing and managing available IPP Print/Scan services (or DNS-SD-advertised network services in general)
Student: Divyasheel
Mentors: Till Kamppeter
Work Product PASSED PAPPL: Printer setup tool support and Scanning support
Student: Bhavna Kosta
Mentors: Jai Luthra, Till Kamppeter, Michael Sweet
Work Product PASSED Printer Applications retro-fitting classic CUPS printer drivers consisting of PPD files, CUPS filters, and CUPS backends, like currently the PostScript, Ghostscript, and HPLIP Printer Applications, have a lot in common and share most of their code. Therefore I have continued the development of the code of the PostScript Printer Application by generalizing it for any type of classic CUPS printer driver (see previous News posts and the sneak previews of my work during the last months) and put it up on the OpenPrinting GitHub as the PAPPL Retro-Fit Library. This library will also be the start of several other CUPS driver retro-fits making all the drivers from the last (even more than) 21 years available for the new all-IPP, PPD-less printing architecture. 21 years ago I migrated all printer drivers into CUPS, now I am migrating them into the next architecture. The library makes creating a Snap of a CUPS driver as easy as creating a Snap of any other application. It contains 98 % of the C code needed to create a PAPPL-based Printer Application around the CUPS driver. Only C code still needed is a main() function stub setting the configuration of the Printer Applications (Which features are used, which are the resource/log/spool/state directories?) and perhaps a printer auto-discovery function (Which printers are supported?). Otherwise one needs only the driver with all its files and some extra packages like Ghostscript, libcups, libcupsfilters, libppd, ... The driver's files (PPDs, filters, backends) only need to get placed in the appropriate directories for the Printer Application to find them. No need to change the code of the drivers, so it is also easy to retro-fit unmaintained drivers, drivers for which one does not have an appropriate printer to test, and even proprietary, closed-source, binary-only drivers. Then one can create print queues with the printers being auto-discovered (by PAPPL's backend and/or included CUPS backends) and the model/driver (PPD file) can be automatically or manually selected (each \"Driver Name\" drop-down entry on the \"Add Printer\" web interface page is one PPD file). When printing a job the IPP attributes are automatically mapped to the best-fitting PPD option settings, to easily allow to make use of the features of the printer, even on clients with limited print dialogs, like phones or IoT devices. The web interface also allows to manually set defaults for all PPD options for more detailed control. Even options requiring CUPS PPD extensions, numeric, string, password, fax number, ... options are supported. All current retro-fitting Printer Applications (PostScript, Ghostscript, and HPLIP) are using this library now. The Printer Applications created with this library can also be run directly on the system, without being in a Snap, especially the Test Printer Application which comes with the library and sets its resource directories to use all the PPD files, filters, and backends of the system's classic CUPS installation. This allows testing installed drivers how they work under a Printer Application or allows installed drivers to be used with an installed CUPS Snap. All important features are included now. Further development of the library will go with the development of PAPPL and the needs of the Printer Applications. Especially the following features will get implemented/supported as soon as they are implemented/fixed in PAPPL: Support for string/text-style vendor options. Needs support in PAPPL (Patch already applied in the Printer Application Snaps). Human-readable strings for vendor options. Needs support in PAPPL. Ink level check via ps_status() function. Needs support in PAPPL. Ghostscript Printer Application in the Snap Store, 194 installations via Snap Store If you want to use an (older) printer which is not a modern driverless IPP printer and is also not a PostScript printer (which would be supported by the PostScript Printer Application then) Then this is the right Printer Application for you. It supports ~5000 different printer models, mainly with drivers from the well-known Ghostscript but also some others. The printer model support is based on OpenPrinting's printer support database (Foomatic). Especially many standard laser (PCL 6/XL, PCL 5c/e, PCL4) and dot matrix (ESC/P, OKI, IBM, ...) but also many printers with proprietary print data formats are supported. There are not only model-specific entries to choose from, but also generic entries for the common formats for the case your printer is not explicitly listed. The Printer Application gives access to all the options of the former PPD files inside its web interface (\"Device Settings\", \"Media\", \"Printing Defaults\") but can be easily used from any IPP-compliant client application or device. The standard IPP attributes are automatically converted to the best-fitting PPD option settings, especially for color, quality, and content optimization. These drivers already ship for many years with most common Linux distributions (Ubuntu, Debian, Fedora, SUSE, ...) and have made many user's printers work and these printers will continue to work in environments where only Printer Applications (and no classic printer driver packages) are supported. In the future more drivers will get added to the Snap of this Printer Application, especially smaller, unmaintained driver projects for which it does not make much sense to clutter the Snap Store with another Printer Application. HPLIP Printer Application in the Snap Store, 616 installations via Snap Store Right after having published the Ghostscript Printer Application I have continued with the HPLIP Printer Application, to cover the printers supported by the printer driver of HPLIP. Creating this one was much more complex than the Ghostscript Printer Application as HPLIP is a suite of printer drivers, PostScript PPD files (with extra CUPS filters), scanner drivers and command-line and GUI utilities. It also has many quirks like excessive use of hard-coded absolute file paths in the source code, utilities written in Python, an x86-32/64-only binary-only code blob in the driver ... while Ghostscript and Foomatic are much more packaging-friendly. As scanning support in PAPPL is not ready yet, scanning on multi-function printers is not yet supported. Also loading the proprietary driver plugin will be added later. Printing is now possible on all non-PostScript and PostScript printers from HP and Apollo which HPLIP supports without its proprietary plugin. More than 3000 different models from ~30 years. For maximum compatibility both PAPPL's standard backends and the \"hp\" backend of HPLIP are available, the former for bi-directional access (poll accessory configuration settings of PostScript Printers), the latter for simultaneous printing and scanning on the same device and perhaps also special needs of some printer models. Note that HP is one of the best manufacturers in terms of supporting driverless IPP printing and scanning, so most newer HP printers work best without this Printer Application, even if HPLIP (and so this Printer Application) supports them. Note also that HPLIP has many bugs which are fixed in the Debian/Ubuntu and RedHat/Fedora packages by a high amount of distribution patches whereas this Printer Application uses the \"raw\" upstream source code. I will soon switch to the packaging GIT repository of Debian, as soon as the new Debian printing maintainer has updated it to version 3.21.8. PostScript Printer Application in the Snap Store, Call for testing on the snapcraft.io forum and on the Ubuntu Discourse, 1484 installations via Snap Store The PostScript Printer Application is now switched over to use the new PAPPL Retro-Fit Library. This means that now we have fully automatic mapping of job IPP attributes to the best-fitting PPD option settings to make printing as easy as possible with standardised user-settable options and from any client device including phones. Also most of the development and debugging happens centrally in the retro-fit library. Note that HP's PostScript PPD files are in both this and the HPLIP Printer Application now. This should make the life easier for users. Some do not know whether their printer is PostScript, but it is from HP, so the HPLIP Printer Application will always work, others have a bunch of PostScript printers of different manufacturers, including HP, they will be able to support them all with a single Printer Application. CUPS Snap in the Snap Store, Call for testing on the snapcraft.io forum and on the Ubuntu Discourse, 2564 installations via Snap Store I am still waiting for the snapd team to implement the security concept on the snapd side, but unfortunately, they are very busy currently. But I have good news now: I have talked with them about when I can expect the merging into snapd and they tell that they will do it in October, so that for the full developemnt cycle of Ubuntu 22.04 LTS (J. J.), starting end of October, it will be available for testing and deciding whether said Ubuntu version will come with the CUPS Snap as standard printing environment, and naturally uploading of applications which print into the Snap Store will get easy and fully automatic, without any manual review and permission needs. Main TODOs are: Complete the security concept on the snapd side, especially implement the content interfaces (see above) Testing Turn classic CUPS drivers into Printer Applications (see progress above) Add a migration script so that OS distributions can easily switch over from classic packages to the CUPS Snap Currently released is 2.3.3op2. Development of CUPS 2.4 is in progress, currently mainly fixing of bugs which were reported to Apple's CUPS GitHub in the last 19 months. Ubuntu Impish Indri (21.10) will also come with CUPS 2.3.3op2, the CUPS Snap and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master. The CUPS in Impish Indri has a distribution patch porting the fully automatic job-IPP-attribute-to-PPD-option-settings mapping from cups-filters, which we use in all retro-fitting Printer Applications to CUPS, so that when sharing a print queue under the new Ubuntu one has the same ease of printing to it from any device, especially phones. A Pull Request for upstream inclusion of this feature is posted and under discussion. There will be news and discussion about CUPS 2.4.x and 3.x with Michael Sweet on the OpenPrinting Micro-Conference on the Linux Plumbers 2021 on Monday (Sep 20). Currently released is 1.28.10. Current development work is finishing up, testing, debugging this year's GSoC student projects, improving and optimizing the rules for mapping job IPP attributes to PPD option settings, and smaller feature needs appearing during the CUPD driver retro-fitting work (but most is already done for this). Now we also need to clean up and sort out things to be able to do a first 2.x release of cups-filters. Improved the auto-mapping of job IPP attributes to PPD option settings (presets). Several new rules added during further driver retro-fitting work, especially also for Foomatic's \"PrintoutMode\" composite option. The GSoC students have completed conversion of the filters into filter functions and making the filter functions also use job and printer IPP attributes as alternative to PPDs and option settings. A Pull Request for a single, universal CUPS filter, calling sequences of filter functions, reducing external function calls, is posted and shortly before merging. Support for the print-rendering-intent IPP attribute in filter functions. Use of log function for the log messages produced by the color-management-related functions of libcupsfilters. In the ieee1284NormalizeMakeAndModel() function extract driver info with regular expression (needed by libpappl-retrofit). In filterExternalCUPS() sanitize the device URI (for CUPS backends) and env variables to assure that passwords do not get into log files. Also several minor bug fixes were done. 1.28.10 Bug fix release, fixes backported from the master (2.x) branch (see below) Ubuntu Impish Indri (21.10) will come with cups-filters 1.28.10. The CUPS Snap currently uses 1.28.10. The PostScript Printer Application Snap uses the current GIT master of cups-filters. Currently released is 1.1b1. We have now support for setting the default printer and pausing/resuming print queues in the web interface (and command line interface, too). Also the Printer Application does not get stuck any more on an unresponsive printer when canceling or deleting jobs or shutting down the Printer Application. The printer's device ID now also gets polled from SNMP-discovered devices, meaning that for those an auto-assignment of the driver is also possible. Many other improvements and fixes. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-September-2022",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - September 2022",
+ "url": "/OpenPrinting-News-September-2022",
+ "headings": [
+ "Saving old printers under Windows is getting easier",
+ "OpenPrinting Micro-Conference on the Linux Plumbers 2022",
+ "Open Source Summit Europe 2022",
+ "Ubuntu Summit 2022",
+ "Google Summer of Code 2022",
+ "Common Print Dialog Backends 2.0",
+ "CUPS Snap and snapd printing interface",
+ "Approaching cups-filters 2.0",
+ "pappl-retrofit",
+ "OpenPrinting web server: Printer Application look-up service is now live",
+ "Snap Store Overview",
+ "CUPS",
+ "cups-filters",
+ "PAPPL"
+ ],
+ "tags": [],
+ "teaserImage": "/assets/images/malt-jet-printer/printer.jpg",
+ "snippet": "Printer Application Snaps under Windows, OpenPrinting MC, OSS, Ubuntu Summit, GSoC, CPDB 2.0, \"cups\" snapd interface, cups-filters 2.0, Printer App look-up, PAPPL 1.2.2",
+ "content": "We are a little late this month, mainly due to my conference trip to Dublin, Ireland, last week, but also to catch the release of systemd/Snap-supporting WSL2. The month is nearly over, tomorrow there is already the new Ubuntu Desktop Team Indaba, this time about snapcraft 7/Ubuntu Core 22. Do not miss it while reading all the exciting stuff here ... So let us start ... I am back from Dublin, Ireland, now, having attended two conferences, the Linux Plumbers conference and the Open Source Summit (OSS) 2022. Conferences have often nice social events in the evenings after each day of talks and hallway sessions. This time the OSS had their main social event in the Storehouse of Guinness, the place where it is shown how this famous beer is made. And there I have seen something very special ... You perhaps have read or heard about how I got to do OpenPrinting. I did a PhD in physics, was system administrator for the department's network, discovered and deployed CUPS back in 2000, got discovered by MandrakeSoft, and finally switched the subject I was working on to Structured Deposition of Ink and Toner Particles on Paper Substrates or, in a more colloquial English: Printing. But only paper? One can print on other materials, too. Let us try: Structured Deposition of Malt Particles on Beer Foam Substrates Yes, you are reading right, you can have pictures on the foam of your beer, even your picture. Back to the Storehouse. Up on the forth floor, after you have seen how this holy black liquid with the nice foam on the top is made, you will get a so-called Stoutie, a Guinness with a picture on its foam. First they (or you) draw the beer, and then, they put it into their malt jet printer: Malt jet printer
The malt jet printer, with touch screen operation! Printing ...
Printing has started ... Print head
... Print head moving ... ... Printing ...
... Printing continues ... ... Printing done!
... and ready! I do not know whether you can print with a Linux machine to this device, so probably it would be a \"Paperweight\" in our database ... Cheers!! You remember my announcement of the HOWTO about running Printer Applications under Windows via WSL to save legacy printers in the August News? You were perhaps thinking about the poor Windows users whose printers stopped working now having to compile a hell lot of libraries from our site to get their old treasure working again. That is not needed any more. The new version of WSL supports systemd and with this also snapd and with this Snaps, including all the Printer Application Snaps. And systemd enables more Linux workflows you are used to in WSL, like auto-starting the daemons (also of the Printer Applications). No compiling, auto-starting daemons, Avahi advertising your printer to the hosting Windows (no manual input of the URI) ... Here is the first announcement from Microsoft and the first Ubuntu blog from Oliver Smith, Product Manager Enterprise Desktop at Canonical. Update: Our HOWTO is now updated. So follow our new version of the HOWTO. And here is quick overview of the changed steps (details in the HOWTO): First, use either the preview version of Ubuntu WSL or follow Oliver's instructions on enabling systemd in your WSL. It is the section \"How to enable systemd in Ubuntu WSL\" near the beginning of the blog. Now make sure you have Avahi installed (package avahi-daemon): and install it if needed With this the Windows print environment will auto-discover the Printer Application running under WSL. If your printer is connected via USB, install USB IPD. Now find the suitable Printer Application in the Snap Store (OpenPrinting, LPrint) or if you are in doubt, use our look-up service. Install it with just a simple: Replace
Presenter: Till Kamppeter
Slides
CUPS 2.5 and 3.0 Development
Presenter: Michael Sweet
Slides, Recording
Mostly as reported here from earlier conferences. CUPS 2.5.x delayed to release in May 2023, 3.x stays in time for release end of 2023. There was no coding yet for 2.5.x and 2.5.x also needs OAUth integration with the desktop. Does not make much sense when one cannot use OAuth, only translations/Weblate interesting then. No worries for switchover into New Architecture by CUPS 3.x or the CUPS Snap: All free drivers are available in Printer Applications, GNOME Control Center and print dialog support available by then, rehearsal by Ubuntu with CUPS Snap. Testing and CI for OpenPrinting projects
Presenters: Till Kamppeter, Michael Sweet
Slides, Recording
CUPS and some other projects do CI via Github Actions triggered on each GIT commit: make test, static analysers, try to build Docker image, ... We want to expand this to all important OpenPrinting projects, in addition regression tests (from Red Hat), filter regression tests on huge amount of print data files from bug report (like Ghostscript), perhaps also private tests for CVEs. Restricting access to IPP printers with OAuth2 framework
Presenter: Piotr Pawliczek
Slides, Recording
Desktop/GUI integration is required, best with OAuth2 support already existing in the desktop toolkits and Linux distributions. Zdenek Dohnal has reached out to the upstream developers of GTK/GNOME about the OAuth2 integration and already available components, especially GNOME Online Accounts (GOA), evolution-data-server (eds), opening browser, user/password input pop-ups, RestOAuth2Proxy from librest 1.0, liboauth, ... We will post here when we find our way through this. Documentation for OpenPrinting projects
Presenter: Michael Sweet, Till Kamppeter
Slides: CUPS, Site, Recording
Documentation for programmers, administrators, and users needed, in CUPS the former is mainly automated by especially formatted comments in the source code and extracting these with an appropriate tool and the rest is written manually. We want to extend this to all important OpenPrinting projects. In addition, we should also consolidate all printing debugging documentation created by the distributions: Debian, Ubuntu, Fedora, SUSE, ... Sandboxing/Containerizing alternatives to Snap for Printer Applications
Presenters: Till Kamppeter, Valentin Viennot
Slides: General, Chiselled containers, Recording, Recording
Only containerization alternative to Snap are OCI-compliant containers: Docker, ROCKs, ... For this session I have invited Valentin Viennot, Product Manager ROCKs & container images at Canonical, as last-minute guest to talk about optimizing containers for security and size by removing (chiselling) unnecessary OS components. Valentin would help us on this for containers of CUPS and of Printer Applications, both in OCI-compliant and Snap format and to distribute via the ROCKs store. We have cancelled the 3D-printing session as we did not have enough to discuss about this subject. Phoronix has written about Mike's part on our micro-conference: CUPS 3.0 Continues Being Crafted To Overhaul Linux Printing Thanks a lot to Monica Ayhens-Madon for taking care of the remote attendees while I was concentrating on the people in the room, to Steven Rostedt and James Bottomley to organize the Linux Plumbers and to help me with everything micro-conference-related, especially also having given last-minute in-person admission to Valentin, and also thanks to Zdenek Dohnal for taking notes of the discussions. Once in Dublin for the Linux Plumbers (see above) I also attended this year's Open Source Summit Europe of the Linux Foundation. This is one of the largest free software conferences, with 15 tracks. I had access to the whole conference and all evening events due to being one of the 8 fellows of the Linux Foundation. I did not give a talk there but met a lot of people, also an old friend from the early 2000s and also Kate Stewart from the Linux Foundation to talk about the Future of OpenPrinting. There were also great social events in the evenings, in the Guinness Storehouse (see also above) and in the Teelings Distillery. And I won a BeagleBone IA64 in the closing plenary of the embedded Linux track! A lot of organization and preparation work is going on! I am also one of the members of the event's organization team. The site has completely changed now. The preliminary announcement page has been replaced by an Indico-based interactive site where you can register for attending and submit your proposal for a talk or a workshop. Please be quick with your ideas for contributions. The call for proposals ends on UPDATE!!! October 7 (we got amazing submissions, and we want more!). And note that Canonical will pay all your costs (travel, accommodation, meals) if your in-person proposal gets accepted. Formats available are interactive workshops, regular talks in two sizes and lightning talks in two sizes. I have already seen first proposals coming in and there are already many interesting talks which would make the Summit be a great conference. But we need many, many more. Especially success stories with Ubuntu, techniques of getting your work done with Ubuntu, and of application development and distribution are highly welcome. Also hands-on workshops, especially about robotics, IoT, Raspberry Pi, embedded, ... are sought-after. We also want to offer a Snap Tutorial Track (\"Your application everywhere, just in a Snap!\"), so that the many application developers in the community learn how to snap their work to easily distribute it, making it available in many distributions: Ubuntu, Debian, SUSE, Red Hat, Windows (see above), ... For this we are looking for workshops about advanced Snap techniques (GTK/GNOME, Qt/KDE, Flutter, Games, ...). Interactive hands-on workshops are preferred. See also the Ubuntu blog from Heather Ellsworth (also in the organization team) about the call for proposals, with detailed instructions for a hopefully successful proposal. And here is the initial announcement blog from Philipp Kewisch, Community Manager at Canonical and one of the chairs of the event. And if you are eager to get the latest news quickly instead of waiting for my October News Post, subscribe to the official Ubuntu Summit newsletter. Any questions? Please ask summit@ubuntu.com. Get in touch with the people behind Ubuntu in Prague!! Now the third month of the coding period of the Google Summer of Code 2022 has passed and our contributors are continuing their great work! And the coding is not over yet, as we are applying a new feature of the GSoC. We have extended the coding period for all our 7 students, primarily to compensate for them having exams of their schools during the original coding period, or classes already having restarted. For that we extended by 4 weeks. In our GNOME Control Center sub-team (Mohit and Shivam) we have extended for even 6 weeks, to give the GNOME design team the time to get the changes on the GUI right. And here are the third editions of their little summaries (again in our group chat on Telegram) of what they have done: Converting Braille embosser support into a printer application
Contributor: Chandresh Soni
Mentors: Till Kamppeter, Samuel Thibault
Hello everyone, in the last few weeks I have created a separate driver for embossers and integrated them with the main application. I have also completed automake for the printer application, with only minor changes remaining. I plan to begin testing the application this week and fine-tune it based on the results of the testing. Scanning Support in PAPPL
Contributor: Deepak Khatri
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
Hi everyone, in last few days I have been going through my work to integrate it into pappl. In last few weeks I improved scanner objects and try to implement the API papplSystemSetScannerDrivers. I am also trying to understand the similarities of code to be used in Driver Interface. Adding Common Print Dialog Backends (CPDB) support to existing Print Dialogs
Contributor: Gaurav Guleria
Mentors: Till Kamppeter
I have started work on the CPDB support for Qt Print Dialog. I have created a basic CPDB print plugin for Qt here: https://github.com/TinyTrebuchet/qtbase/tree/cpdb with help from Albert Astals Cid (tsdgeos). I have also got in touch with the Qt development team to decide how exactly should CPDB support be added into the QPrintDialog. Further, I have done some bug fixes, improvement and added new features to cpdb-libs. cpdb-libs now has support for obtaining and setting user and system wide default printers: https://github.com/OpenPrinting/cpdb-libs/pull/10 and also supports multiple unique media margins for each media size: https://github.com/OpenPrinting/cpdb-libs/pull/8 Discussion with the Qt upstream developers on their mailing list: Initial post, thread \"Adding CPD support to Qt print dialog\" GNOME Control Center GUI for discovering non-driverless printers and finding suitable Printer Applications for them
Contributor: Mohit Verma
Mentors: Till Kamppeter, Michael Sweet, Pranshu Kharkwal, Divyasheel, Deepak Patankar
I have completed the work of discovery of Printer Applications along with their binary paths. I have also weeded out the duplicate entries listed by Avahi. With the Printer Application look-up service in place, I have started the work on a temporary GUI for the Printer Application which can be adjusted to the final design once it is finalized by Marek Kasik. This GUI will be completed by the end of this week. So, by the end of this month we will have a makeshift GUI which can search for the most appropriate Printer Application on the Open Printing and install it as well along with other desired functionalities. Further discussion happened on Mohit´s issue report: GNOME Issue report #1878: Allow to add new printers via Printer Applications cups-pk-helper changes: cups-pk-helper PR #7: Added discovery of Printers via lpinfo, PAPPL and Printer Applications Scanning Support in PAPPL with eSCL Support
Contributor: Rishabh Maheshwari
Mentors: Till Kamppeter, Michael Sweet, Dheeraj Yadav, Deepak Patankar
I have completed all the necessary functions required for the parsing of client scanner requests and store the device capabilities in a data structure. I have also completed developing the helper functions required for this functioning. Currently, I am waiting for Deepak to finish his work towards developing some simple test facility which emulates the behavior of a scanner using static images which will be used by me for testing my code. Add Avahi calls for discovering and resolving driverless IPP printers and Optimize the processes
Contributor: Sachin Thakan
Mentors: Till Kamppeter, Michael Sweet, Deepak Patankar
Hi all, I have been working on integrating my earliar work into cups-filter. In last few weeks, I refactored and improved my avahi implementation and tried building cups-filter on my system(having encountered some issues with my already build version of cups-filter) to get started with 2nd phase of the project. I am hoping to make fast progress in coming weeks. Thanks Create new printer setup tool for the GNOME Control Center
Contributor: Shivam Mishra
Mentors: Till Kamppeter, Pranshu Kharkwal, Divyasheel, Deepak Patankar
Hi everyone, I have completed integration of GUI functionality of configuring IPP system service with IPP printing services listing in the main panel along with CUPS queues. As of now I'm working on fine-tuning & other possible updates, and also looking for integration of discovery of Printer applications in the module. Feature requests so far: #1877: Improve setting of IPP options #1879: Do not show setting of drivers for IPP printers #1911: Printers: Make adminurl available for IPP printers While our GSoC contributor Gaurav Guleria is working on adding CPDB support to the print dialogs (see above) he has continued to do fixes and improvements on the CPDB framework itself: Support for each media having multiple sets of margins Support for overall default printers Distinguishing print and fax queues amd providing needed extra options Also this will get included in the 2.0 release of the Common Print Dialog Backends. For the release itself I will still wait a little bit, as Gaurav could find other needs of functionality during his work on the Qt dialog. CUPS Snap in the Snap Store Now with the cups snapd interface in place Snap package maintainers are starting to use it. Unfortunately, we have hit a bug in snapd with the new cups interface. The automatic dependency installation of the CUPS Snap via the pseudo content interface with default-provider: cups interferes badly if the Snap using the cups interface for printing is seeded (being in the list of default packages used in the OS distribution), even if the CUPS Snap is also seeded (bug report on snapd). I hope the bug gets solved soon by the snapd team at Canonical. Otherwise we will simply skip right to the real integration of the CUPS Snap dependency in the cups interface without any ugly workarounds. For this I have already planned to meet the snapd team in-person for working on an appropriate solution on Canonical's internal Engineering Sprint in Prague, in the week before the Ubuntu Summit. The implementation will then be scheduled to be finished for Ubunru 23.04, the first Ubuntu using the CUPS Snap as standard print environment and the New Architecture. Application developers in the community uploading their work to the Snap Store can still freely use the cups interface without any problems. Only the few Snaps which are in the default installation/the ISO of Ubuntu are affected (and have to stay with cups-control for the time being), and those are usually maintained by Canonical employees anyway. We get really close now. I am in the middle of cleaning up all the code to get a unique coding style and to make it more readable. For the coding style I follow the DEVELOPING.md file of the CUPS source code, to extend this to all OpenPrinting projects. To improve the readability of the code, I also add missing spaces in comma-separated lists (xxx,yyy,zzz -> xxx, yyy, zzz) and around operators (x=a*(b+c)%4 -> x = a * (b + c) % 4), what got nearly completely missed out by several contributors. Comments are re-formatted to use // ... instead of /* ... */, like in PAPPL, so C and C++ files get the same comment style. I did this already on the code for the cfFilterPDFToPDF() filter function and on a bunch of other files of libcupsfilters. In addition, I did final testing, bug fixing and polishing: Made the new cups-filters correctly working with the PPD files for driverless printers generated by CUPS (temporary CUPS queues and creating queues with lpadmin ... -m everywhere ...) and also with PPD files of older cups-filters 1.x versions (commit). Added NULL checks when filter functions of libppd (especially also ppdFilterExternalCUPS) are called without PPD file, to avoid crashes. This especially prevented all maintenance tasks (poll default option settings and installable accessory configuration from PostScript printers, identify printer, …) in the retro-fitting Printer Applications from working (commit , commit). Replaced all assert() calls in the 3 libraries (libfontembed, libcupsfilters, libppd) by macros to only be actual assert() calls when the DEBUG macro is set, to avoid automatic bug reports (apport) in production use (coomit). Correctly check final output type to determine which filter does the page logging (commit). Page logging for PostScript output (commit). Compare MIME type strings case-insensitively in the cfFilterUniversal() filter function (commit). When generating a printer IPP attributes record from the PPD file, make sure that all attributes concerning custom page size are included (commit). Import template directory name when calling cfFilterBannerToPDF() via cfFilterUniversal() (commit). Let ppdFilterPDFToPS() correctly determine the print resolution (commit). Improvements on getting printer IPP attributes from the PPD, on attributes printer-resolution, device-uri, document-format-supported, print-content-optimize-supported, media-col-ready, media-ready, removed irrelevant code about supply levels (commit) Fixed selection of PDF renderer in the build system (commit) Added support for Poppler's pdftops to the cfFilterUniversal() filter function/universal CUPS filter (commit) In cfFilterPDFToRaster() fixed margins of output pages (commit) cfFilterRasterToPDF() only accepts PWG Raster, not CUPS Raster, so renamed it to cfFilterPWGToPDF() (commit) and only feed PWG Raster into it (commit). Finally removed the not-used-by-anyone PHP and Perl APIs (commit) Also removed legacy image format support (commit). Merged pull request to add configuration directive to cups-browsed to not check the network interfaces too frequently, to improve its performance. Thanks a lot to Zdenek Dohnal from Red Hat for the contribution. I have also adapted the printer driver retro-fit library and where needed thet Printer Application to the last and final changes of the cups-filters 2.x API, and while doing this, also fixed a crasher in pappl-retrofit (commit, commit). Naturally I have also tested everything and found that after printing a job or doing an administrative task (Identify printer, poll accessory configuration) the Printer Applications start to consume 100% CPU permanently. After reporting a bug on PAPPL earlier, Michael Sweet actually found a 100%-COU problem in the job history clean-up code and fixed it, but the 100%-CPU problem persisted for me. I Investigated further and found that it only happens on printers with CUPS backends. So I worked around it by temporarily de-activating the not yet completed supply read-out support (commit). But doing more tests the 100%-CPU monster was rearing its heads again, but before I could investigate, I had to reboot on a browser memory clog-up crash and after that the 100% CPU was gone, probably a bad effect of the system having run out of memory ... Now it seems to be all working as intended. We have finally deployed the Printer Application look-up service for printer setup tools on the OpenPrinting web server for printer/driver look-ups! I did some tests and everything works as expected. Printer Application Snaps installed on the server find the correct drivers for the given printer device ID and the user (or better the printer setup tool) gets as answer a hierarchy list of what are the best Printer Applications which support their printer and with which internal driver. I passed this on to our GSoC contributors working on the GNOME Control Center, so that they make use of it. If you want to try it out, try URLs like: https://openprinting.org/query.php?papps=true&device-id=MFG:HP;MDL:LaserJet%204050 https://openprinting.org/query.php?papps=true&device-id=MFG:Epson;MDL:Stylus%Photo%20R800 This is actually a machine communication interface for printer setup tools, an interface for humans will come later. Thanks a lot to Violet Kurtz from the OSUOSL for implementing this! From OpenPrinting we have already 6 Snaps in the Snap Store: |Name|Description|Downloads| |:---|:---|---:| |cups|CUPS|82922| |ipp-usb|ipp-usb|2715| |ps-printer-app|PostScript Printer Application|2558| |ghostscript-printer-app|Ghostscript Printer Application|1787| |hplip-printer-app|HPLIP Printer Application|5742| |gutenprint-printer-app|Gutenprint Printer Application|4661| Currently released is 2.4.2. There will be further bug fix releases in the 2.4.x series. Some bug fixes were done during the last month, see changes below. Ubuntu Kinetic Kudu (22.10 will most probably come with 2.4.3. The CUPS Snap (in the Edge channel) and our CUPS-driver-retro-fitting Printer Application Snaps use the current GIT master of CUPS. The CUPS Snap in the stable channel is version 2.4.2. Currently released is 1.28.16. The restructuring of the code to separate the siamesian twins of the filter functions and PPD file support is completed and we also have done a lot of testing and bug fixing. Now we are finally polishing the coding style and updating the license/copyright headers for the 2.0.0 release. See above for more details. As cups-filters 2.0.0 will not make it into Ubuntu 22.10 we continue with further bug fix backport releases in the 1.x series. 1.28.16 Bug fix release, to make images be printed in their original size with \"print-scaling=none\" and to not use deprecated data types for reading TIFF images. Ubuntu Kinetic Kudu (22.10 will coming with cups-filters 1.28.16 or a later 1.28.x release. The CUPS Snap is currently locked to the /e496badbf2 commit (from May 20) of cups-filter's GIT master (2.x) until the restructuring gets more tested. The Printer Application Snaps use the current GIT master of cups-filters and so are the first application for real-life testing. Currently released is 1.2.2. In the last months the development of the 1.3.x series has already started. See changes below. 1.2.2 General bug fix release. See changes below. All the CUPS-driver-retro-fitting Printer Applications in the Snap Store (see above) 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."
+ },
+ {
+ "id": "post:OpenPrinting-News-September-2023",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - September 2023",
+ "url": "/OpenPrinting-News-September-2023",
+ "headings": [
+ "Opportunitiy Open Source in the IIT Mandi, India",
+ "DebConf 2023 in Kochi, India",
+ "Ubuntu Summit 2023 in Riga",
+ "Google Summer of Code 2023",
+ "cups-filters Second Generation - Final 2.0.0 Release!",
+ "PAPPL 1.4.0",
+ "Snapping for OpenPrinting, especially the CPDB CUPS backend",
+ "Printer setup tool for KDE",
+ "CUPS 3.x"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/P22DOu_ahBo/hqdefault.jpg",
+ "snippet": "40 years of GNU, Opportunity Open Source in IIT Mandi, India, DebConf 2023 in Kochi, India, R. I. P. Abraham Raji, Ubuntu Summit 2023 in Riga, GSoC 2023, cups-filters 2.0.0, PAPPL 1.4.0, CUPS 3.x",
+ "content": "We are all talking about Open Source or, more correctly, Free Software, and others are just talking about Linux, which is only a small part of it, but many do not know when and how it all began. A few days ago, on September 27, we had the 40th anniversary of Richard M. Stallman (RMS) announcing the plan to develop the GNU operating system, a free (as in freedom) Unix-like operating system. And what made Richard coming to this idea is the same as what made me promoting CUPS and running OpenPrinting, a problem with a printer. Richard´s problem was that back in 1980 at the MIT Artificial Intelligence Laboratory, where he was working, they got a shiny new Xerox 9700 and Xerox denied him access to the source code of the printer's software, for him to make the users get informed about finished jobs, paper jams, ... (note that CUPS came well later) Exactly this he did with the software of the previous printer. See the whole story in \"Free as in Freedom\", by Sam Williams, chapter 1. My problem was that back in 1998 in the Theoretical Physics department of the University of Bayreuth in Germany, where I did my PhD, they got a shiny new Tektronix Phaser color laser printer and it only came with proprietary software for commercial Unixes and not for Linux. Only by deploying CUPS with its perfect PostScript printer support I solved the problem. But my problem had never showed when there had not been Richard's ... To celebrate the 40th anniversary of the foundation of the free software movement, there was a little one-day conference in Biel/Bienne in Switzerland, with several talks. Richard Stallman was also there, giving a keynote (FOSS Force article). In the keynote RMS revealed that he has cancer, and one sees also in the video that he has lost all his hair and beard due to the chemo (see also the article on The Register). But he says that his prognosis is good. We all wish RMS all the best to recover soon and continue his great initiative for many more years. And, talking about history of free software, on the DebConf in Kochi, India, I met Raghavendra Bhat, who told me his experience with XPP (X Printing Panel), the little print dialog I wrote back in 2000, which initiated my printing career. He did a lttle write-up for me to post here: XPP was doing a good job for me as I had setup some Xerox or HP Laser Jet printers. I had setup FVWM on Slackware GNU or so, then I chanced upon this small nifty printer setup uty XPP. I deployed it as it had no other library dependencies, it had a dependency on libfltk or was it libx11. I setup the HP Laserjet printer beautifully, an unused PC AT computer with Slackware GNU/Linux acted as the print server now with this X11 tool called XPP. I looked up as to who the developer of this panel was, a weird sounding Norwegian or such name with Kampeter in the end. I thought it was some computer programmer who made a pun of his name to mask identity as to the creator of XPP, Kampeter for Komputer!! About a couple of months back, a research scientist told me that the Slackware machine near a Laser Printer was still not junked. Much to my suprise, the Laser printer was still churning out pages with this XPP dialog-like printer panel interfacing with this antique AT machine. Hahaha..... Yes, Till Kampeter, you really are ancient, more still so serving a real good job with the XPP printer panel. I had deployed this with Slackware in an oceanography lab here in Kochi, maybe was it Bo Peep or was it Hamm or it could have still have been Slackware GNU. Debian GNU was not known, even if it were who would want to do a tedious install with the BOOT and ROOT floppies!! So XPP is still in good memories ... My colleague at Canonical I mentioned most in my OpenPrinting News was Heather Ellsworth, especially known as the host of the Ubuntu Desktop Team Indabas. Unfortunately, she has left Canonical. But no worries, she is at Thunderbird now, in Jason Evangelho's marketing and communications team. So she is continuing in free software, continuing doing community work, continuing to attend and organize conferences (and so continuing to meet me), ~~continuing to do Indabas~~ ... ... not Indabas, but she did a great podcast, episode #5 of the Thundercast series. She tells about how she got into free software and gives some tips for remote working (note that Thunderbird is also totally work-from-home, as Canonical). Also Monica Ayhens-Madon, especially known as host of the Ubuntu Community Office Hours back in 2021, who left Canonical already last year, is now at Thunderbird, at least part-time. And by the way, I have shown here already, exactly a year ago, a printer which prints on beer foam, in the Guinness Storehouse in Dublin, Ireland, and I have seen it again in Vienna, where I live. It's a Ripple Maker, controlled by its touch screen and a web app, most probably not a driverless IPP printer. Special tip: You are on NixOS? Printing is not enabled by default there. Please follow these instructions (Thanks, Linux Matters team for the hint in episode #13). So let us now start with what we did at OpenPrinting in September ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. My talk about the conference on the DebConf 2023: \"Opportunity Open Source conference in the IIT Mandi, India: Motivating people to be a part of us!\" (video, slides, all files/photos) My lightning talk about the conference on the Canonical Engineering Sprint: Opportunity Open Source conference in the IIT Mandi, India: Motivating people to be a part of us! Report by Dimple Kariakose on Ubuntu Discourse Mastodon: #OpportunityOpenSource My first trip to India, especially the Opportunity Open Source in the Indian Institute of Technology Mandi in Northern India was a success. The long trip, a 10-hour road trip from Delhi Airport and after the event ~6 hours driving to Chandigarh Airport, were really worth it, as we encountered ~100 excited students of the IIT Mandi attending the event. We were also lucky with the weather, sunny and no rain during the road trips and the event itself. Especially our GSoC contributors were eager to meet me, as I arrived at 2am and several stayed up to receive me at the guest house, amd they helped me to get my suitcases (with all the swag) into my bedroom. Akarshan Kapoor (GSoC contributor on scanning with PAPPL) did great on-location organization work, getting for us the 2 conference rooms, accommodation in the guest house, volunteers for A/V and also excellent food ... Thanks a lot to him. Everything worked great, streaming, recording, remote speaking, only problem was the connection of the laptop running the streaming with the room's audio system. We could not test this beforehand as the rooms were permanently busy witih classes. We ended up running an hour late and to make remote speakers audible holding a mic against a Bluetooth speaker connected to the laptop. Especially we did not have the time for running the GSoC panel any more. Also due to the live stream in room 1 on Friday having broken down we needed to create a new one for the OpenPrinting track and so were not able to start the sessions in time. At least we could have Michael Sweet's talk in full. The actual schedules, also with some last-minute changes of the day before, worked out in several phone calls with the Zephyr people during the road trip to Mandi, are here. Especially we have added the talk \"Getting a Start in Open Source\" by Shuah Khan from the Linux Foundation on Friday into the Zephyr track and we have replaced the Zephyr training on Saturday by the talk \"Why BeST uses OpenSource and Zephyr RTOS\" by Oliver Völckers from BeST Berliner Sensortechnik GmbH in Germany. We also moved the screening of Kate Stewart's pre-recorded talk from Friday to Saturday. But the attendees had no problem with all that and were patient with us. They liked the event a lot. Special thanks to Canonical's Community Team, Philipp Kewisch, Mauro Gaspari, and Aaron Prisk, for all the support, the swag, and especially for hosting my event site on Canonical's Indico and for letting me accept remote speakers, live-stream, and record using Canonical's StreamYard and Ubuntu OnAir. And thanks a lot to all the speakers, volunteers in the rooms, and the exceptional audience! And we have asked for those who want to participate in an Indian Ubuntu Local Community (LoCo) to sign up via a QR code and ~30 actually signed up! In total, including DebConf we got even 47 sign-ups. Thanks a lot already now to everyone having signed up. Here are all the sessions with links to slides and recordings: General open source/free software What is Open Source? by Aveek Basu (video, slides) - Aveek started the event with an introduction for newcomers to open source and free software. Getting a Start in Open Source by Shuah Khan (video, slides) - Shuah from the Linux Foundation shows where one can contribute and mentorship opportunities at the Linux Foundation. ScaniVerse: A New Horizon in Unified Scanning for Linux Systems by Akarshan Kapoor (video, slides) - GSoC contributor Akarshan Kapoor presents his GSoC project of adding scanning support to PAPPL to supply scanner drivers via sandboxable Scanner Applications and also his project of MetaScan a scan client which organizes the scanned images. The same talk he will also give on the Ubuntu Summit 2023. He does amazing work for free software. Apply and work at Canonical, panel by Till Kamppeter and the Canonical Gang (video) - Right in the time of the year of placement, when companies come to Indian universities to offer first jobs for those who complete their courses, I have hosted a panel with three Indian Canonical employees and we told about how we got to Canonical, how the selection process works, how it is to work from home for Canonical, everyone meeting twice a year for a week at Engineering Sprints and the fun of it, attending conferences, ... OpenPrinting OpenPrinting - We make printing just work! by Till Kamppeter (video, slides) - Here I have told how I got into free software and how I started OpenPrinting and what we are doing at OpenPrinting. CUPS 2.5 and 3.0 Development by Michael Sweet (video, slides) - Michael Sweet, author of CUPS, told about the next steps and future plans in CUPS development. CUPS 2.5.x adding features like OAuth2 support, wide-area DNS-SD look-up, multi-language support, ... CUPS 3.x completely restructuring (New Architecture), especially all-IPP without PPDs but also a more comprehensive library API, local server and sharing server, D-Bus printing, ... a lot of coding is needed, for CUPS itself, desktop integration, new PDF library, ... Contributors urgently needed. Demo of GNOME Control Center \"Printers\" module, by Mohit Verma (video) - Mohit showed his work on the \"Printers\" module of the GNOME Control Center, to prepare it for the New Architecture, supporting IPP print destinations and Printer Applications. Call for participation by Till Kamppeter (video) - And as we have seen here we have a lot of work and need people who want to contribute, so I made a call for contributions as a conclusion for the OpenPrinting track. Zephyr What is Zephyr? by Benjamin Cabé and Jonas Remmert (video) - Introduction into this free-software real-time operating system for IoT systems too small for running Linux. Zephyr Project: Supporting Sustainability by Kate Stewart (video, slides) - This talk, pre-recorded by Kate Stewart, VP Dependable Embedded Systemsof the Linux Foundation, shows where Zephyr gets actually used. Zephyr in Action: Real-World Product Development, interactive workshop by Jonas Remmert (video, slides, examples/exercises) - Jonas, speaking remotely, showed how to set up a Zephyr environment and run several examples in it. Attendees could try out everything on their own laptops and got on-the-spot help by Akarshan Kapoor. A successful workshop with remote speaker. Why BeST uses Open Source and Zephyr RTOS by Oliver Völckers (video, slides) - Success story of using Zephyr for monitoring wastewater removal from trains. Immutable distributions and sandboxed packaging Desktop Linux, as easy as a smartphone! Just in a Snap! by Till Kamppeter (video, slides) - Grown from the smartphone operating system Ubuntu Touch we got the universal sandboxed packaging format Snap, initially for Ubuntu Core, an immutable Linux operating system for IoT. Snap got established as packaging format for standard Desktop and Server Linux systems and Ubuntu Core got extended to Ubuntu Core Desktop, an all-Snap immutable desktop operating system. This talk explained how all this actually works. A sneak peak into the realm of immutable Linux distributions by Rudra Saraswat (video, slides) - Rudra, 14-years-old project lead of Ubuntu Unity, Unity 7, and blendOS, explains the principles of an immutable operating system and atomic updates how they work in blendOS. Your app everywhere, just in a Snap!, interactive workshop by Till Kamppeter (slides, virtual machine) -12 brave souls, not only my 3 colleagues from Canonical, stepped up to learn how to snap (package in Snap format) desktop applications in my workshop. I could not run the complete workshop, as we had only 1 hour, but give a good insight into the subject matter. One of the participants, Biswadeep Purkayastha, also one of our GSoC contributor candidates for 2023, started volunteering to snap for OpenPrinting. See more below. And sorry, this workshop was too interactive for recording ... Documentation The Fundamentals of Effective Technical Writing by Hrittik Roy (video, slides) - An introduction into technical writing, document types, organization of the document, examples, ... The slides are actually for a workshop, so while or after watching the video you can actually do the exercises. Can Documentation be fun? by Dimple Kariakose (video, slides) - Another approach to introduce the audience into the aspects of documentation, and as Dimple is in Daniele Procida's documentation team at Canonical, she follows Daniele's Diátaxis model. Recordings of the conference days Friday, Sep 8: Plenary OpenPrinting Track Zephyr Track Saturday, Sep 9: Plenary Nice comment by @manojkapoor9855 on the YouTube video of Saturday: A very informative talk show entitle as 'Opportunity Open Source' was organized By Akarshan Kapoor and his team mates of Kamand Prompt under the Guidance of Technical Secretaries Reetam Sir and Anurag Sir at IIT Mandi. Heartfelt Thanks to Mr. Till Kamppeter and Mr. Aveek Basu whom have arrived from Austria for such an informative session for 2 days Summit. Today on 9th September 2023 it was almost 9 Hours 15 minutes online tireless streaming on You Tube Channel. Thanks to all team members of Data Science & Engineering and Computer Science Students for taking such good initiatives for making Open Source Canonical, Ubuntu and Linux more visible and vibrant to all who seems to be interested. And thanks to Ban Jo (@Enry211) for adding a comment with links to the beginnings of all sessions to each video. From Mandi in northern India I directly went to Kochi in southern India, to the DebConf. Departing on Sunday morning (Sep 10) I arrived after 6 hours on the road (to Chandigarh Airport) and 4 hours of flight on Monday, Sep 11, 4am in the morning. And on Tuesday, Sep 12, right in the very first time slot my talk about Mandi was scheduled! So after taking some sleep up to lunch I had only the Monday afternoon to prepare the talk, and I also needed to do a semi-annual report for Canonical that afternoon ... So I was not able to attend any of the talks on Monday ... My 2 talks have actually taken place as planned and were a success, at least what the circumstances allowed, as unfortunately, the 3 conference rooms were far from each other, making it difficult to switch between them to get to the desired sessions. Especially the plenary room, in which my 2 talks have taken place, was outside the hotel and required a 5-min walk to get there, ending up with a near empty room most of the time. Here are the 2 talks and the slides and recordings of them: Opportunity Open Source conference in the IIT Mandi, India: Motivating people to be a part of us! video, slides, all files/photos This talk is about how we have organized the conference, the challenges, and naturally also the outcome and experiences with running it, having come right from there to the DebConf. Lots of photos! The New Architecture for Printing and Scanning on Debian video, slides, all files With the DebConf taking place right in the new cycle after the Bookworm release I tell the Debian developer community about the New Architecture of printing and scanning to help them switch the Debian distribution to the new IPP-only PPD-less realm. The event's full schedules have all recordings embedded in the talk descriptions now. Here are all videos and all slides, photos, and other materials. On Wednesday, Sep 13, right in the middle of the conference, there was a tourist day. Attendees could select 1 of 5 day trips in and around Kochi. One of the trips was a day at the beach with an option for kayaking. Unfortunately, there were less kayaks than they got reserved and one of the 2 persons who stayed without, Abraham Raji, entered the kayaking waters and got drowned by the streams. On the Debian web site: Abraham was a popular and respected Debian Developer as well a prominent free software champion in his home state of Kerala, India. He was a talented graphic designer and led design and branding work for DebConf23 and several other local events in recent years. Abraham gave his time selflessly when mentoring new contributors to the Debian project, and he was instrumental in creating and maintaining the Debian India website. R. I. P. Abraham Due to this, all sessions and the conference dinner on Thursday, Sep 14, got suspended, some got withdrawn by the speakers, others moved out to the following days using extra rooms. On Friday, Sep 15, in the morning was the funeral and so there the sessions got also suspended and buses provided for those who wanted to visit Abraham's familiy ~2 driving hours away from Kochi. As Rudra Saraswat attended the Opportunity Open Source in Mandi only remotely, because he was afraid of traveling to there due to heavy rain and landslides during the weeks before, I have suggested him to attend the DebConf to meet him there. I also helped him to get accepted by the DebConf's organizers with his last-minute registration. So I met him there only on Tuesday and Wednesday, as on Thursday he had to leave early in the morning already to not miss his visa appointment for the Ubuntu Summit 2023 in Riga. I wanted to do with him a spontaneous panel session about immutable operating systens, especially blendOS and Ubuntu Core Desktop, and live-stream it on Ubuntu OnAir, Wednesday night, as there was no other time slot left. So I told people at dinner that I wanted to do the session, so that they attend it, to get some live audience, and I prepared the conference room, especially set up a laptop with my camera and my microphones for the Ubuntu OnAir streaming, same configuration as in Mandi, as the video team of DebConf was not present for such a spontaneous session. Once completely done with the setup and ready for starting the stream, a person from the DebConf organizers entered the room, delivering the news about Abraham and we did not start our session ... Photos of the DebConf The schedules for the Ubuntu Summit have been published, and the two and a half days are packed with amazing sessions! And for displaying them more nicely, Philipp Kewisch, Canonical's Community Team manager has hacked Indico again, adding a horizontal view for the schedules, similar how you see the Electronic Program Guide (EPG) on a modern TV, with a line for each channel (room) and the time at the horizontal axis. If you have problems navigating, you can resort to the \"classic\" vertical view via the menu button in the upper left corner. My workshop \"Improving snap maintenance: automating tag updates\" will take place on Saturday, November 4, at 12:00 - 13:00 EET. As Heather Ellsworth has left Canonical, she will not be on the Ubuntu Summit. My co-speaker in the workshop will be Jesús Soto now. He is from the gaming squad in Canonical's Desktop Team and he already replaced Heather in my Snap workshop on the GUADEC 2023. The session description is already updated appropriately now. This month not much has happened in the GSoC. In Indian universities there have been the mid-semester exams and the placements have started. The placements are the way how students in their last year find their first employment after completing their courses. Indian companies who are hiring come to the universities, offer their jobs, and run tests and interviews. And in the IIT Mandi there was also the Opportunity Open Source. On October 13-15 there will be the GSoC Mentor Summit 2023. After 3 online editions due to the pandemic it is finally in-person again, taking place on the Google Campus in Sunnyvale, CA, where it already happened in 2018. It is somewhat smaller than the last editions before the pandemic, with only one instead of two guaranteed slots for representatives of each mentoring organization. I will attend, and also Deepak Patankar, mentor and former GSoC contributor for OpenPrinting. He was lucky getting his slot by the waitlist, through which slots not taken up are getting redistributed. As in the years before, the Mentor Summit will be a so-called un-conference, consisting of BoFs, spontaneously planned during the event. There will also be lightning talk sessions where each organisation could tell about exceptional contributors or other interesting things which happend related to the organization's GSoC participation. I plan to give a lightning talk about the Opportunity Open Source in Mandi. Now, in the last 3 months, we got only few bug reports, and a security vulnerability in CUPS, in code which got overtaken into libppd, and therefore the vulnerability is also there. To get the security fix into a release and 3 months being a long time after RC2 I am finally releasing 2.0.0 right now. Ubuntu 23.10 will ship with this release. libppd Postscript Parsing Heap Overflow (CVE-2023-4504) From the bug report: The ppd_scan_ps() function in the libppd code base provides functionality that scans through a string looking for the next Postscript object. When iterating through a string which contains an open parenthesis and ends with a single backslash (0x5c) character, the code incorrectly iterates forward a character without properly checking the bounds of the string resulting in a 1 byte read beyond the allocated heap buffer. This is fixed by adding the missing NULL check when, after a backslash was read, the character escaped by the backslash is read. Miscellaneous fixes A few other bugs got reported and fixed since RC2. These fixes are also included. See the lists in the original announcement. Michael Sweet has released PAPPL v1.4.0 which is a new feature release. Especially it adds the new create-printers operation, as API function and IPP request, to let the Printer Application automatically add queeus for any local printers which are supported by it. This function will also be called automatically the first time the Printer Application is run after its installation, so that just installing a Printer Application is usually all what needs to be done to set up a non-driverless printer. This also makes it easier to write Printer-Application-supporting printer setup tools, as (at least for PAPPL-based Printer Applications) one can add a button to auto-setup all supported ones under the auto-discovered printers. Here is a list of further feature additions: Added support for \"job-retain-until\" (Issue #14) Added new PAPPL-Create-Printers operation, and the PAPPL mainloop API now auto-adds local printers the first time a server is run (Issue #245) Added new papplDeviceRemoveScheme and papplDeviceRemoveTypes APIs to disable unwanted device types (Issue #259) Added support for suspending and resuming jobs at copy boundaries (Issue #266) Added support for server configuration files (Issue #279) Now preserve the paused state of printers (Issue #286) Updated the options sub-command to list vendor options and values (Issue #255) Updated web interface to show the age of jobs (Issue #256) Updated \"devices\" sub-command to have the PAPPL server find the devices instead of doing it directly (Issue #262) Updated default logging to be less chatty (Issue #270) Updated the Wi-Fi configuration page to support hidden networks. Updated the Wi-Fi configuration page reload time to 30 seconds. Updated TLS certificate generation to support more types of certificates and to use modern OpenSSL/GNU TLS APIs. The Snap workshop (slides) which I have given on the Opportunity Open Source in Mandi was a special success, as under the ~12 participants, one of them, Biswadeep Purkayastha, stepped up to voluntarily snap for OpenPrinting. He also was one of our GSoC contributor candidates for 2023, but did not get selected due to lack of contributor slots assigned to us by Google. He has already studied the rest of the workshop slides which we could not do at the conference due to the limited time, and also my \"Daemon Snapper's Workshop\" (slides) from the Ubuntu Summit 2022. And he familiarized himself with the new user daemon feature of snapd, in preparation to snap CPDB backends. Now he will work on creating a Snap for the CPDB backend for CUPS. On DebConf, when I have given my talk about the New Architecture for printing (video, slides), Michael from Nigeria came up to me and showed interest in updating the printer setup tool in the KDE Settings application for the new PPD-less all-iPP printing approach. I am in contact with him via Telegram and he is already studying the code base. Michael Sweet has presented his updated plans for CUPS 2.5.x and CUPS 3.x in his talk on the Opportunity Open Source (video, slides). It is not only about the all-IPP printing approach with support for classic CUPS drivers and PPD files going away so that we are required to support Printer Applications, but also there are interesting new features coming which should also get integrated into the desktop. Note that the support for Printer Applications by the desktop is absolutely required for CUPS 3.x, support for the other features is highly recommended, to get access to the full functionality of CUPS. Here are the new features and their desktop needs: Already planned for CUPS 2.5.x: Wide-area discovery of network print destinations via DNS-based DNS-SD Print destination access outside the scope of DNS-SD discovery, by specifying the IPP destination(s) in a configuration profile - Profile setup UI in setup tool OAuth2/OpenID authentication - Authorization UI in print dialog, token registration in setup tool? Localization: Use Weblate to gather translations, generate multi-language PPD files, provide *.strings files for shared printers - No desktop integration needed, client just tells their UI language to server, CPDB CUPS backend should already do that. Planned for CUPS 3.x Separation of local and sharing server - In setup tool show only functionality for CUPS daemon type in use Printing via D-Bus with local server - Access to CUPS also via D-Bus, should get implemented in libcups3, CPDB should use correct libups APIs Michael Sweet also writes (on his last slide): CUPS 3 - Challenges Much broader scope and integration than the original CUPS work Desktop support - need to uplift GNOME/KDE/XFCE desktops to new D-Bus API for printing, authorization, consent UI Need developers to work on the local and sharing servers, desktop UI/services Can probably use/adapt PAPPL code for the core server bits Much of the print dialog work can be repurposed Probably have existing authorization/notification UI we can use Graphics libraries - current PDF tools/libraries have problematic licenses or other limitations For all this we need contributors, not only for desktop integration but also for coding on CUPS itself. We should also post GSoC project ideas for coding on CUPS 3.x. Planned (estimated) release dates: CUPS 2.5.x (release manager: Till Kamppeter) CUPS 2.5b1 - November/December 2023 CUPS 2.5rc1 - January/February 2024 CUPS 2.5.0 - February/March 2024 Estimated Ubuntu release: 24.04 LTS or 24.10 CUPS 3.x (release manager: Michael Sweet) libcups 3.0b2 - November/December 2023 libcups 3.0rc1 + cups-local 3.0b1 - March/April 2024 cups-sharing 3.0b1 - September/October 2024 Estimated Ubuntu release: 25.04 CUPS Snap Not treated in Michael's talk, but CUPS 3.x has also impact on the CUPS Snap, caused by the 2 different server types. The snapping of CUPS as we have it now will most probably be applied to the sharing server, which is very similar with CUPS 2.x The Snap of the local server will get simpler, especially It is a user daemon It does not provide IPP print destinations to the network, so it needs less interfaces (for example no network-bind, avahi-observe instead of avahi-control). The \"cups-snap\" repository will get discontinued and folded into \"cups\" (2.5.x) and \"cups-sharing\" (3.x). snapd needs to correctly prioritize to which CUPS Snap's slot the interfaces cups and cups-control of client Snaps get auto-connected."
+ },
+ {
+ "id": "post:OpenPrinting-News-September-2024",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - September 2024",
+ "url": "/OpenPrinting-News-September-2024",
+ "headings": [
+ "cups-browsed remote command execution vulnerability overhyped",
+ "Festa do Software Livre/UbuCon Portugal 2024",
+ "Ubuntu Summit 2024 in the Hague",
+ "Google Summer of Code 2024"
+ ],
+ "tags": [],
+ "snippet": "cups-browsed RCE vulnerability overhyped, Festa do Software Livre/UbuCon Portugal 2024, Ubuntu Summit 2024, GSoC 2024",
+ "content": "Most impactful in September were the security advisories reported for cups-browsed, starting with the report of a remote command execution vulnerability discovered by security researcher Simone Margaritelli and his post about it on X (formerly Twitter) before the official disclosure made it overhyped and main subject of bloggers, podcasters, and YouTubers. In the end it turned out to be much less harmful than was the initial impression suggested. I have been on the Open Source Summit Europe this year (see last month's news), as it was taking place in my city, in Vienna. I also have given a talk about OpenPrinting there, but recordings are not yet released. And now I am also approaching the next events. At first I am following an invitation from Diogo Constantino from the Portuguese Ubuntu Local Community, giving talks on the Festa do Software Livre in Aveiro, Portugal which hosts the UbuCon Portugal 2024 as one of its tracks, a conference held primarily in Portuguese language. Shortly after, I will be in the Hague in the Netherlands for the third Ubuntu Summit, where I am again member of the organization team, but I will also present, together with the Snapcrafters, on a booth and in two workshops. Our GSoC contributors have continued with their work, approaching the completion of their projects. And they have written about their work again. So let us see what happened at OpenPrinting in September ... And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat On September 5 we got a GitHub security advisory (GHSA) on cups-browsed about a remote code execution. It is possible to create an emulation of an IPP printer with forged metadata to make cups-browsed auto-generate a print queue and the PPD generator of libcups or libppd create a PPD with added lines so that the foomatic-rip filter gets used and the PPD defines a filter command line for foomatic-rip which is supplied by the attacker. So we have a remote code execution (RCE) vulnerability. The reporter, Simone Margaritelli (aka evilsocket), started investigating when he discovered that cups-browsed accepts UDP packets on port 631 from any source to trigger a get-printer-attributes IPP request. He then found further bugs leading up to the remote code execution. He posted on X (formerly Twitter) on September 23 that he recently reported a severe security issue, an \"Unauthorized RCE on all GNU/Linux systems)\" with a CVSSv3 score (agreed on with Canonical and Red Hat) of 9.9 of 10, but not telling anything about that it was his report about cups-browsed. He also told in the post that he has spent 3 weeks on the investigations, and that a disclosure date was agreed on with the developers. The message got hidden shortly after, but one can still read it on some archiving sites. Seth Arnold of Canonical's security team made me aware of this X message on Tuesday, September 24, and this started continues conversation of me with the security team on the Canonical-internal chat, along with already ongoing conversation on GitHub and VINCE. On Thursday, September 26 I read on VINCE that the vulnerability has leaked and so we had to agree on a quick disclosure. Instead of on the originally planned disclosure on October 6 we agreed to disclose still on September 26, at 20:00 UTC. Canonical's security team has acted immediately to quickly apply the patches which Michael Sweet (author and maintainer of CUPS) had already prepared for CUPS, cups-browsed, libcups-filters, libppd, and cups-filters (in the time from the first report until then I was some days off and I was also on the Open Source Summit Europe, thanks, Michael Sweet, for stepping in, also thanks to Zdenek Dohnal from Red Hat) to the appropriate in all supported Ubuntu versions, so that at the time of disclosure most fixes were already in place. They also reported in an Ubuntu blog. They tell users what to do, from turning off cups-browsed or at least its legacy CUPS browsing support to updating their systems as the fixes were already available. Thanks a lot to Seth Arnold, Marc Deslauriers, Diogo Sousa, Mark Esler, Luci Stanescu, and more. At the time of disclosure there appeared tons of posts on Mastodon about this subject matter and I have given several answers. A good and detailed description of the vulnerability comes from Simone himself in his blog. Thanks to Simone Margaritelli for the detailed investigation and also the detailed description about how the vulnerability works. Investigators of this kind are really needed to keep free software on a high security level. This vulnerability could never have been found by automated methods like fuzzing or code analysis. Some days later, Peter van Dijk (aka Habbie, also thanks for your report) has reported another vulnerability of the legacy CUPS browsing support as a GHSA on cups-filters. It was possible to send a well-formed CUPS broadcast packet to UDP port 631 of cups-browsed, but with a port 80 URL of a web site which redirects on the port and then cups-browsed falls into an infinite loop sending HTTP requests which can only be stopped by kill -9. This vulnerability got independently discovered and treated in detail by Akamai and posted in their blog. Overhyped The X post by Simone really overhyped the vulnerability. Attacks from the internet are not very probable due to the fact that servers on the internet do not have cups-browsed and CUPS installed and CUPS/cups-browsed setups usually exist only in NAT-protected local networks with desktop machines and print servers. And the remote code execution is also rather restricted, as CUPS filters are not running as root, but as the system user \"lp\" which cannot even read user's home directories. In addition, the remote code execution only happens when a user actually prints a job on the fake printer. Actually assigned scores ended up between 8.4 and 9.1. Fixes Fixes are already available in the appropriate upstream repositories: cups-browsed, libcupsfilters, libppd, cups-filters, cups. Especially we have removed legacy CUPS browsing (and also LDAP) support from cups-browsed and added verification of the content of IPP responses and of content filled into PPD files, to not contain control characters like newlines. These changes are sufficient to prevent the reported exploits. We did not yet add any protection against PPD files defining malicious filter command lines for foomatic-rip. A possible solution we are discussing is providing a hash database for all command lines in the existing PPD files but also isolation/encapsulation/containerization of Foomatic-based filtering. See more info and a list of all CVEs and patches in our separate News Flash. In a few days I will depart to Portugal, exactly to the city of Aveiro, close to O Porto. Diogo Constantino, who is leading the Ubuntu Local Community (LoCo) Portugal, has, as he interviewed me on the Podcast Ubuntu Portugal #310, invited me to come to the event. It is the Festa do Software Livre, a 2-day conference with a main track and several sub-conferences co-located by different open-source organizations: Drupal, Flutter, WikiMedia Portugal, Inêrcia, and the UbuCon Portugal. Here are the schedules: Festa do Software Livre, UbuCon Portugal I will give 3 sessions during the event, all in Portuguese: OpenPrinting - A boa impressão do software livre Fri, October 11, 14:00 - 15:00 WEST, Anfiteatro IV (Main Track) I will give an overview of our work. Going through OpenPrinting’s history the components of the printing infrastructure of modern Linux (and other Posix-style) operating systems will get shown. How did the Internet Printing Protocol (IPP) with the printing system CUPS being an implementation of it simplify printing a lot? The printer driver challenge, good and bad cooperation with manufacturers, packaging and distributing ... Desktop integration, GUI toolkits, print dialogs, setup tools, portals, ... Especially also the New Architecture of all-IPP printing and scanning and also the integration in immutable OS distributions will be treated ... And in the end I will also quickly tell about Microsoft going all-IPP in Windows ... This is the same talk as I had given on the FOSDEM, on the Opportunity Open Source, and on the Open Source Summit Europe, but in Portuguese language. And I got a generous time slot of 60 min, meaning that we have a lot of time for questions, answers, and discussion. Linux para desktop, fácil como um smartphone! Graças ao Snap! Sat, October 12, 09:30 - 10:30 WEST, room 4.1.02 (UbuCon PT) The motivation, advantages, and concept of the sandboxed, immutable Snap packaging format is shown and how it is used to make up immutable all-Snap OS distros, the IoT distro Snap was originally designed for, Ubuntu Core, and the easily usable and maintainable Ubuntu Core Desktop. This is the same talk as I had given on the FOSDEM, on the GUADEC, and on the Opportunity Open Source, but in Portuguese language. And here I also got a generous time slot of 60 min, meaning that we have again a lot of time for questions, answers, and discussion. O seu aplicativo para todo mundo! Graças ao Snap! - Oficina interativa Sat, October 12, 11:00 - 13:00 WEST, room 4.1.02 (UbuCon PT) Vamos snapear! (Let's snap!) - Interactive workshop to learn how to package applications in the sandboxed, immutable package format Snap to publish them in the Snap Store. Attendees will create simple Snaps in several hands-on exercises. This is the same workshop as I had given on several other conferences, but in Portuguese language. And here I also got plenty of time, 2 hours, whereas on other events I got only 60 or 90 minutes. I also do not need to give a long introduction as I will give my talk right before. So we have a lot of time for doing the exercises. And if you want to participate, do not forget to prepare your laptop before. Most probably the sessions will get streamed, so that one can also attend them remotely. The third Ubuntu Summit is only little more than two weeks away from us (on October 25-27). The schedules are published. As announced already we will have one plenary room for talks and an additional room for workshops. And we will have an exhibition floor with 26 booths of open-source organizations. As already told last month, I will be presenting Snap together with Merlijn Sebrechts, Heather Ellsworth, Soumyadeep Ghosh, and Lucy Llewellyn from the Snapcrafters. We will have a booth and the following two workshops: Crafting snaps quickstart guide 101 Sat, October 26, 16:30 - 17:30 CEST, room Princess Ariane (Workshop room) This is an interactive workshop where you learn snapping (package applications as Snaps), based on the original workshop given by Heather Ellsworth and me on several other conferences. You will make Snaps of simple GNOME and KDE applications on your laptop. You will use interfaces for defined communication with the outside world, content Snaps providing common libraries (GNOME, KDE ffmepeg, ...), learn several methods how to make software running in a sandbox, build and run the applications, ... And our team will be in the room and help you on all your questions and doubts ... How to build and test your snaps automatically using GitHub actions Sun, October 27, 14:00 - 15:00 CET, room Princess Ariane (Workshop room) Original description: In this workshop we will showcase how one can use GitHub actions to automate the building and testing of Snaps. We will show users how they can use the already created CIs directly. Or, how they can modify and change those according to their needs. We'll show how to run VMs inside the GitHub runners using ghvmctl and run GUI apps. We will also have a workshop created by our OpenPrinting GSoC OSS-Fuzz project team. The 2 mentors George-Andrei Iosif and Dongge Liu will be on the Summit to give Fuzzing in the open: Integrate your project in OSS-Fuzz for continuous fuzzing Sat, October 26, 11:30 - 13:00 CEST, room Princess Ariane (Workshop room) They will teach how you can make your free software application project more stable and more reliable by using Google's OSS-Fuzz service to make your code undergo continuous fuzz testing. They will explain what fuzz testing is and how OSS-Fuzz works with their work on OpenPrinting as example, how to write Fuzz harnesses, and how to make use of the test results to fix crash bugs (which are often possible vulnerabilities). Unfortunately, our GSoC contributor, Jiongchi Yu will not be able to come to the Hague. If you want to attend these workshops (or any other workshop on the Summit) please open the session description by clicking the session in the timetable follow any preparation instructions there and/or also download the slides (under \"Presentation Materials\" at the bottom) and follow preparation instructions in there. Also you will have the slides at hand to copy and paste any commands and examples. Preparations are usually things like installing the needed operating system/virtual machine and needed software. Our GSoC contributor Akarshan Kapoor is on the Ubuntu Summit again, but not with a talk about Scanner Applications. Doing his second exchange semester in Germany, inspired by the technology used in the trains of the German railway he will give the talk Flush with Innovation: Revolutionising Train System Toilets with Embedded Technologies Sun, October 27, 14:30 - 14:55 CET, room KWA (Plenary room) Original description: This talk will cover updates on the hardware, firmware, and software developments of the Pump Monitor, a unique device currently used by Deutsche Bahn, leveraging recent Zephyr RTOS (real time operating system) components like zbus. The core of the talk will delve into the architecture and development path of our Open Source IoT LwM2M and Django server, highlighting its robustness, flexibility, and user-friendly interface. Additionally, the session will address sustaining cloud infrastructure through Open Source solutions, ensuring reliability and security via protocols like LwM2M and CoAP, and promoting the benefits of Open Source adoption in real-world applications. The project utilizes a local server-based IoT system leveraging the Lightweight Machine to Machine (LwM2M) protocol, enabling communication between IoT devices running Zephyr RTOS and a backend server using Django, operating fully within a local environment without external cloud services. And if you want to attend any live-streamed sessions (talks in the plenary room) remotely, note that in the night between the Saturday and the Sunday of the Summit the daylight saving time in Europe ends, meaning that on Friday and Saturday we have CEST (UTC+2) and on Sunday we have CET (UTC+1). See you all in the Hague! Rudra Pratap Singh has officially completed his project of OCI containerization of CUPS and the Printer Applications, but he still does some testing and we will need to make his work available. For this we will need to create a DockerHub account for OpenPrinting and also transfer his work to be hosted in the OpenPrinting GitHub. The other 10 contributors are all nearing the completion of their projects. Most have gotten additional deadline extensions due to important events interrupting their project work, but they and their mentors are reporting that they are doing well. As the second contributor Biswadeep Purkayastha, adding CPDB support to LibreOffice's print dialog, will reach the finish line. He has already submitted his final report. And here are the write-ups: CPDB support for the LibreOffice print dialog
Contributor: Biswadeep Purkayastha
Work Product This month, I worked on resolving an issue where user-set default values were not being properly applied in CPDB. The problem occurs when user default settings are defined using lpoptions. CPDB fails to recognize these newly set user defaults as the actual defaults when retrieving options. Upon further investigation, I discovered that CUPS is not returning the correct default values when queried by CPDB, indicating the issue likely lies with CUPS. I've submitted a detailed issue report on the CUPS GitHub repository and am currently awaiting a response from Michael Sweet. In the meantime, I am focusing on wrapping up my project and fine-tuning minor details in preparation for my final submission. WIP Pull Request. Integrating C-based OpenPrinting Projects in OSS-Fuzz Testing
Contributor: Jiongchi Yu In September, the OpenPrinting fuzzing project integrates more harnesses for libcupsfilters and cups-filters. We upgraded the harness for cups-filters from version 1.X to the latest 2.X to better align with the long-term development goals of OpenPrinting ecology. However, due to the current OSS-Fuzz base image lacking support for operating systems higher than Ubuntu 20.04 and the corresponding dependency libraries, the ClusterFuzz compilation for the two projects remains failing. We are actively communicating with Google developers to resolve this issue. Additionally, we have triaged 27 identified issues found by existing OSS-Fuzz harnesses and submitted relevant issue reports and security advisories for the confirmed bugs. Moving forward, we are working on involving more LLMs efforts to help generate effective fuzz drivers and towards more secured OpenPrinting projects. CPDB support for the print dialog of Mozilla
Contributor: Kushagra Sharma Progress has been made in the integration of CPDB. After successfully setting up the dummy print backend, I have now transitioned to replacing the placeholder calls with CPDB APIs. These APIs are being used to populate the print backend in Mozilla, enabling more robust print functionality. This phase involves ensuring that the CPDB integration is seamless and interacts correctly with other components. I'm also focused on fixing import issues with CPDB and testing edge cases and across different environments. As this work nears completion, I anticipate submitting a pull request shortly for review, which will mark an important milestone in this project. Kushagra created a good collaboration with the Mozilla developers now, via my original feature request. Desktop Integration: Update system-config-printer for the New Architecture of printing
Contributor: Shivam Jaiswal I have written the asynchronous service discovery code and created a basic UI structure for discovered services. I have added buttons to list all discovered services. My next goal is to merge the final code for service discovery into the main GitHub repository of SCP. After that, I will finalize code for add printer part. Make a native printer Application from Gutenprint
Contributor: Ankit Pal Singh Currently working on status callback function, documentation and the job flow. Fixing some minor issues, once this is done then I will start with pappl backend implementation. User interfaces for using OAuth2 with printers and scanners
Contributor: Shivam Sharma This month the major focus was on improving the security levels in OAuth code and merging OAuth code with CPDB. I implemented the auth.h file and called the auth.h file in the print-backend.c file and also made a few changes in makefile which helps to merge the auth code with the CPDB backend. Currently I am working on the gtk of OAuth. Also testing the code with different authentication url. After finishing this task the focus will be on adding more functionality and improving the way of authentication which will be made easier for the clients to authenticate themselves. The changes will be made to improve the GTK and level of authentication. Converting Braille embosser support into a Printer Application
Contributor: Arun Patwa In September Month, I was majorly working on integration of braille embosser support into the PAPPL Application for the brf file. Got stuck into embosser support for long time. I had done some testing for the conversion and also refractored the code. I aim to complete the integration of other filters in the upcoming weeks and also testing of braille embosser support for them. Replace QPDF by PDFio as PDF manipulation library in libcupsfilters
Contributor: Uddhav Phatak I have sucessfully ported all the files in the cupsfilters/pdftopdf/, and all tests are passing with the make check. The remaining three files are pwgtopdf.cxx, pdf.cxx, and pclmtoraster.cxx. In this, I have already converted half functions of pclmtoraster.cxx and pdf.cxx. Soon, all the code will be converted to C and the dependency from the QPDF library would be removed completely. Here is Uddhav's work on GitHub."
+ },
+ {
+ "id": "post:OpenPrinting-News-Sovereign-Tech-Agency-is-investing-in-OpenPrinting",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Sovereign Tech Agency is investing in OpenPrinting",
+ "url": "/OpenPrinting-News-Sovereign-Tech-Agency-is-investing-in-OpenPrinting",
+ "headings": [
+ "I was working at Canonical for a long time ...",
+ "... looking for a new solution ...",
+ "... the Sovereign Tech Agency ...",
+ "... Now I am working at OpenPrinting",
+ "Thanks"
+ ],
+ "tags": [],
+ "snippet": "I am covered to work on OpenPrinting full-time until end-2026",
+ "content": "Also announced on Mastodon and on LinkedIn Mid-May, on the last Engineering Sprint of Canonical I got the notice that I got laid off by Canonical, after having been with them for near 20 years. The contract ended 4 weeks after that, mid-June and I got 3 months of my monthly payment as indemnity. See also my earlier post. I naturally wanted to continue OpenPrinting as my living and not have to take an arbitrary job and continue OpenPrinting as a hobby. So my first efforts were to make OpenPrinting a full sub-organization of the Linux Foundation so that it can handle money, to be able to get sponsorships, especially also via membership tiers. Our idea here is to get sponsored by the companies who most benefit from OpenPrinting, like major OS distributions, computer manufacturers who make laptops and desktops with Linux, printer manufacturers, cloud groupware/office developers, ... But getting this up and running takes time. We already tried to get a full sub-organization before my lay-off, but the process always got stuck. Now I see the chance that we will complete it due to its urgency. We are working on creating the Technical Charter which is required, and I have also already lined up the needed Technical Steering Committee. The people from the Linux Foundation also want to help me to find the sponsors. Many of the candidates are already Linux Foundation members and they could take up an OpenPrinting membership in addition. In parallel I tried to make people know about my situation. I posted a thread on Mastodon/the Fediverse and asked for boosting, and the thread (at least its initial post) got boosted 1187 times (Thanks to you all! I have never seen any other post in the Fediverse which got boosted that much)! I also (finally) filled in my LinkedIn profile and also created a profile for OpenPrinting. I interacted with a lot of people via LinkedIn, invited people who could help to connect with me on LinkedIn and then I asked them for help. One was Tara Tarakiyee from the Sovereign Tech Agency (STA), an organization of the German government which supports open source developers and organizations whose work goes into development an maintenance of software which is essential for IT and internet infrastructure and therefore of public interest. I told him about OpenPrinting and my situation and whether the STA would support me. Then he asked me for details of my work and offered me support from the STA. I had to express my (or OpenPrinting's) needs in work hours and money (the first time I had to do such a thing in my life) and within a few weeks my proposal got accepted and now the Sovereign Tech Fund invests in OpenPrinting to sustain me at the same monthly compensation as I got from Canonical (by average) until end of 2026. Here is the page about their investment in OpenPrinting and it got also mentioned in their October Newsletter. Yes, when somebody asks my where I am working, I will say its OpenPrinting, I am now self-employed as its lead. Note that the STA did not hire me as an employee, but they hired me as a freelancing engineer, paying my work hours which I am billing to them. I am also continuing to pursue establishing OpenPrinting as a full sub-organization of the Linux Foundation, to be open for further funding of the organization and this way to assure its continuation and so printing to just work also in the future. I want to express my thanks for all the help and support I have gotten in this situation, first of all Tara Tarakiyee, Hanno Zulla, Paloma Oliviera, and probably also others from the Sovereign Tech Agency for the quick arrangement of the investment. I also want to thank Kate Stewart, Todd Benzies, Michael Dolan, Scott Nicholas, and Daniel Scales from the Linux Foundation for the great support to make OpenPrinting a full sub-organization of the Linux Foundation and to help us to get funding. And big thanks to those who have joined the Technical Steering Committee of OpenPrinting with me: Michael Sweet, Aveek Basu, Zdenek Dohnal, and Thorsten Alteholz. Special thanks to all the people who have worked and are working with me at OpenPrinting to make OpenPrinting the strong organization which it is now and so make printing just work (I give some names, there are many more): Michael Sweet, Kurt Pfeifle, Grant Taylor, Ira McDonald, Ulrich Wehner, Ian Murdock, Mark Shuttleworth, Aveek Basu, Zdenek Dohnal, Alexander Pevzner, Johannes Meixner, Didier Raboud, Thorsten Alteholz, Deepak Patankar, Sahil Arora, Akarshan Kapoor, Soumyadeep Ghosh, Sanskar Yaduka, ... Thanks a lot to the organizers of the Google Summer of Code, especially Stephanie Taylor, Carol Smith, and Leslie Hawthorn to make this great program running which helped us to get a lot of awesome developers for our community. Also thanks for all the coverage on the Internet, especially to Heather Ellsworth (Ubuntu Indaba), Monica Ayhens-Madon (Ubuntu Office Hours), Michael Tunnell, Jill Bryant, and Ryan (Destination Linux), Joe Ressington and Graham Morrison (Late Night Linux), Noah Chelliah (Ask Noah), Diogo Constantino (Podcast Ubuntu Portugal), Liam Proven (The Register), ...
And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions"
+ },
+ {
+ "id": "post:OpenPrinting-News-Tech-over-Tea-300-Brodie-interviews-Till-Kamppeter",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Tech over Tea #300 - Brodie interviews Till Kamppeter",
+ "url": "/OpenPrinting-News-Tech-over-Tea-300-Brodie-interviews-Till-Kamppeter",
+ "headings": [
+ "The full episode",
+ "Highlight clips",
+ "Why Did Canonical Part With The Leader Of Linux Printing",
+ "The Future Of OpenPrinting",
+ "OpenPrinting CUPS vs. Apple CUPS",
+ "He's Why Printers Work On Linux",
+ "The State Of Linux Printing Before CUPS",
+ "The Long History Behind OpenPrinting On Linux"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/-6fPfwixNLk/hqdefault.jpg",
+ "snippet": "Everything about OpenPrinting, history, what we are doing, funding and the future, ...",
+ "content": "Many of you know the YouTuber Brodie Robertson, mostly by his main channel, just named Brodie Robertson where he is talking about and discussing the latest news and incidents in the FOSS world (ex.: \"Can't print on Tuesdays\") and often causing controversial discussions in the comment sections. But he has also a second channel, Tech over Tea, where he does, once a week, an interview with a person who is doing important things for free and open source software. Back in April this year, Brodie had posted on Mastodon asking for nominating potential guests for future episodes of Tech over Tea. I had taken that opportunity then and sent an e-mail to Brodie: I have seen now that you are asking for nominations for guests in \"Tech over Tea\" on Mastodon. And I know that the person who is leading OpenPrinting is one of these project developers interested to be guest in your show. So I am nominating him with this e-mail, yes myself. ... He liked the idea and accepted my offer and we aimed for producing and publishing the show before the northern-hemisphere summer holidays. Unfortunately, in May, the incident with Canonical happened and I did not know how things with me and with OpenPrinting will go on in the future, and in this situation I did not want to give the interview, so I asked for postponing the production until the issue gets sorted out ... ... when I got the investment of the Sovereign Tech Agency and so being mostly recovered, I mailed to Brodie again and told him that I am now ready for producing the video, aiming for publication well before the end-of-year holidays. So we did it and it came out great! I got many likes and some questions on the social media where I linked the videos and on the videos themselves on YouTube. I answered all the questions, liked many a and disliked a few comments, and I also got a lot of likes for that, also from Brodie. Have fun watching the interview (below) and feel free to comment and ask your questions in the YouTube comments ...
And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and (new) on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Brodie's announcement on Mastodon: Today we have the legendary @till (Till Kamppeter) on the show, the man keeping printers working on Linux to talk about his decades of experience in this space This is the full interview, in 2 hours I am telling what we are doing at OpenPrinting, how it all began 25 years ago, and also about my layoff from Canonical and how I am recovering (a big thanks again to the Sovereign Tech Agency!) Currently 29 comments on YouTube, including all answers I have also posted on LinkedIn about it, and got 30 reactions and 1 repost! Is watching/listening to a full 2-hour Tech over Tea episode not your cup of tea? Do not run for a coffee now to keep yourself awake for the 2 hours, but just watch the most breaking news in it which Brodie has separated for you, as usual one on each of the 6 days after the release of the full episode. The first of them is about the incident with Canonical and how I am recovering, and fairly well (thanks again, Sovereign Tech Agency) as I am covered until end-2026 now! 1 comment on YouTube The second one is about the future of OpenPrinting and how it will get continued on the long run. This one is not only about what happened to CUPS after Michael Sweet had left Apple, but I also tell about CUPS 3.x, the New Architecture, classic drivers and PPDs getting dropped, driverless printing, how it began and how it works, and that driverless printing even can save your legacy printers under Windows ... 9 comments on YouTube, including all answers This clip is about what OpenPrinting is, how we make use of the Google Summer of Code, how classic printer drivers were developed by reverse-engineering, how I made them easily available for everyone and about IPP ... 28 comments on YouTube, including all answers Now it is about my time as system administrator in the Theoretical Physics department of the University of Bayreuth in Germany, from 1997-2000, in the pre-CUPS era, the dark years of LPD ... 1 comment on YouTube The last one is about how I discovered CUPS and how after that I got discovered for making CUPS what it is today."
+ },
+ {
+ "id": "post:OpenPrinting-News-The-Winter-of-Code-4.0",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - The Winter of Code 4.0",
+ "url": "/OpenPrinting-News-The-Winter-of-Code-4.0",
+ "headings": [
+ "The project ideas we have on offer are:"
+ ],
+ "tags": [],
+ "snippet": "OpenPrinting is mentoring organization in the WoC 4.0! Apply for doing a 1-month project until Dec 31!",
+ "content": "Some weeks ago I got e-mail from the Google Developer Groups (GDG) on Campus IIIT Kalyani inviting me as Google Summer of Code (GSoC) org admin for the Linux Foundation to participate in the Winter of Code (WoC) which they are organizing. Actually, they seem to have invited all the GSoC mentoring organizations, as I got the same e-mail also via the LibreOffice developer mailing list. The Winter of Code is an Open Source contributor program inspired by the Google Summer of Code, but with only a 1-month coding period and no stipends for contributors and mentors. It is organized by folks at the Indian Institute of Information Technology Kalyani, but as they have approached other GSoC organizations, too, it is not based on my relationships with India that they invited me. The program is performed for the 4th time this year but I only got note this year, by the mentioned e-mail. I decided to participate with 3 small projects to try out the program and see whether it attracts people to join our developer community and also for potential GSoC contributors, by giving us nice code samples by their work on our WoC projects. Add support for JPEG-XL as input format
Mentors: Uddhav Phatak, Till Kamppeter JPG-XL is a more modern successor of JPG, supporting high color depths (>8 bits per color), HDR, more flexibility with compression rates, ... to allow for high-quality image files in a standard format. A free software library supporting this format is available, libjxl. Therefore we should add support for this format and try to carry on to the printer as much as possible of the image quality, especially the higher color depth, as the PWG and CUPS Raster support up to 16 bits per color. Create an OCI container image of ipp-usb
Mentor: Rudra Pratap Singh As we have OCI container images for CUPS and for the 4 retro-fitting Printer Applications at OpenPrinting, we also want to have an OCI container image of the IPP-over-USB daemon ipp-usb. This way we can provide the full printing stack as OCI container images, ideally on DockerHub. This allows to add printing functionality to most immutable distributions, and also to distributions in general, using official packages of OpenPrinting. Apply OSS-Fuzz to cups-browsed
Mentor: Jiongchi Yu We have deployed OSS-Fuzz on CUPS (2.x), libcups (of CUPS 3.x), libcupsfilters and cups-filters now to efficiently discover crash bugs and vulnerabilities on these components. But recently, we had a security vulnerability on cups-browsed, which is not covered by OSS-Fuzz. Therefore we want to apply OSS-Fuzz here, too. We will also accept your own project ideas. If you are interested, please register as a contributor on the WoC web site. Last day for registering is December 31. Until January 12, you will need to submit your proposal then and coding period is January 20 - February 20 (see complete schedules). It is not required to be a student or an open-source beginner, everybody can participate. Please also check out the FAQs. A well-done WoC project can also be your launchpad to the GSoC as we will for sure give you higher priority in the GSoC contributor selection process then. We are looking forward for your participation. And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-UbuCon-Asia-2025-in-Kathmandu-Nepal",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - UbuCon Asia 2025 in Kathmandu, Nepal",
+ "url": "/OpenPrinting-News-UbuCon-Asia-2025-in-Kathmandu-Nepal",
+ "headings": [
+ "Why attending a conference in Nepal?",
+ "Arriving in Nepal",
+ "Day 1",
+ "Day 2",
+ "The day trip",
+ "And off to India ...",
+ "Thank you",
+ "Links"
+ ],
+ "tags": [],
+ "snippet": "Organized by the Ubuntu and GNOME communities of Nepal",
+ "content": "This year we have done the third Opportunity Open Source in India, and originally having planned to co-host the first UbuCon India with it we had settled it on the weekend right after this year's UbuCon Asia which has taken place on August 30-31 in Kathmandu in the neighboring country Nepal, to make it possible that speakers could be on both events with only one round trip. But even with the co-hosting not having worked out, and also with my talks already being accepted, I have done this round trip and attended UbuCon Asia before running the Opportunity Open Source 3.x in the IIT Kanpur in India. My trip from Vienna to Kathmandu went through the beautiful Doha Airport in Qatar, via Qatar Airways. With 2 ~5-hour flights with a meal ~2 hours into each flight and the stop-over in the middle of the night I had not much sleep when I arrived in the morning of Friday, August 29, the day before the conference started. After landing and going through immigration (was quick as I already applied for my tourist visa online before traveling) I met Mauro Gaspari (Ubuntu Community Team at Canonical) and Dimple Kuriakose (Technical author at Canonical) at the baggage claim and we shared a taxi to the hotel. The hotel was in the Thamel district. There are many streets with small stores selling handcrafts and souvenirs and there I bought some stuff for my wife. In the evening I met Soumyadeep Ghosh (Snapcrafters) and talked with him about his GSoC project (Blog) of Python bindings for libcups3 and he brought in the idea of creating programming-language-independent APIs for printing and also of oxidizing (converting to Rust) libcups and CUPS as future work at OpenPrinting. I told him that for oxidizing on one side we will have a lot of work and the risk to introduce new bugs but on the other side we have rather low coverage with fuzz-testing the C code, so replacing it my memory-safe Rust could be the better solution. On Saturday, August 30, the UbuCon started. Arriving at the venue one saw a long line of people waiting. It was for the registration desk in front of the building, for the more than 300 people just attending the conference, but not giving a talk or a workshop. Speakers got shown a hidden room inside the building where they could pick up their badges. The organizers (a sponsor?) provided us with highly sophisticated all-plastic badges, which were not that easy to assemble, especially removing the protective plastic film. But this way the sponsors assure that, if a badge gets into the environment, their logos will still be seen in centuries ... After the introduction from the organizers the first session was the keynote presentation by Dimple Kuriakose, \"Confidential Computing Demystified: An in-depth look into CVMs\" (Slides), explaining all the measures in the Ubuntu operating system to keep the system secure and protect the data and privacy of the users. And since the Ubuntu Summit 2022 there is practically no conference any more without workshops, and the first workshop this time was \"Crafting snaps quickstart guide 101\" (Slides, Exercises), by Soumyadeep Ghosh and me. The room was nearly full, showing that there are many people interested in packaging applications in the Snap format. In total there were 6 workshops throughout the 2 days: Snap, LXD, AppArmor, Local AI/LLMs, Documentation on GIT, and air-gapped Ubuntu. There was lunch in the cafeteria of the college, free of charge for speakers and included in the conference fee for general attendees. Organizers redirected speakers to early and late hours during the lunch break for them to avoid long waiting lines. In the afternoon Akarshan Kapoor, GSoC contributor for OpenPrinting in 2023 and 2024 presented his GSoC work in the talk \"Scaniverse Universal Scanner Drivers: One Solution for Every Distro\" (Slides). My second time on the stage was also on the first day. I have participated in the panel session \"Growing Ubuntu and FOSS Community - and yourself, Locally and Globally\", hosted by Yush Pokharel and with Aryan Kaushik, Rashika Karki, and me as guests. Everyone told here about the creation of their projects and building their communities, and the audience could ask questions afterwards. The second day, Sunday, August 31, started for me with the exhibition area. Despite being the rainy season in South Asia, the booths were set up on an open-air space, each of them was at least under a tent to protect them from rain. Especially I visited the DeepComputing booth, in the hope to meet founder Yuning Liang, but he was not there. I also wanted to try out the second-gen RISC-V motherboard for Framework laptops, but due to my visit right in the beginning of the conference day the electric cables were not yet set up (they had to be removed during the night because of the rain) and so they had no working machine. After that I went to the Ubuntu booth to meet some former colleagues and friends, Mauro Gaspari, Andreia Velasco, and others. As this event is an UbuCon, the Ubuntu booth was not in the outdoor space but right in front of the door of the main lecture hall, where the plenary sessions were taking place. In the afternoon I attended Graham Morrison's workshop \"Open Documentation Academy Live: Make your first open source contribution\" (Slides) which was about documentation and managing it in GIT repositories, to get ideas to handle documentation at OpenPrinting. The last talk I attended on this UbuCon was \"How to build a sustainable Open Source company\" by Frank Karlitschek, creator and founder of NextCloud. This was interesting for me and OpenPrinting for two reasons, once, for the economical aspect how Nextcloud earns money, and second because of Nextcloud itself, as I am also thinking about having it on a server of OpenPrinting, for collaborative office document work, video meetings, conference streaming, download management, ... What I missed during the day was a printing incident in the exhibition space. Yeonguk Choo from the Ubuntu Korea LoCo (Local Community) has, inspired by a photo booth on the Ubuntu Summit 2023 in Riga, created his own photo booth based on Ubuntu and free software, Ubu4Cut and deployed it for the first time on the UbuCon Korea. Then he brought it to this year's UbuCon Asia. On the first day Ubu4Cut behaved well and many attendees lined up for taking photos to take home as souvenir, but on the second day, at some hour in the morning, the photo printer (some Canon Selphy device) stopped working. Youngbin Han, lead of the global organization of the UbuCon Asia conferences and lead of the Ubuntu Korea LoCo, was there and directly messaged me on both Matrix and Telegram, but I must have been busy with something and so I did not see the messages, sorry. But, fortunately, I have built a nice team at OpenPrinting, with the help of the Google Summer of Code, and so Akarshan Kapoor, one of our most amazing team members, who was at the booth at that time, solved the problem. Thanks a lot, Akarshan, for helping to make printing just work everywhere! The conference ended with a closing ceremony where all the speakers, sponsor representatives, and organizers were called onto the stage, one by one to receive their tokens of appreciation. After that we have taken a group photo and then headed to the venue of the conference dinner, hosted by one of the event's sponsors, Programiz. The place was beautiful and the food delicious, a great night to network with the speakers and the sponsors. And that was not the end. On Monday, September 1, there was another opportunity to socialize with the conference participants and also to see a bit of the beautiful Nepal. In the morning we were taken by bus to Bhaktapur, to visit the palace and the museum there and after lunch our bus took us up the mountains, to Nagarkot, where we crossed a long suspension bridge over a deep valley and we also got to a viewpoint where we were supposed to see the Mount Everest and other 8000+-meters mountains, but unfortunately, we did not have a clear that day ... Next day, Tuesday, September 2, I had to say good bye to Nepal as the next adventure, the Opportunity Open Source 3.0 in India, in the IIT Kanpur was approaching ... Thanks a lot to the global and local organizers Youngbin Han, Khairul Aizat Kamarudzzaman (fenris), Muhd Syazwan Md Khusaini, Rj Hsiao, Aryan Kaushik, Aaditya Singh, Sailesh Singh, and Utsav Bhattarai. Also thanks a lot to the speakers: Dimple Kuriakose, Soumyadeep Ghosh, Akarshan Kapoor, Yush Pokharel, Aryan Kaushik, Rashika Karki, Mauro Gaspari, Andreia Velasco, Graham Morrison, Frank Karlitschek, and to the many others whose talks I have missed ... And also to the sponsors and to St. Xavier’s College! And especially thanks to Canonical for funding my trip, and also to Mauro Gaspari and Gemma Mulcahy for making this going smoothly and helping quickly where needed. I hope to see you all again, perhaps in Malaysia ... UbuCon Asia 2025 web site Photos from the community Schedules Ubuntu Discourse post from Youngbin Han Ubuntu Discourse post from Aryan Kaushik Ubuntu Discourse post from Yeonguk Choo And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social and on LinkedIn: @OpenPrinting. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions"
+ },
+ {
+ "id": "post:OpenPrinting-News-We-got-a-Framework-RISC-V-board-from-DeepComputing",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - We got a Framework RISC-V board from DeepComputing",
+ "url": "/OpenPrinting-News-We-got-a-Framework-RISC-V-board-from-DeepComputing",
+ "headings": [
+ "From a RISC-V SBC to a shiny RISC-V Framework motherboard",
+ "Setting it up - The quirks of a pre-production unit",
+ "The keyboard during boot",
+ "And what about Snap?",
+ "Summary OR The Setup HOWTO",
+ "Links",
+ "Contact us"
+ ],
+ "tags": [],
+ "teaserImage": "https://img.youtube.com/vi/RFQ_TvCYBYM/hqdefault.jpg",
+ "snippet": "RISC-V board for OpenPrinting for development and testing, getting it all to work, Ubuntu Desktop, Snap on RISC-V",
+ "content": "On the Ubuntu Summit 2024 in the Hague end-October 2024 there was a booth of DeepComputing, manufacturer of RISC-V-based laptops and consumer electronics, right next to the booth of Framework, manufacturer of the famous modular, easiliy repairable and upgradeable laptops. At the DeepComputing booth I met DeepComputing's founder Yuning Liang (his Ubuntu Summit talk, slides, video) and told him of OpenPrinting and he gave me a RISC-V-based SBC for testing OpenPrinting's software on this platform. He also put me in contact with people who could help me to get an operating system onto the SBC and I was in good hope to get able to install Ubuntu on it. Unfortunately this did not work out and when FOSDEM was approaching in the beginning of February I saw that DeepComputing had there a booth again and Yuning was also there (he has given a talk, video). So I have taken the board with me to ask for help to get Ubuntu onto it. I attended the talk and after it I went with Yuning to the booth. But Yuning did even something better, he has replaced the SBC by a shiny new RISC-V motherboard for Framework laptops, the one which got recently released for general sale and which Nirav Patel, founder of Framework, has installed in a Framework laptop in a lightning demo on the Summit. And I do not even need a Framework laptop for using it, as he gave it to me in the Cooler Master standalone case with Wi-Fi antennas and interface modules, plus a kit for updating the board's EC firmware. The OS pre-installed on it was Ubuntu 24.04. Now I have a working RISC-V sample for OpenPrinting! I directly went back to the Ubuntu booth and set it up there for a first test. Fortunately, I had brought a wired keyboard and mouse and some old USB-C power supplies. Colleagues asked for bringing such stuff for demoing Raspberry Pis but nobody actually set them up, so we had an even nicer demo of the Framework/DeepComputing RISC-V board on the Sunday afternoon. There was not much to demo though as there were still some issues, and so we quickly messed it up ... Note that we have a pre-production unit (the so-called \"Early Access Edition\") here, so it is to expect that there are some hick-ups ... When we booted it for the first time on the booth we had to do some quick lookups on the internet to find out that the power has to be fed in on the upper left or upper right USB-C and also where the power button is in the standalone case (tiny black button at the upper right). Then, everything once plugged together correctly, the system booted and we already saw the USB keyboard not working in the GRUB boot menu but after the menu had timed out it slowly booted to a GNOME desktop, only that this GNOME desktop was probably the upstream default of GNOME, not the Ubuntu desktop at least. The wallpaper was a DeepComputing one. Exploring around on the desktop we also found that there were no web browsers and doing a system update (apt dist-upgrade) the update complained about \"No space left on device\", and continuing after cleaning (apt clean) it errors on the gdm package, after that the system did not boot any more. Back at home, I wanted to reload the original operating system image on the micro-SD card which serves as storage for the device to restore the system and when I wanted to open the standalone case I saw that it uses small Torx screws, T5 size according to what is written on the box the case came in. I did not have a screwdriver for it and remembered the Framework screwdriver with Torx/Philips flippable double bit on the FOSDEM booth. Probably it was forgotten to get packed into the kit. As Framework asks for 12 EUR for shipping when buying the 5 EUR tool I ended up going to a nearby big-box electronics store and bought an iFixit toolkit, containing the needed bit, and, because of my \"No space left on device\" experience on the FOSDEM, a 256-GB micro-SD card. The re-flashing of the SD card was then easy, just putting it into a reader connected to my laptop and using dd via (use a tool like GNOME Disks to see whether the output device is really /dev/sda) restored the system. sdcard.img is the uncompressed system image (Setup instructions and download). And the \"No space left on device\" was not due to a too small micro-SD card. The one which came with the board is 64 GB but the root partition was only 16 GB and the ext4 file system in it only 8 GB. So just resizing them to fill up the card's capacity using (GNOME Disks for example) would already do the trick. But with a 256 GB card at hand I used that one, to not run out of storage later. The system booted as usual, looong GRUB boot menu timeout and USB keyboard not working in GRUB menu to stop it. Now I had a desktop again to explore around in it. An important point I discovered: Printing just works! I see my driverless IPP printers and can print on them. For the missing web browser I was not able to install Firefox or Chromium, but I found the Epiphany browser: and could browse the web but not play YouTube videos. Local video files do not play with totem even with all GStreamer codecs (gstreamer1.0-plugins-XXX with XXX being base, good, bad, and ugly) and ffmpeg installed and there were also sound issues. I told Yuning about the first issues and he gave me some first answers. I also posted about them on a longer Mastodon thread started by Zygmunt Krynicki, at Canonical responsible for making Snap working on all distros, and he told me to post them on the bug tracker on GitHub where I reported all of them (see the links throughout this article for individual reports), and I got them answered. For most of them I got told that they will get addressed in the next image version, V1.1 of the Ubuntu 24.04 image. The Ubuntu 24.04 V1.1 image Shortly after Canonical has issued the Ubuntu 24.04.2 LTS point release the V1.1 image based on this release got published (yes, it contains my fix for the 100%-CPU bug of cups-browsed). I installed it and Most of my reported issues got fixed! So my bug reports worked out. Booting into the new system started with a quicker timeout of the still not accessible GRUB menu and arriving on the desktop a first-time wizard asked for defining host name, user name, password, time zone, ... Also the root partition and file system were automatically extended to the size of the card. So from a test setup (with user and password being \"roma\") we have advanced to an end-user/production setup now. After the setup wizard I got presented a nice Ubuntu Desktop now, GNOME with launcher on the left, Ubuntu theming, Ubuntu tools, like App Center ... And as promised in the release notes, Firefox, Chromium, and VLC are installed. And both browsers work correctly, and also play YouTube videos, with fluent sound from the monitor's speakers (with HDMI chosen as audio output in the GNOME Control Center), only the image was not very smooth, as, according to the release notes, hardware acceleration for video playback is not yet supported. VLC is crashing on playing local video files from the command line though. I got an answer on the bug report recommending mpv. I installed it and it actually works, and rather well for not having hardware acceleration. I can also do full system updates now, sudo apt update; sudo apt dist-upgrade, without making the system unbootable. Problem was not gdm but the custom 6.6.20 kernel replaced by a stock 6.8.0 kernel. This is now fixed by the kernel version being pinned, meaning that it does not get updated (according to the release notes). And now let us try printing ... So let us start easily (This command checks whether the CUPS daemon is running) : WHAT?! CUPS is not installed. A desktop system without CUPS installed. This is strange. I also wanted to have a quick look into a man page. Of df, which I have used and therefore it is for sure installed. This is interesting. A desktop system is where users do not log into? OK, let us unminimize: Lots of packages get installed, and I see also that all the printing stack packages are under them. So I try again: And CUPS is back! I also tried to print from applications, and it works! Reported an issue about this. The full Ubuntu Desktop experience Let us do and something like 300 packages get installed. So I have a lot more desktop applications and utilities, an Ubuntu-themed GNOME desktop, even with the Noble Numbat wallpaper (instead of the DeepComputing one). And for me it makes the impression that the YouTube videos in Firefox run more smoothly (more fps). Thanks a lot, DeepComputing and Framework to provide the hardware for a great RISC-V desktop. And thanks a lot, Yuning Liang, for providing the RISC-V board for OpenPrinting and for your great support to get it all working! Note: This applies only to the \"Early Access Edition\", a pre-production unit sold on conferences, like FOSDEM. As the boards sold on the DeepComputing booth on FOSDEM are pre-production units they seemed to take into account that they can still have significant bugs in their EC firmware, and probably therefore the kits came with a firmware flashing tool, which I actually had to use. Already during the first boot at the Ubuntu booth we found out that we could not interact with the boot menu of GRUB by the (USB) keyboard and the only way to get the board booting was to wait for the too long timeout to expire. Once it is a little bit annoying and second, if the machine would not boot one cannot resort to use an older kernel. In the beginning I did not realize that the material coming with the board was a firmware flashing tool, but as, in reaction to my bug report about the USB keyboard only working in the desktop I got a firmware update and instructions how to apply it with my tool in a mail from DeepComputing's support, and I got aware that I got this tool and appreciated that I could fix the board with it. After having applied the EC firmware update all my USB keyboards were working, a wired one with built-in USB hub and wireless Logitech keyboard using Logitech's Universal Receiver. Note: For anybody reading this and wanting to update the EC firmware, too. Please have a look into my comment on the bug report about using the newer STM32Cube flashing software which is also available for Linux. Thanks a lot, DeepComputing and Yuning Liang, for including the updating tool with the kit! The standard Ubuntu Desktop makes more and more use of the Snap package format to assure continuous updates from upstream also after the Ubuntu release and also enhanced security for common desktop applications, especially Firefox, Chromium, and Thunderbird. So I had also a look into this on the RISC-V system. The first note I got about Snap and the RISC-V board was a post by Zygmunt Krynicki on Mastodon in a long Mastodon thread where he tells that the kernel of the system which came with the does not support Snap and his GitHub issue report telling that it is because the kernel does not include squashfs support. squashfs is the immutable, compressed file system which is used by Snaps. The kernel issue got fixed with the Ubuntu 24.04 V1.1 image, but snapd was not installed, and Firefox and Chromium were installed as standard Debian packages. So I tried to install snapd, snapcraft, and rockcraft and it worked: and then I ran That is what is expected. But this was all. I tried to find some Snaps built for RISC-V in the Snap Store but did not find anything. It seems that I will soon try to make a start by building the OpenPrinting Snaps (CUPS, ipp-usb, Printer Applications) and then let the Snap Store build them , too. Thanks a lot, Zygmunt, for reporting the Snap problem! A few steps to a great desktop setup on a RISC-V-based Framework laptop or the RISC-V board in a standalone case: Install the Ubuntu 24.04 V1.1 image (or newer if available) following these instructions. Boot and go through the first-time wizard Unminimize your system with the commands: Update your system Get the full Ubuntu desktop Install the mpv video player for local video files Set mpv as default video player in the GNOME Control Center (\"Apps\", \"Default Apps\"). If you use a standalone case and not a Framework laptop, set audio output to \"HDMI\" or connect a USB audio output device and point the audio output to that one. Use the quick menu of GNOME or the \"Sound\" section of GNOME Control Center. If the sound test function does not work, do not worry, test with any sound-producing app. If you want to be able to install Snap packages, install snapd: If you want to create Snap packages or port exisiting ones to RISC-V, install snapcraft: Now things should work as with a usual Ubuntu desktop. DeepComputing Framework Issue tracker for DeepComputing/Framework RISC-V board Mastodon thread about the RISC-V board and my and Zygmunt Krynicki's experience with it And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-News-Windows-Protected-Print-vs.-Scanning-under-Windows",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting News - Windows Protected Print vs. Scanning under Windows",
+ "url": "/OpenPrinting-News-Windows-Protected-Print-vs.-Scanning-under-Windows",
+ "headings": [],
+ "tags": [],
+ "snippet": "Windows Protected Print protects you from scanning",
+ "content": "Around a year ago I reported here about Microsoft's plans to make printing under Windows more secure, going the same way as we are going with the New Architecture in CUPS 3.x, an all-IPP print environment without printer drivers, only supporting modern, driverless IPP printers. In Windows it is especially important to get rid of printer drivers, as they are closed-source code pieces running in system or even kernel level. For Windows Protected Print (WPP) Windows does not use CUPS, but Mopria instead, and they do not have a concept for non-driverless legacy printers, whereas we have the Printer Applications (which can also be used under Windows). Microsoft's plans were reported about in a blog on Microsoft's community forum, where I also left some comments. Now, some weeks ago, I read new comments there where many users complained that with the 24H2 update of Windows 11, which introduced Windows Protected Print, scanning on the multi-function printers ceased to work, while printing is working. Modern multi-function devices which do driverless IPP printing also do driverless scanning, using at least one of the standard protocols eSCL or WSD, but it seems that Microsoft did not take care of that when implementing Windows Protected Print. Also on The Register got reported that with the update 24H2 of Windows 11 several users of Canon multi-function printers reported scanning not to work any more, despite Microsoft already having issued fixes. Microsoft promised to fix the bug by end-January, but they already left their users without scanning working for many weeks. But for the seasoned WSL tinkerer (Warning: Command line use required!) it should be solvable. Proceed as described here for legacy printers, but instead of (or in addition to) installing a Printer Application, install SANE (Scanner Access Now Easy): and then use the scanimage command. Enter man scanimage for how to use it. I hope this makes Windows 11 SANE for the time being. We will soon have Scanner Applications which emulate driverless scanners (eSCL, WSD), but note that current Windows has especially problems with those. And as usual: Stay updated on Mastodon: #OpenPrinting and @till@ubuntu.social. Or discuss on our mailing lists: Development: printing-architecture AT lists DOT linux DOT dev (Archive) Users: printing-users AT lists DOT linux DOT dev (Archive) Subscribing/Unsubscribing instructions Or on the Telegram OpenPrinting chat"
+ },
+ {
+ "id": "post:OpenPrinting-Summit-PWG-Meeting-2020-approaching",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting Summit/PWG Meeting 2020 approaching!",
+ "url": "/OpenPrinting-Summit-PWG-Meeting-2020-approaching",
+ "headings": [],
+ "tags": [],
+ "snippet": "The virtual OpenPrinting Summit/PWG Meeting will take place this week, from Tuesday, May 5 to Friday, May 8, Tuesday is OpenPrinting day",
+ "content": "On Tuesday our annual meeting will start again. During 4 days we will discuss, together with the Printer Working Group (PWG), our plans how we will continue the development printing (and scanning) with free software on Linux and similar operating systems and also about free printing-related standards, especially the Internet Printing Protocol (IPP). The OpenPrinting-related part is the first day (Tue, May 5). See the agenda. Due to COVID-19 we will not meet in person, but have a virtual meeting, using WebEx. The agenda was modified to make the individual meeting days shorter, adding a forth day. Everyone can participate, we do not discuss anything secret or proprietary. There is also no registration nor any conference fees needed. Simply have a look on the agenda and logistics page. Slides of all presentations are linked there, too, at latest before the appropriate presentation starts. To participate in the WebEx meeting, please e-mail to the PWG chair at any time before or during the meeting, and visit the WebEx meeting page."
+ },
+ {
+ "id": "post:OpenPrinting-mentoring-on-the-Google-Summer-of-Code-2020",
+ "source": "static",
+ "type": "post",
+ "title": "OpenPrinting mentoring on the Google Summer of Code 2020!",
+ "url": "/OpenPrinting-mentoring-on-the-Google-Summer-of-Code-2020",
+ "headings": [],
+ "tags": [],
+ "snippet": "The Linux Foundation got accepted as a mentoring organization for the GSoC 2020 and OpenPrinting as one of its sub-organizations will offer a wide variety of student projects again",
+ "content": "The Linux Foundation got accepted as a mentoring organization for the GSoC 2020 and OpenPrinting as one of its sub-organizations will offer a wide variety of student projects again. This year our main subject is the Internet Printing Protocol (IPP). The students will implement the standards for driverless IPP scanning (driverless printing already works), IPP System Service (the printer setup tool of the future), Printer and Scanner Applications for providing drivers in the Snap Store, and more printing-related projects. Each project consists of three months of coding from mid-May to mid-August. Students who want to participate, please see the general GSoC info of the Linux Foundation and our project idea list. See also Google's timeline. Once you have found your preferred project idea(s) or you have your own idea, please contact the mentors mentioned in the idea listing or the organization admins as soon as possible. We will then introduce you to the work of OpenPrinting. Please do not wait for the start of Google's student application period."
+ },
+ {
+ "id": "post:PostScript-Printer-Application",
+ "source": "static",
+ "type": "post",
+ "title": "PostScript Printer Application",
+ "url": "/PostScript-Printer-Application",
+ "headings": [
+ "PostScript Printer Application"
+ ],
+ "tags": [],
+ "snippet": "The PostScript Printer Application, first PAPPL-based non-Raster Printer Application, retro-fitting PPD files",
+ "content": "After having all needed filter functions and PPD file collection handling implemented in cups-filters and having the HP PCL Printer Application as example I have created a Printer Application for PostScript printers. It is now available as the ps-printer-app repository on the OpenPrinting GitHub. Currently it is a first working model, it will get much more functionality, especially for best user experience, added in the near future. See all the details of properties, planned features, known issues, and how to use in the README.md file. This Printer Application is especially a working model for A non-raster Printer Application: Destination format is PostScript, a high-level/vector format. Input data in PostScript or PDF is accepted and needed conversion is not done through an inbetween raster step. A Printer Application which uses the new filter functions of cups-filters 2.x. Filter functions are library functions derived from cups-filters and contain decades of development and refinement starting from the introduction of CUPS in 2000. A retro-fit Printer Application for classic CUPS drivers, in this case the simplest form of only PPD files for PostScript printers. It lists PPD files from repositories included in the Snap, loads the PPD needed for the actual printer, extracts options from the PPD to display them in the web interface, accepts job settings as IPP attributes, and inserts the PostScript code provided by the PPD correctly into the output data stream. A Printer Application which does not pass through raw (input format is printer's native format) jobs. To assure that always the PostScript code of the PPD file is inserted into the output stream, we call the printer's native format \"application/vnd.printer-specific\" which does not exist as input format, so \"application/postscript\" input is forced through the pstops() filter function. To do not need to re-invent the code for forking into sub-processes so that we can pass data through a sequence of filters, we create a filter function to send the data off to the printer and form a chain of the actually converting filter function (one of pstops(), pdftops(), imagetops(), rastertops()) and the with this filter function using the filterChain() filter function. The PostScript Printer Application has all PostScript PPD files of the foomatic-db and HPLIP projects built-in, so most PostScript printer PPDs which usually come with Linux Distributions. Note that some PPDs use certain CUPS filters for extra functionality. These filters are not included. The user can add additional PPDs without needing to rebuild the Snap."
+ },
+ {
+ "id": "post:cups-2.3.3op1",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.3.3op1",
+ "url": "/cups-2.3.3op1",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.3.3op1 is the first OpenPrinting CUPS release which fixes many bugs, incorporates common Linux distribution changes, and provides several IPP Everywhere improvements.",
+ "content": "CUPS 2.3.3op1 is the first OpenPrinting CUPS release which fixes many bugs, incorporates common Linux distribution changes, and provides several IPP Everywhere improvements. Download v2.3.3op1 Changes include: The automated test suite can now be activated using make test for consistency with other projects and CI environments - the old make check continues to work as well, and the previous test server behavior can be accessed by running make testserver. ippeveprinter now supports multiple icons and strings files. ippeveprinter now uses the system's FQDN with Avahi. ippeveprinter now supports Get-Printer-Attributes on \"/\". ippeveprinter now uses a deterministic \"printer-uuid\" value. ippeveprinter now uses system sounds on macOS for Identify-Printer. Updated ippfind to look for files in \"~/Desktop\" on Windows. Updated ippfind to honor SKIP-XXX directives with PAUSE. Updated IPP Everywhere support to work around printers that only advertise color raster support but really also support grayscale (Issue #1) ipptool now supports DNS-SD URIs like ipps://My%20Printer._ipps._tcp.local (Issue #5) The scheduler now allows root backends to have world read permissions but not world execute permissions (Issue #21) Failures to bind IPv6 listener sockets no longer cause errors if IPv6 is disabled on the host (Issue #25) The SNMP backend now supports the HP and Ricoh vendor MIBs (Issue #28) The scheduler no longer includes a timestamp in files it writes (Issue #29) The systemd service names are now \"cups.service\" and \"cups-lpd.service\" (Issue #30, Issue #31) The scheduler no longer adds the local hostname to the ServerAlias list (Issue #32) Added LogFileGroup directive in \"cups-files.conf\" to control the group owner of log files (Issue #34) Added --with-max-log-size configure option (Issue #35) Added --enable-sync-on-close configure option (Issue #37) Added --with-error-policy configure option (Issue #38) IPP Everywhere PPDs could have an \"unknown\" default InputSlot (Issue #44) The httpAddrListen function now uses a listen backlog of 128. Added USB quirks (Apple issue #5789, #5823, #5831) Fixed IPP Everywhere v1.1 conformance issues in ippeveprinter. Fixed DNS-SD name collision support in ippeveprinter. Fixed compiler and code analyzer warnings. Fixed TLS support on Windows. Fixed ippfind sub-type searches with Avahi. Fixed the default hostname used by ippeveprinter on macOS. Fixed resolution of local IPP-USB printers with Avahi. Fixed coverity issues (Issue #2) Fixed httpAddrConnect issues (Issue #3) Fixed web interface device URI issue (Issue #4) Fixed lp/lpr \"printer/class not found\" error reporting (Issue #6) Fixed xinetd support for LPD clients (Issue #7) Fixed libtool build issue (Issue #11) Fixed a memory leak in the scheduler (Issue #12) Fixed a potential integer overflow in the PPD hashing code (Issue #13) Fixed output-bin and print-quality handling issues (Issue #18) Fixed PPD options getting mapped to odd IPP values like \"tray---4\" (Issue #23) Fixed remote access to the cupsd.conf and log files (Issue #24) Fixed the automated test suite when running in certain build/CI environments (Issue #25) Fixed a logging regression caused by a previous change for Apple issue #5604 (Issue #25) Fixed fax phone number handling with GNOME (Issue #40) Fixed potential rounding error in rastertopwg filter (Issue #41) Fixed the \"uri-security-supported\" value from the scheduler (Issue #42) Fixed IPP backend crash bug with \"printer-alert\" values (Issue #43) Removed old Solaris inetconv(1m) reference in cups-lpd man page (Issue #46) Fixed default options that incorrectly use the \"custom\" prefix (Issue #48) Fixed a memory leak when resolving DNS-SD URIs (Issue #49) Fixed systemd status reporting by adopting the notify interface (Issue #51) Fixed crash in rastertopwg (Apple issue #5773) Fixed cupsManualCopies values in IPP Everywhere PPDs (Apple issue #5807) Enjoy!"
+ },
+ {
+ "id": "post:cups-2.3.3op2",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.3.3op2",
+ "url": "/cups-2.3.3op2",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.3.3op2 is the latest OpenPrinting CUPS security and bug fix release.",
+ "content": "CUPS 2.3.3op2 is the latest OpenPrinting CUPS security and bug fix release. Changes include: Security: Fixed a buffer (read) overflow in the ippReadIO function (CVE-2020-10001) Clarified the documentation for the \"Listen\" directive (Issue #53) Fixed duplicate ColorModel entries for AirPrint printers (Issue 59) Fixed directory/permission defaults for Debian kfreebsd-based systems (Issue #60, Issue #61) Fixed crash bug in ppdOpen (Issue #64, Issue #78) Fixed regression in snprintf emulation function (Issue #67) The scheduler's systemd service file now waits for the nslcd service to start (Issue #69) The libusb-based USB backend now uses a simpler read timer implementation to avoid a regression in a previous change (Issue #72) The PPD caching code now only tracks the APPrinterIconPath value on macOS (Issue #73) Fixed segfault in help.cgi when searching in man pages (Issue #81) Root certificates were incorrectly stored in \"~/.cups/ssl\". Enjoy! Download v2.3.3op2"
+ },
+ {
+ "id": "post:cups-2.4.0",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.0",
+ "url": "/cups-2.4.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.0 is the latest stable OpenPrinting CUPS release. Among the changes from beta and release candidate the stable release adds two new configuration options for optimizing cupsd setup on servers and several other changes.",
+ "content": "CUPS 2.4.0 is the latest stable OpenPrinting CUPS release. Among the changes from beta and release candidate the stable release adds two new configuration options for optimizing cupsd setup on servers and several other changes. The detailed list of changes: Added configure option --with-idle-exit-timeout (Issue #294) Added --with-systemd-timeoutstartsec configure option (Issue #298) DigestOptions now are applied for MD5 Digest authentication defined by RFC 2069 as well (Issue #287) Fixed compilation on Solaris (Issue #293) Fixed and improved German translations (Issue #296, Issue #297) Enjoy! :)"
+ },
+ {
+ "id": "post:cups-2.4.1",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.1",
+ "url": "/cups-2.4.1",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.1 is the first bug fix release from 2.4.x series. Among the other bug fixes it fixes sharing default color mode to clients and several memory leaks.",
+ "content": "CUPS 2.4.1 is the first bug fix release from 2.4.x series. Among the other bug fixes it fixes sharing default color mode to clients and several memory leaks. Detailed list of changes: The default color mode now is now configurable and defaults to the printer's reported default mode (Issue #277) Configuration script now checks linking for -Wl,-pie flags (Issue #303) Fixed memory leaks - in testi18n (Issue #313), in cups_enum_dests() (Issue #317), in _cupsEncodeOption() and http_tls_upgrade() (Issue #322) Fixed missing bracket in de/index.html (Issue #299) Fixed typos in configuration scripts (Issues #304, #316) Removed remaining legacy code for RIP_MAX_CACHE environment variable (Issue #323) Removed deprecated directives from cupsctl and cups-files.conf (Issue #300) Removed purge-jobs legacy code from CGI scripts and templates (Issue #325) Enjoy! :)"
+ },
+ {
+ "id": "post:cups-2.4.10",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.10",
+ "url": "/cups-2.4.10",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.10 fixes regression for domain socket-only setups",
+ "content": "CUPS 2.4.10 brings two fixes: Fixed error handling when reading a mixed 1setOf attribute. Fixed scheduler start if there is only domain socket to listen on (Issue #985) which the latter is fix for regression after fix for CVE-2024-35235 in scenarios where is no other listeners in cupsd.conf than domain socket created on demand by systemd, launchd or upstart. Enjoy! Download v2.4.10"
+ },
+ {
+ "id": "post:cups-2.4.11",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.11",
+ "url": "/cups-2.4.11",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.11 bring several bug fixes regarding IPP support and Web UI",
+ "content": "CUPS 2.4.11 brings several bug fixes regarding IPP response validation, processing PPD values, Web UI support (checkbox support, modifying printers) and others fixes. Detailed list of changes is available in CHANGES.md Enjoy! Download v2.4.11"
+ },
+ {
+ "id": "post:cups-2.4.12",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.12",
+ "url": "/cups-2.4.12",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.12 brings enhancements in IPP encryption and debugging",
+ "content": "The last planned release of CUPS 2.4.x series (the next will be 2.5.x series) contains several enhancements among set of bug fixes, such following cryptographic policies when using GnuTLS crypto provider and possibility to opt-out from this behavior, logging job debugging history if print queue backends fails, or raising alerts for certificate issues in IPPS backend. The detailed list of changes is available in CHANGES.md. Enjoy the new release! Download v2.4.12"
+ },
+ {
+ "id": "post:cups-2.4.13",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.13",
+ "url": "/cups-2.4.13",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.13 fixes important and moderate vulnerabilities",
+ "content": "The release 2.4.13 brings two CVE fixes - fix for important CVE-2025-58060 and fix for moderate CVE-2025-58364, together with several bug fixes. The release includes a new feature - new attribute for printer and job objects - print-as-raster - which allows enforce rasterization of the file for IPP Everywhere/AirPrint printers, which supports PDF and raster document formats. The feature is useful for working around internal PDF issues in the printer firmware, for example missing diacritic when printing a PDF. The detailed list of changes is available in CHANGES.md. Enjoy the release! Download v2.4.13"
+ },
+ {
+ "id": "post:cups-2.4.14",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.14",
+ "url": "/cups-2.4.14",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.14 fixes installation of localized files",
+ "content": "The hotfix release brings fix for installation process of localized templates and CUPS web UI home pages. Enjoy! Download v2.4.14"
+ },
+ {
+ "id": "post:cups-2.4.15",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.15",
+ "url": "/cups-2.4.15",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.15 fixes two CVEs in scheduler",
+ "content": "The release CUPS 2.4.15 brings two CVE fixes: Fix various cupsd issues which cause local DoS (CVE-2025-61915) Fix unresponsive cupsd process caused by slow client (CVE-2025-58436) and several bug fixes described in CHANGES.md. Enjoy! Download v2.4.15"
+ },
+ {
+ "id": "post:cups-2.4.16",
+ "source": "static",
+ "type": "post",
+ "title": "Untitled Article",
+ "url": "/cups-2.4.16",
+ "headings": [
+ "title: CUPS 2.4.16\nlayout: single\nauthor: Zdenek\nexcerpt: CUPS 2.4.16 hot fix release is available\ndate: '2025-12-04'"
+ ],
+ "tags": [],
+ "snippet": "The hotfix release 2.4.16 includes fix for infinite loop in GTK, which was caused by change of internal behavior in libcups on which GTK depended on, and workaround for stopping...",
+ "content": "The hotfix release 2.4.16 includes fix for infinite loop in GTK, which was caused by change of internal behavior in libcups on which GTK depended on, and workaround for stopping the scheduler if configuration includes unknown directives. The full list of changes is shown in CHANGES.md. Enjoy! Download v2.4.16"
+ },
+ {
+ "id": "post:cups-2.4.2",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.2",
+ "url": "/cups-2.4.2",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.2 brings the fix for CVE-2022-26691, LibreSSL/OpenSSL and minimal AIX support together with a list of bug fixes",
+ "content": "CUPS 2.4.2 brings the fix for CVE-2022-26691, together with LibreSSL/OpenSSL and minimal AIX support. There are lots of bug fixes as well, feel free to check the list of changes: Fixed certificate strings comparison for Local authorization (CVE-2022-26691) The cupsFileOpen function no longer opens files for append in read-write mode (Issue #291) The cupsd daemon removed processing temporary queue (Issue #364) Fixed delay in IPP backend if GNUTLS is used and endpoint doesn't confirm closing the connection (Issue #365) Fixed conditional jump based on uninitialized value in cups/ppd.c (Issue #329) 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) The lpstat command now reports when the scheduler is not running (Issue #352) Updated the man pages concerning the -h option (Issue #357) Re-added LibreSSL/OpenSSL support (Issue #362) Updated the Solaris smf service file (Issue #368) Fixed a regression in lpoptions option support (Issue #370) The scheduler now regenerates the PPD cache information after changing the \"cupsd.conf\" file (Issue #371) Updated the scheduler to set \"auth-info-required\" to \"username,password\" if a backend reports it needs authentication info but doesn't set a method for authentication (Issue #373) Updated the configure script to look for the OpenSSL library the old way if pkg-config is not available (Issue #375) Fixed the prototype for the httpWriteResponse function (Issue #380) Brought back minimal AIX support (Issue #389) cupsGetResponse did not always set the last error. Fixed a number of old references to the Apple CUPS web page. Restored the default/generic printer icon file for the web interface. Removed old stylesheet classes that are no longer used by the web interface. Enjoy the new CUPS release!"
+ },
+ {
+ "id": "post:cups-2.4.3",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.3",
+ "url": "/cups-2.4.3",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.3 brings the fix for CVE-2023-32324, several improvements and a ton of bug fixes",
+ "content": "CUPS 2.4.3 brings fix for CVE-2023-32324, several improvements and many bug fixes. CUPS now implements fallback for printers with broken firmware, which is not capable of answering to IPP request get-printer-attributes with all, media-col-database - this enables driverless support for bunch of printers which don't follow IPP Everywhere standard. Aside from the CVE fix the most important fixes are around color settings, printer application support fixes and OpenSSL support. Detailed list of changes: Added a title with device uri for found network printers (Issues #402, #393) Added new media sizes defined by IANA (Issues #501) Added quirk for GoDEX label printers (Issue #440) Fixed --enable-libtool-unsupported (Issue #394) Fixed configuration on RISC-V machines (Issue #404) Fixed the device_uri invalid pointer for driverless printers with .local hostname (Issue #419) Fixed an OpenSSL crash bug (Issue #409) Fixed a potential SNMP OID value overflow issue (Issue #431) Fixed an OpenSSL certificate loading issue (Issue #465) Fixed Brazilian Portuguese translations (Issue #288) Fixed cupsd default keychain location when building with OpenSSL (Issue #529) Fixed default color settings for CMYK printers as well (Issue #500) Fixed duplicate PPD2IPP media-type names (Issue #688) Fixed possible heap buffer overflow in _cups_strlcpy() (fixes CVE-2023-32324) Fixed InputSlot heuristic for photo sizes smaller than 5x7\" if there is no media-source in the request (Issue #569) Fixed invalid memory access during generating IPP Everywhere queue (Issue #466) Fixed lprm if no destination is provided (Issue #457) Fixed memory leaks in create_local_bg_thread() (Issue #466) Fixed media size tolerance in ippeveprinter (Issue #487) Fixed passing command name without path into ippeveprinter (Issue #629) Fixed saving strings file path in printers.conf (Issue #710) Fixed TLS certificate generation bugs (Issue #652) ippDeleteValues would not delete the last value (Issue #556) Ignore some of IPP defaults if the application sends its PPD alternative (Issue #484) Make Letter the default size in ippevepcl (Issue #543) Now accessing Admin page in Web UI requires authentication (Issue #518) Now look for default printer on network if needed (Issue #452) Now we poll media-col-database separately if we fail at first (Issue #599) Now report fax attributes and values as needed (Issue #459) Now localize HTTP responses using the Content-Language value (Issue #426) Raised file size limit for importing PPD via Web UI (Issue #433) Raised maximum listen backlog size to INT MAX (Issue #626) Update print-color-mode if the printer is modified via ColorModel PPD option (Issue #451) Use localhost when printing via printer application (Issue #353) Write defaults into /etc/cups/lpoptions if we're root (Issue #456) Enjoy! :)"
+ },
+ {
+ "id": "post:cups-2.4.4",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.4",
+ "url": "/cups-2.4.4",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.4 brings hotfix for cupsGetNamedDest() segfault",
+ "content": "CUPS 2.4.4 release is created as a hotfix for segfault in cupsGetNamedDest(), when caller tries to find the default destination and the default destination is not set on the machine (Issue #719). I'm sorry for inconvenience and enjoy the hotfix! Download v2.4.4"
+ },
+ {
+ "id": "post:cups-2.4.5",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.5",
+ "url": "/cups-2.4.5",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.5 brings hotfix for corrupted locally saved certificates",
+ "content": "CUPS 2.4.5 is a hotfix release for a bug which corrupted locally saved certificates, which broke secured printing via TLS after the first print job. We're sorry for the inconvenience and enjoy the hotfix! Download v2.4.5"
+ },
+ {
+ "id": "post:cups-2.4.6",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.6",
+ "url": "/cups-2.4.6",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.6 brings fix for CVE-2023-34241",
+ "content": "CUPS 2.4.6 is released to ship the fix for the latest CVE - CVE-2023-34241 - and two other bug fixes. Detailed list: Fix linking error on old MacOS (Issue #715) Fix printing multiple files on specific printers (Issue #643) Fix use-after-free when logging warnings in case of failures in cupsdAcceptClient() (fixes CVE-2023-34241) Enjoy! Download v2.4.6"
+ },
+ {
+ "id": "post:cups-2.4.7",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.7",
+ "url": "/cups-2.4.7",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.7 brings fix for CVE-2023-4504 and other fixes",
+ "content": "CUPS 2.4.7 is released to ship the fix for CVE-2023-4504 and several other changes, among them it is adding OpenSSL support for cupsHashData function and bug fixes. Detailed list: CVE-2023-4504 - Fixed Heap-based buffer overflow when reading Postscript in PPD files Added OpenSSL support for cupsHashData (Issue #762) Fixed delays in lpd backend (Issue #741) Fixed extensive logging in scheduler (Issue #604) Fixed hanging of lpstat on IBM AIX (Issue #773) Fixed hanging of lpstat on Solaris (Issue #156) Fixed printing to stderr if we can't open cups-files.conf (Issue #777) Fixed purging job files via cancel -x (Issue #742) Fixed RFC 1179 port reserving behavior in LPD backend (Issue #743) Fixed a bug in the PPD command interpretation code (Issue #768) Enjoy the new release! Download v2.4.7"
+ },
+ {
+ "id": "post:cups-2.4.8",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.8",
+ "url": "/cups-2.4.8",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.8 brings important bug fix for permanent IPP Everywhere printer installation",
+ "content": "CUPS 2.4.8 brings many bug fixes which aggregated over the last half a year. It brings the important fix for race conditions and errors which can happen when installing permanent IPP Everywhere printer, support for PAM modules password-auth and system-auth and new option for lpstat which can show only the successful jobs. Detailed list of changes is available in CHANGES.md. Enjoy! Download v2.4.8"
+ },
+ {
+ "id": "post:cups-2.4.9",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4.9",
+ "url": "/cups-2.4.9",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4.9 brings security fix for CVE-2024-35235",
+ "content": "CUPS 2.4.9 brings security fix for CVE-2024-35235 and several bug fixes regarding CUPS Web User Interface, PPD generation and HTTP protocol implementation. Detailed list of changes is available in CHANGES.md. Enjoy! Download v2.4.9"
+ },
+ {
+ "id": "post:cups-2.4b1",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4b1",
+ "url": "/cups-2.4b1",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS v2.4b1 is the beta release for OpenPrinting CUPS 2.4 which contains new features, deprecations, removals and bugfixes.",
+ "content": "CUPS 2.4b1 is the beta release for OpenPrinting CUPS 2.4 which contains several new features such as basic OAuth support, support for AirPrint and Mopria clients and support for running CUPS as a snap, several deprecations (Kerberos, cups-config), removals of old deprecated directives, and many bug fixes. The detailed list of changes: Added support for CUPS running in a Snapcraft snap. Added basic OAuth 2.0 client support (Issue #100) Added support for AirPrint and Mopria clients (Issue #105) Added configure support for specifying systemd dependencies in the CUPS service file (Issue #144) Added several features and improvements to ipptool (Issue #153) Added a JSON output mode for ipptool. The ipptool command now correctly reports an error when a test file cannot be found. CUPS library now uses thread safe getpwnam_r and getpwuid_r functions (Issue #274) Fixed Kerberos authentication for the web interface (Issue #19) The ZPL sample driver now supports more \"standard\" label sizes (Issue #70) Fixed reporting of printer instances when enumerating and when no options are set for the main instance (Issue #71) Reverted USB read limit enforcement change from CUPS 2.2.12 (Issue #72) The IPP backend did not return the correct status code when a job was canceled at the printer/server (Issue #74) The testlang unit test program now loops over all of the available locales by default (Issue #85) The cupsfilter command now shows error messages when options are used incorrectly (Issue #88) The PPD functions now treat boolean values as case-insensitive (Issue #106) Temporary queue names no longer end with an underscore (Issue #110) The USB backend now runs as root (Issue #121) Added pkg-config file for libcups (Issue #122) Fixed a PPD memory leak caused by emulator definitions (Issue #124) Fixed a DISPLAY bug in ipptool (Issue #139) The scheduler now includes the [Job N] prefix for job log messages, even when using syslog logging (Issue #154) Added support for locales using the GB18030 character set (Issue #159) httpReconnect2 did not reset the socket file descriptor when the TLS negotiation failed (Apple #5907) httpUpdate did not reset the socket file descriptor when the TLS negotiation failed (Apple #5915) The IPP backend now retries Validate-Job requests (Issue #132) Now show better error messages when a driver interface program fails to provide a PPD file (Issue #148) Added dark mode support to the CUPS web interface (Issue #152) Added a workaround for Solaris in httpAddrConnect2 (Issue #156) Fixed an interaction between --remote-admin and --remote-any for the cupsctl command (Issue #158) Now use a 60 second timeout for reading USB backchannel data (Issue #160) The USB backend now tries harder to find a serial number (Issue #170) Fixed @IF(name) handling in cupsd.conf (Apple #5918) Fixed documentation and added examples for CUPS' limited CGI support (Apple #5940) Fixed the lpc command prompt (Apple #5946) Now always pass \"localhost\" in the Host: header when talking over a domain socket or the loopback interface (Issue #185) Fixed a job history update issue in the scheduler (Issue #187) Fixed job-pages-per-set value for duplex print jobs. Fixed an edge case in ippReadIO to make sure that only complete attributes and values are retained on an error (Issue #195) Hardened ippReadIO to prevent invalid IPP messages from being propagated (Issue #195, Issue #196) The scheduler now supports the \"everywhere\" model directly (Issue #201) Fixed some IPP Everywhere option mapping problems (Issue #238) Fixed support for \"job-hold-until\" with the Restart-Job operation (Issue #250) Fixed the default color/grayscale presets for IPP Everywhere PPDs (Issue #262) Fixed support for the 'offline-report' state for all USB backends (Issue #264) Documentation fixes (Issue #92, Issue #163, Issue #177, Issue #184) Localization updates (Issue #123, Issue #129, Issue #134, Issue #146, Issue #164) USB quirk updates (Issue #192, Issue #270, Apple #5766, Apple #5838, Apple #5843, Apple #5867) Web interface updates (Issue #142, Issue #218) The ippeveprinter tool now automatically uses an available port. Fixed several Windows TLS and hashing issues. Deprecated cups-config (Issue #97) Deprecated Kerberos (AuthType Negotiate) authentication (Issue #98) Removed support for the (long deprecated and unused) FontPath, ListenBackLog, LPDConfigFile, KeepAliveTimeout, RIPCache, and SMBConfigFile directives in cupsd.conf and cups-files.conf. Stubbed out deprecated httpMD5 functions. Add test for undefined page ranges during printing. Enjoy!"
+ },
+ {
+ "id": "post:cups-2.4rc1",
+ "source": "static",
+ "type": "post",
+ "title": "CUPS 2.4rc1",
+ "url": "/cups-2.4rc1",
+ "headings": [],
+ "tags": [],
+ "snippet": "CUPS 2.4rc1 is a release candidate for OpenPrinting CUPS 2.4.0, which adds two enhancements before the stable release.",
+ "content": "CUPS 2.4rc1 is a release candidate for OpenPrinting CUPS 2.4.0, which adds two enhancements before the stable release. The detailed list of changes: Added warning and debug messages when loading printers if the queue is raw or with driver (Issue #286) Compilation now uses -fstack-protector-strong if available (Issue #285) Enjoy!"
+ },
+ {
+ "id": "post:cups-browsed-2.1.1",
+ "source": "static",
+ "type": "post",
+ "title": "cups-browsed 2.1.1",
+ "url": "/cups-browsed-2.1.1",
+ "headings": [
+ "All changes",
+ "Package"
+ ],
+ "tags": [],
+ "snippet": "Bug fix release, especially to fix the long-standing problem that cups-browsed sometimes gets stuck with 100% CPU",
+ "content": "We have issued this release as it contains a fix for a long-standing bug. Since multi-threading was introduced as a central new feature of the 2.x generation of cups-browsed users started to report that from time to time cups-browsed got stuck with 100% CPU load on 1 or 2 processor cores (Ubuntu bugs #2049315, #2067918, and #2073504). It took very long to come to the right idea what actually needed to get fixed, as the bug was not easily reproducable, sometimes it happened but often not. After having collected some tracebacks it turned out that cups-browsed always got stuck in an infinite loop in the httpGets() function of libcups. One of the reporters of the cups-browsed problem also reported an issue in CUPS. I found out that the used field of the data structure http_t for HTTP requests, which tells how many bytes in a buffer are used, has to be negative to cause the infinite loop. Reviewing the HTTP-related code in libcups I did not find a way how this can happen. http_t is even an opaque data structure, so the used field can only be changed by the CUPS library's own functions. But when I went through the code of cups-browsed I found the culprit: cups-browsed opens only one single HTTP connection to the cupsd it is working for and keeps it throughout its whole life. Only later on multi-threading got added, to do computationally intensitive tasks, CUPS queue creation and DNS-SD resolving, in parallel, and having only one HTTP connection, requests happening in parallel messed up the data structure, ending up with negative used field and cups-browsed getting stuck in an infinite loop. Now we have fixed this by creating separate HTTP connection by each function which needs one. CUPS has no problem with several client connections in parallel. We also fixed an uninitialized string buffer and a wrong use of a pointer. Do not use global HTTP connection to local CUPS cups-browsed used a simple HTTP connection to CUPS and preserved it in a global variable throughout its whole life. With the addition of multi-threading this caused race-conditions and especially cups-browsed getting stuck in a busy loop. Now we create separate HTTP connections each time we need one, to eliminate this problem (Ubuntu bugs #2049315, #2067918, and #2073504, CUPS Issue #879). Fix uninitialized make_model in create_queue() Initialized the buffer by putting a terminating zero to its beginning, also removed a wrong use of sizeof() (applying to pointer no to buffer, Issue #42). cups-browsed: More Details and Download, Discussion"
+ },
+ {
+ "id": "post:cups-browsed-Second-Generation-Forth-Beta-Release",
+ "source": "static",
+ "type": "post",
+ "title": "cups-browsed Second Generation - Forth Beta Release!",
+ "url": "/cups-browsed-Second-Generation-Forth-Beta-Release",
+ "headings": [
+ "All changes",
+ "Packages"
+ ],
+ "tags": [],
+ "snippet": "Test script, for `make check`, CI, autopkgtest, ... and several bug fixes",
+ "content": "In this forth beta we have added a test script, to give make check functionality but also for using it in the autopkgtests of debian/Ubuntu and for general CI. We also found and fixed many bugs in cups-browsed itself during the development of the script. The splitting of cups-filters into separate packages for the second generation has put the code of cups-filters into packages which are \"new\" for Ubuntu. Therefore they have to pass the process of being included in the \"Main\" part of the distro, especially as at the time when cups-filters was originally created there was not such a Main Inclusion process. One requirement are the automatic tests, a build test (make check) performed right after compiling the code by the build process of the DEB package, and an autopkgtest, performed when the package is uploaded or when a new version of another package where our package depends on is uploaded (for example upload of CUPS triggers also the autopkgtest of cups-browsed). Therefore with this release I add a test script, which serves for both build test and autopkg test. It has different modes, once it can run a private copy of CUPS and the compiled cups-browsed in the source tree, and second, it can also use the daemons which are regularly installed into the system. The script generally emulates IPP printers with the help of the ippeveprinter utility of CUPS and checks whether cups-browsed auto-creates CUPS queues for them and whether one can print a job via the cups-browsed-generated queue. cups-browsed made it into Main already, despite the Main Inclusion Request (MIR) not yet being concluded. In the course of the development of the test script cups-browsed received also some more intense testing and this revealed several bugs, including some crashers. These we have all fixed now. And to complete this release, it also contains the fixes of bugs found by a Coverity scan done at Red Hat, as it was also done with the other components of cups-filters. These bugs are typically memory leaks or potential segmentation faults. Thanks a lot, Zdenek Dohnal. Added test script for make test/make check, CI, autopkgtest, ... The script test/run-tests.sh creates emulations of IPP printers via ippeveprinter (of CUPS 2.x) and checks whether cups-browsed creates corresponding CUPS queues, whether a job to such a queue gets actually printed, and whether cups-browsed removes the queues again when the printers are shut down. implicitclass backend: If no destination got reported by cups-browsed, retry after one minute, not the standard 5 minutes of CUPS. debug_printf(): Check for need of log rotation only if log file is set and opened, to avoid a crash. on_printer_modified(): Added NULL check to avoid a crash. ipp_discoveries_add(): Ignore duplicate entries. These are most probably caused by a bug in Avahi, having certain discoveries of a printer reported twice and others not. When the printer disappears Avahi reports the disappearal of each discovery correctly, leaving the duplicate entry untreated (removing only one instance of it) and cups-browsed assumes that the printer is still there, keeping its CUPS queue. update_cups_queues(): Reset counter for pausing CUPS queue updates. Otherwise after having updated the number of queues supposed to be the maximum for one run of update_cups_queues(), cups-browsed will never update any queue again. resolve_callback()/resolver_wrapper(): New thread only when printer found We move the check which resolver event we have (found/failure) already in the main thread (resolver_wrapper()) and launch a new thread only if we have found a new printer and have to investigate whether to add a queue for it or not. resolve_callback() only initiates this investigation now. This way we do not need to pass the resolver data structure (of type AvahiServiceResolver*) into the new thread, which caused segfaults. create_remote_printer_entry(): Corrected some memory freeing when a printer data structure is deleted, but this has not caused a segfault in the recent tests. Fixed issues reported by Red Hat Coverity tool (Pull request #6) configure.ac: Change deprecated AC_PROG_LIBTOOL for LT_INIT (Pull request #5) configure.ac: cups-browsed doesn't need C++ cups-browsed: More Details and Download, Discussion"
+ },
+ {
+ "id": "post:cups-filters-1.25.12-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.25.12 released!",
+ "url": "/cups-filters-1.25.12-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, to address a bug of grayscale jobs not printed on PostScript printers when Poppler is used as PDF interpreter, to allow printing on printers which claim to accept PWG Raster but actually do not print this format, and to eliminate all compiler warnings when building the package",
+ "content": "Bug fix release, to address a bug of grayscale jobs not printed on PostScript printers when Poppler is used as PDF interpreter, to allow printing on printers which claim to accept PWG Raster but actually do not print this format, and to eliminate all compiler warnings when building the package libcupsfilters: Use the text names \"Draft\", \"Normal\", and \"High\" instead of 3, 4, and 5 as choice names for the \"cupsPrintQuality\" option as CUPS does (Issue #171). libcupsfilters: If a printer supports both Apple Raster and PWG Raster let the generated PPD use Apple Raster as there are several printers which report PWG Raster support but do not actually print PWG Raster (Pull reguest #168, Issue #171, CUPS issue #5238). cups-browsed: Fix unset location check to use DNS-SD field (Pull request #172). libcupsfilters, beh, implicitclass, foomatic-rip, imagetopdf, mupdftoraster, pdftops, sys5ippprinter, cups-browsed, driverless: Silenced all compiler warnings to make the build process of cups-filters completely free of warnings. pdftops: Fixed crash when using filter without PPD file. pdftops: If printing grayscale jobs with Ghostscript as PDF renderer, add \"-sProcessColorModel=DeviceGray\" to Ghostscript command line. pdftops: Do not use the ugly \"pdftops -level1 ...\" workaround to get grayscale PostScript output from Poppler. It leads to huge output files with Poppler's \"pdftops\" utility and does not work at all with \"pdftocairo\". Poppler itself does not support PostScript output converted to grayscale. Issue a warning with the hint to use Ghostscript or MuPDF as PDF renderer (Issue #169). libcupsfilters: In the cupsRasterParseIPPOptions() accept also \"Mono\", \"Monochrome\", and \"Gray\" as color space names. More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.25.13-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.25.13 released!",
+ "url": "/cups-filters-1.25.13-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, mainly to solve problems of cups-browsed, mainly for compatibility problems with some printers, leaks, and crashes. Also updated the PPD generator to catch up with the one of CUPS. Prefer Apple Raster instead of PWG Raster as some printers have bugs in their PWG Raster implementation.",
+ "content": "Bug fix release, mainly to solve problems of cups-browsed, mainly for compatibility problems with some printers, leaks, and crashes. Also updated the PPD generator to catch up with the one of CUPS. Prefer Apple Raster instead of PWG Raster as some printers have bugs in their PWG Raster implementation. implicitclass: When passing on the job via the \"ipp\" CUPS backend, set argv[0] to the destination printer URI (Pull request #173). cups-browsed: Added another fallback to the get-printer-attributes IPP request: Now after failing the standard request (\"all\", \"media-col-database\") with both IPP 2.0 and IPP 1.1, try simply \"all\", without \"media-col-database\" (Pull request #173). cups-browsed: Do not set printer-is-shared for remote CUPS queue when making a temporary queue permanent (Pull request #180). cups-browsed: Fix leaks of ipp_t struct and load balancing on the servers (Pull request #179). cups-browsed, implicitclass: Prioritize Apple Raster against PWG Raster when selecting the PDL for the destination printer for a job sent to a cluster, also cleaned up the PDL selector code and added PostScript support. libcupsfilters: Updated the PPD generator adding all changes of the PPD generator of CUPS: Support for \"job-account-id\", \"job-accounting-user-id\", \"job-password\", finishing options \"trim-...\" added, finishing options and \"finishing-col-database\" support synced with CUPS. libcupsfilters: In the PPD generator get the mode for handling the back sides of the sheets when printing duplex preferably from the \"urf-supported\" attribute. libcupsfilters: Fixed bug that the PPD generator did not output the \"*CloseUI: *ColorModel\" line when it did not determine a default setting for \"ColorModel\". cups-browsed: Added some missing memory allocations leading to a segfault (Issue #175). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.26.0-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.26.0 released!",
+ "url": "/cups-filters-1.26.0-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Feature release, cups-browsed and driverless utility use DNS-SD-service-name-based URIs for IPP print queues now, like CUPS does. cups-browsed handles print jobs to clusters now while it is still creating local print queues. A lot of bug fixes on cups-browsed and the driverless utility",
+ "content": "This release adds some new features to cups-browsed and to the driverless utility: Both now use DNS-SD-service-name-based URIs for IPP print queues, like CUPS does. These URis are independent of network interfaces and ports and so make providing IPP services on the local machine (Printer Applications) easier. cups-browsed creates large numbers of local queues in portions now, so that it can treat jobs to print clusters between the portions, this makes printing more reliable in large networks with many printers. In addition, a lot of bugs got fixed. cups-browsed: When generating local queues for printers for which the local CUPS daemon would provide temporary queues use the PPDs generated by libcupsfilters and not the ones generated by CUPS. The PPD generation of libcupsfilters also works with IPP-1.x-only printers, printers which do not support to query \"media-col-database\" and printers which support driverless printing only via PCLm. This can be changed via the \"UseCUPSGeneratedPPDs\" directive in cups-browsed.conf (Issue #22). libcupsfilters: Re-structured the get_printer_attributes() function to remove the recursive calls for the fallbacks, to check required attributes in the response only if requested, and to fully integrate the method of getting a suitable response for a full printer capability list also if the printer is only IPP 1.1 or does not support the \"media-col-database\" attribute (Issue #22, Issue #163). libcupsfilters, cups-browsed, driverless: Moved the funtions get_printer_attributes() and resolve_uri() from cups-browsed into libcupsfilters, to share them with the driverless utility (Issue #22). implicitclass: Fixed wrong stdout redirection from the filters to the IPP backend and hard-coded path for \"ipp\" backend call (Possible fix for Issue #163, Issue #181). cups-browsed, driverless: Use DNS-SD-service-name-based URIs instead of host-name-based ones, as CUPS also does. In cups-browsed one can switch back to the conventional host-name-based URIs via the new \"DNSSDBasedDeviceURIs\" configuration option. Note that cups-browsed always uses conventional URIs for printers discovered via legacy CUPS browsing or LDAP. cups-browsed: When removing a CUPS queue, do not consider an error (and retry) if the queue does not actually exist. Also ignore errors when checking whether there are still jobs. This way when a new queue gets created and the generation of the PPD file fails the attempt to remove this non-existing queueu when removing the printer entry does not cause any problem. cups-browsed: Improved the fallback mechanism of the get_printer_attributes() function. Instead of considering the request failed by the content of the response only when not more than the two language atrributes come out, we check through a list of required attributes whether they are all there. In addition, we actually fail when all callbacks have failed (Issue #22). cups-browsed: Introduced new configuration options \"UpdateCUPSQueuesMaxPerCall\" and \"PauseBetweenCUPSQueueUpdates\" to limit the amount of local CUPS queues created, modified, or removed in a single event callback. Before, when there were thousands of printers in the network, cups-browsed got blocked for other tasks, like assigning a destination printer for a cluster print job (Issue #163). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.26.1-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.26.1 released!",
+ "url": "/cups-filters-1.26.1-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, to make the cups-browsed-generated local print queues actually work on all OS distributions and to get legacy (not actually designed for driverless IPP) printers better working",
+ "content": "Bug fix release, to make the cups-browsed-generated local print queues actually work on all OS distributions and to get legacy (not actually designed for driverless IPP) printers better working build system: Install the \"implicitclass\" backend with -rwx------ permissions, so that CUPS executes it as root, as the \"ipp\" CUPS backend also has to be executed as root (Issue #183). build system: Fixed setting permissions when installing the \"cups-brf\" backend. libcupsfilters: When using the \"media-{bottom,left,right,top}-margin-supported\" IPP attributes (needed if we have no \"media-col-database\"), use the minimum and not the maximum margins, this allows accessing more of the printer's capabilities, especially for legacy printers which do not provide sufficient information (Issue #22). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.26.2-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.26.2 released!",
+ "url": "/cups-filters-1.26.2-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release mainly to make cups-browsed correctly working with a CUPS daemon on a non-standard port, and also for cups-filters smoothly building with GCC 10",
+ "content": "Bug fix release mainly to make cups-browsed correctly working with a CUPS daemon on a non-standard port, and also for cups-filters smoothly building with GCC 10 cups-browsed: Added crash guards to avoid crashes in case the dummy printer entry for a deleted master entry is used. cups-browsed: Set the port of the local CUPS daemon to be used according to the IPP_PORT environment variable. cups-browsed: Eliminated the use of the cupsGetPPD2() function of libcups completely, also the remaining calls in the record_printer_options() and update_cups_queues() functions, the former causing incomplete recording of option settings and the latter use of CUPS-generated PPDs not working when CUPS is running on a non-standard port. cups-browsed: Eliminated the use of the cupsGetPPD2() function of libcups in queue_overwritten(). The function actually loads the queue's PPD file if the queue is on a local CUPS on port 631. Due to a bug the function fails if an alternative port is used. This lets queue_overwritten() always assume that the PPD got removed and therefore the queue got overwritten. So queues got released from cups-browsed if it was printed on them or if they were supposed to be removed on shutdown. foomatic-rip: Fixed compilation with -fno-common. Starting from the upcoming GCC 10, the default of the -fcommon option will change to -fno-common. This causes compilation errors in foomatic-rip due to missing \"external\" declarations (Pull request #184). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.27.0-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.27.0 released!",
+ "url": "/cups-filters-1.27.0-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "In this release cups-browsed does not need to know the port number of the CUPS daemon it is attached to any more when it connects via domain socket and many additional filters support zero-page jobs now",
+ "content": "In this release cups-browsed does not need to know the port number of the CUPS daemon it is attached to any more when it connects via domain socket and many additional filters support zero-page jobs now cups-browsed: Eliminate the use of the local CUPS daemon's (the CUPS we are attached to) port number completely, so that for attaching to an arbitrary local CUPS daemon listening on an arbitrary port (or even not listening on localhost at all) it is enough to tell cups-browsed the domain socket the CUPS daemon is listening on. cups-browsed, libcupsfilters: Identify DNS-SD-reported printers as of the local CUPS daemon via UUID and not via the port on which the local CUPS is listening, as we do not always have this port available. cups-browsed: Leave the port for legacy CUPS browsing and broadcasting on 631, do not use a possible alternative port of the CUPS we are attached to. The legacy CUPS servers we communicate with are always remote ones. libcupsfilters: in the PPD generator prioritize print-color-mode-supported against pwg-raster-document-type-supported (Issue #186, Pull request #188) rastertopdf, rastertops, texttopdf, pdftoraster, mupdftoraster: Handle zero page jobs, corrections on zero-page job handling (Issue #117) cups-browsed: When restarting after a crash make sure that local queue names have same upper/lower case as before. cups-browsed: Small code improvements to reduce crash probability. More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.27.1-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.27.1 released!",
+ "url": "/cups-filters-1.27.1-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release - All filters support zero-page jobs now, option and choice names in PPDs are changed to work around a bug in CUPS when generating IPP attributes, cups-browsed creates queues for all emote IPP printers by default, and several smaller fixes in the filters",
+ "content": "Bug fix release: All filters support zero-page jobs now, option and choice names in PPDs are changed to work around a bug in CUPS when generating IPP attributes, cups-browsed creates queues for all emote IPP printers by default, and several smaller fixes in the filters libcupsfilters: Let the PPD generator not put any dashes into the PPD option and choice names when translating them from IPP attribute names, to avoid that on the back-translation by CUPS no double-dashes are generated. This broke paper tray selections with tray names like \"tray-1\", \"tray-2\", ... (Issue #192, Issue #201, Debian bug #949315). foomatic-rip: Fixed segfault when PRINTER environment variable is not supplied. pdftopdf, pdftops, gstoraster, gstopdf, gstopxl, rastertoescpx, rastertopclx, foomatic-rip: Handle zero-page jobs (Issue #117, Pull request #196, Pull request #197, Pull request #198, Pull request #200). texttopdf: Added support for CJK (double-width) fonts (Issue #135, Pull request #199). cups-browsed: Switched default for \"CreateIPPPrinterQueues\" from \"local-only\" to \"All\". The configure script options \"--enable-auto-setup-local-only\" and \"--enable-auto-setup-driverless-only\" can be used to change this default (Debian bug #921252). rastertoescpx: Fixed wrong freeing of a buffer. pdftops: Added options \"crop-to-fit\" and \"fill\" to the pdftopdf options which the pstops called by pdftops should not apply a second time. pdftops: Added missing \"-sstdout=%stderr\" to Ghostscript command line, to assure that all messages are redirected to stderr and do not mix up with the output data. More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.27.2-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.27.2 released!",
+ "url": "/cups-filters-1.27.2-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, mainly to fix regressions cause by the zero-page-job-support implementation in foomatic-rip, also some code improvements in foomatic-rip and some crasher fixes in cups-browsed",
+ "content": "Bug fix release, mainly to fix regressions cause by the zero-page-job-support implementation in foomatic-rip, also some code improvements in foomatic-rip and some crasher fixes in cups-browsed foomatic-rip: In some PostScript input files it was possible that option settings did not get inserted or lines inserted on the wron place (Issue #208, Pull request #210). foomatic-rip: For the PDF page count call Ghostscript in sandbox mode and fix pointer arithmetics (Pull request #212). foomatic-rip: Zero-page-job handling changes made the last page of PostScript files not printed, also turning one-page jobs into zero-page jobs (Issue #200, Issue #206, Issue #208, Pull request #209, Pull request #210, Pull request #211). cups-browsed: check_printer_with_option() function: Initialize the value, add further checks, freeing memory and stop allocating magic numbers (Pull request #204). cups-browsed: Additional checks against crashes in the is_local_hostname() function (Ubuntu bug #1863716) More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.27.3-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.27.3 released!",
+ "url": "/cups-filters-1.27.3-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, fixing Ghostscript-based PDF page counting in foomatic-rip to work with all Ghostscript versions, building libfontembed tests with correct path to test font, re-sharing of remote CUPS queues with cups-browsed and others",
+ "content": "Bug fix release, fixing Ghostscript-based PDF page counting in foomatic-rip to work with all Ghostscript versions, building libfontembed tests with correct path to test font, re-sharing of remote CUPS queues with cups-browsed and others cups-browsed: Allow sharing local queues pointing to remote CUPS queues and re-sharing printers discovered via BrowsePoll by default, using AllowResharingRemoteCUPSPrinters and NewBrowsePollQueuesShared directives in cups-browsed.conf (Issue #101, Pull request #218). driverless: Correctly unlink temporary file when generating PPD file (Pull request #220). cups-browsed: Fixed memory leaks (Pull request #219). foomatic-rip: PDF page count side-loads the PDF file to count the pages in, so it cannot be run in -dSAFER mode. Run even in -dNOSAFER mode to override the -dSAFER default of newer Ghostscript versions. This should not cause a security problem as we do not take an input file which could do arbitrary side-loads but we run hard-coded PostScript commands instead (Issue #216). libfontembed: Add checks to the test programs to not segfault if the test font file is not found (Pull request #214). Build System: Let ./configure fail if the supplied test font file path (or the default) does not exist (Pull request #214), also use the \"find\" command to find the test font file DejaVuSans.ttf under /usr/share/fonts, as every distribution has it somewhere else. More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.27.4-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.27.4 released!",
+ "url": "/cups-filters-1.27.4-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, several minor fixes and especially memory issues in cups-browsed",
+ "content": "Bug fix release, several minor fixes and especially memory issues in cups-browsed libcupsfilters, cups-browsed: Fix memory issues in ppdgenerator and cups-browsed (Pull request #226). pdftops: Mention cups-filters README instead of CUPS README in debug log (Pull request #225). pdftopdf, gstoraster, foomatic-rip: Use \"-dSAFER\" Ghostscript option, instead of the deprecated \"-dPARANOIDSAFER\" (Pull request #224). Build System: Replace '==' in configure.ac test with '=', as the former is a bashism (Pull request #222). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.27.5-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.27.5 released!",
+ "url": "/cups-filters-1.27.5-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Several fixes/improvements on cups-browsed, to correctly determine the CUPS server to attach to, to correctly create queues pointing to a second local CUPS instance, and to not remove the locally created queues on shutdown. Also included several bug fixes from contributors",
+ "content": "Several fixes/improvements on cups-browsed, to correctly determine the CUPS server to attach to, to correctly create queues pointing to a second local CUPS instance, and to not remove the locally created queues on shutdown. Also included several bug fixes from contributors cups-browsed: Do not remove the created local queues on shutdown, to avoid their re-creation on restart, so that desktops get no cluttered with notifications of new queues being created. One can return to the old behavior via \"KeepGeneratedQueuesOnShutdown No\" in cups-browsed.conf (Ubuntu bug #1869981, #1878241). cups-browsed: Do not accept DNS-SD broadcasts of IPPS type of \"remote\" CUPS queues of another CUPS instance on the local machine. This way we get a local queue pointing to such a printer only in unencrypted version (IPP). For some reason printing from one CUPS server to another on the same machine works only unencrypted. foomatic-rip: Map two-sided-short-edge to DuplexTumble (Pull request #236) Build system: In configure.ac use AS_IF instead of AC_CHECK_FILE for font check (Issue #239, Pull request #240) cups-browsed: Cleaned up code for determining to which CUPS server (host/port/domain socket) to connect, so that connection via DomainSocket cups-browsed.conf directive, CUPS_SERVER and IPP_PORT environment variables and all defaults and methods of libcups, including CUPS' client.conf work. gstoraster, rastertopdf: Do not pass NULL to fprintf() (Pull request #230). libcupsfilters: Silence compiler warning (Pull request #229). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.0-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.0 released!",
+ "url": "/cups-filters-1.28.0-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "IPPS and IPP Fax Out support in driverless, log file size limitation and more options for cups-browsed, tons of bug fixes",
+ "content": "Feature release (probably the last one before 2.0.0) which adds IPP Fax Out support, IPPS support, and a command line option to reveal satndard IPP URIs to the \"driverless\" utility, added log file size limitation and command line options to control what happens to generated queues on shutdown to cups-browsed, fixed several bugs when printing PostScript input files, several bugs and memory leaks in cups-browsed, crashes on the presence of certain fonts, and many more fixes. driverless, driverless-fax, libcupsfilters: Added IPP Fax Out support. Now printer setup tools list an additional fax \"driver\". A fax queue is created by selecting this driver. Jobs have to be sent with \"-o phone=12345\" to supply the destination phone number (Pull request #280). libfontembed: Silenced warning with gcc 10.x (Pull request #287). cups-browsed: Added ./configure options --enable-saving-created-queues and --with-remote-cups-local-queue-naming (Pull request: #253, #285). cups-browsed: Fixed several memory leaks, mainly from the code to merge printer IPP attributes for clusters (Pull request #281, #283). driverless: Added \"--std-ipp-uris\" command line option to show listed URIs in standard hostname-based form (not the CUPS DNS-SD-service-name-based form. Only for manual call of the utility, for debugging purposes (Pull request #277). libfontembed: Removed assert() calls which cause crashes when unsupported emoji fonts are installed (Issue #254, Pull request #276). driverless: Added support for IPPS (use \"ipps://...\" URIs if possible, Issue #251, Pull request #270, #273). gstoraster, gstopdf: When converting PostScript to PDF use the \"pdfwrite\" output device with \"-dPDFSETTINGS=/default\" instead of with \"-dPDFSETTINGS=/printer\". This reproduces bitmaps in the PostScript file with their original image quality (Issue #272). cups-browsed: Limit log file size and add backup file for previous log entries. Introduced the configuration option DebugLogFileSize in cups-browsed.conf to set the actual limit in kilobytes or 0 to get the old behavior of an unlimited size for the log file (Issue #260, Pull request #267). gstoraster, gstopdf: Do not apply margins when output format is PDF, as then we convert an incoming PostScript file to PDF (pre-pdftopdf) and do not prepare the pages for the printer (post-pdftopdf, Issue #250). cups-browsed: Do not write any log messages directly to stderr, there were some concerning timeouts on queue creation (Issue #260). Build system: Fix cross-compilation without DejaVu test font in configure.ac (Issue #262, Pull request #263). libcupsfilters: Respect the fact that PPD keywords are case-sensitive when adding \"*cupsManualCopies: True\" in PPD file (Issue #242). libcupsfilters: Older versions of libcups (< 2.3.1) had the enum name for fold-accordion finishings mistyped. Added a workaround. cups-browsed: Remove left-over local queues from the previous session more quickly when CUPS legacy browsing is turned on. cups-browsed: Left-over local queues from the previous session for which the corresponding remote printer did not appear again did not get removed as they were considered externally overwritten. gstoraster, gstopdf: Add option \"-dDoNumCopies\" to Ghostscript command line if we are outputting PDF (called via gstopdf wrapper) and the number of copies supplied to CUPS is 1 (4th command line argument). In this case we convert incoming PostScript to PDF and need to respect embedded PostScript commands to implement the number of copies (Issue #255, CUPS Issue #5796, OpenSUSE bug #1173345). imagetoraster: Potential null dereference fix (when no valid PPD is supplied, Pull request #256). cups-browsed: Call cupsGetNamedDest() only if \"OnlyUnsupportedByCUPS No\" Sample PPDs: Corrected ColorModel default for Generic PWG Raster PPD to Color (Pull request #247). cups-browsed: Mark the temp queue as cups-browsed-generated during setting printer-is-shared (Pull request #246). cups-browsed: Remove mentions of README and AUTHORS files in the man page (Pull request #244). Sample PPDs: In Generic-PDF_Printer-PDF.ppd add option to switch between color and grayscale printing (Pull request #237). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.1-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.1 released!",
+ "url": "/cups-filters-1.28.1-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release to fix several bugs in the new IPP Fax Out support by the \"driverless\" utility and also to fix some minor issues",
+ "content": "Bug fix release to fix several bugs in the new IPP Fax Out support by the \"driverless\" utility and also to fix some minor issues COPYING: Fixed several typos libcupsfilters: Fixed typo in log message of get_printer_attributes functions. cups-browsed: Fixed typos in configuration file and man page libcupsfilters: Let the PPD generator not suffix page size names with \".Borderless\" if all page sizes would get this suffix, for example for printers which generally print borderless. libcupsfilters: Added \"faxPrefix\" option for generated IPP Fax Out PPDs, so that this option also appears in print dialogs. driverless: List addresses for local services correctly when using \"--std-ipp-uris\" (with \"localhost\" hostname). driverless: Make calls of the ippfind utility somewhat faster, setting the timeout of ippfind to automatic. libcupsfilters: Resolve DNS-SD-based URIs for local services correctly (using hostname \"localhost\"). libcupsfilters: In get_printer_attributes() functions do not try to convert URIs which are not DNS-SD-based (Issue #294). libcupsfilters: In get_printer_attributes() functions also support URIs with \"dnssd://...\" scheme. libcupsfilters: Moved signal handling back into main function of the get_printer_attributes() variants, it got moved out accidentally. driverless: For generating a PPD, independent whether via \"driverless URI\" or \"driverless cat URI\", always allow CUPS driver URIs (prefixed with \"driverless: \" or \"driverless-fax:\") and pure IPP URIs. driverless: Accept clean IPP URIs also for 'driverless cat ...' (Issue #295, Pull request #296). driverless-fax: Do not use fixed path for call of driverless itself (Pull request #293). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.10-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.10 released!",
+ "url": "/cups-filters-1.28.10-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, more reliable CUPS browsing in cups-browsed, improved PDF printer PPDs, minor fixes",
+ "content": "Bug fix release: More reliable legacy CUPS browsing in cups-browsed, improved PDF printer sample PPDs, with borderless page sizes, eliminated unneeded dependency on DjVu font, minor fixes Sample PPDs: Add borderless page size definitions to Generic PDF Printer, HP Color LaserJet CM3530 MFP PDF, and Ricoh PDF Printer PPD files. Sample PPDs: From the PDF PPD files removed the unneeded \"*cupsFilters2: ...\" line. For CUPS it does not make any difference. libcupsfilters: Fixed pdftopdf filter to correctly support page ranges without upper limit, like \"10-\" (Pull request #399). libcupsfilters: Use wildcard tag (IPP_TAG_ZERO) search for \"media-type\" and \"media-type-supported\" in the PPD generator (Pull request #398). implicitclass, parallel: Added missing newlines at error messages. libfontembed: Removed unneeded fontembed/main.c and ttfread executable. Eliminates the dependency on DejaVuSans.ttf (Issue #386). gstoraster: Refactor the filter a little to clarify handling of page counts and set job-impressions for TotalPageCount in PWG-Raster header (Pull request #394). cups-browsed: Make NotifLeaseDuration configurable and renew after half the lease duration not 60 sec before end. The early renewal improves reliability on busy systems a lot. For easier development and debugging short durations from 300 sec on can get selected (Pull request #378). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.11-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.11 released!",
+ "url": "/cups-filters-1.28.11-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, containing backports of many of the bugs recently fixed during the preparation of the cups-filters 2.x release.",
+ "content": "Bug fix release, containing backports of many of the bugs recently fixed during the preparation of the cups-filters 2.x release. Important is that cups-browsed's queue naming is aligned with CUPS' temporary queue naming now and several bugs affecting driverless printing are fixed. libcupsfilters: Let PPD generator take default ColorModel from printer (CUPS issue #277). Braille: In vectortopdf check inkscape version to call inkscape with the correct command line (Issue #315, Pull request #443). Build system: Make missing DejaVuSans.ttf non-fatal in ./configure as the font is only needed for test programs, not for actual use of cups-filters (Issue #411). libcupsfilters: In imagetoraster() fixed crash with SGray (Issue #435). cups-browsed: Naming of local queues is matched to CUPS' current naming of temporary queues (no leading or trailing underscores), to avoid duplicates in print dialogs which support CUPS' temporary queues. libcupsfilters: Make cupsRasterParseIPPOptions() work correctly with PPDs (Issue #436). libcupsfilters: Let colord_get_profile_for_device_id() not return empty file name, to avoid error messages in CUPS error_log. foomatic-rip: Debug message was wrongly sent to stdout and not to log (Issue #422). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.12-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.12 released!",
+ "url": "/cups-filters-1.28.12-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, again backports of cups-filters 2.x, page geometry fixes for print-scaling and number-up, cups-browsed, serial backend",
+ "content": "Bug fix release, containing backports of many of the bugs recently fixed during the preparation of the cups-filters 2.x release. This time many page geometry bugs in the pdftopdf and imageto... filters were fixed especially with print-scaling and number-up, but also bugs in cups-browsed and in the serial backend got fixed. 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 need 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 happem\" 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 differences between size dimensions. More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.13-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.13 released!",
+ "url": "/cups-filters-1.28.13-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, for correct printing on printers which take in the paper long-edge-first and for Apple LaserWriter printers",
+ "content": "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). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.14-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.14 released!",
+ "url": "/cups-filters-1.28.14-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release to get correct PDF output when using \"landscape\", \"orientation-requested\", and/or \"nopdfAutoRotate\" options, and to get PCLm printing work on printers not telling their PCLM default resolution.",
+ "content": "Bug fix release to get correct PDF output when using \"landscape\", \"orientation-requested\", and/or \"nopdfAutoRotate\" options, and to get PCLm printing work on printers not telling their PCLM default resolution. pdftopdf: Correct the output when suppressing auto-rotation (option \"nopdfAutoRotate\"). Depending on the situation pages got cropped in the wrong orientation or de-centered. pdftopdf: Correct the output when the \"orientation-requested\" or the \"landscape\" option is supplied. Output could be de-centered (Issue #456), portrait-oriented pages be wrongly cropped and division of the output page into cells for N-up done in the wrong orientation. rastertopdf: In PCLm output mode the filter failed to generate PCLm if the printer has no \"pclm-source-resolution-default\" IPP attribute. More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.15-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.15 released!",
+ "url": "/cups-filters-1.28.15-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, to make all HP LaserJet PostScript printers correctly work.",
+ "content": "Bug fix release, to make all HP LaserJet PostScript printers correctly work. pdftops: In pdftops identify old LaserJets more precisely for working around PostScript interpreter bugs, older printers need Poppler, newer models need Ghostscript (Ubuntu bug #1967816). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.16-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.16 released!",
+ "url": "/cups-filters-1.28.16-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, to make images be printed in their original size with \"print-scaling=none\" and to not use deprecated data types for reading TIFF images.",
+ "content": "Bug fix release, to make images be printed in their original size with \"print-scaling=none\" and to not use deprecated data types for reading TIFF images. imagetoraster, imagetopdf, libcupsfilters: Added support for reading the resolution of an image from its EXIF data when loading it. This way we get the image reproduced in its original size with \"print-scaling=none\" (Issue #362). libcupsfilters: Replaced deprecated data types uint16 and uint32. The function to read TIFF image files via libtiff in cupsfilters/image-tiff.c uses the deprecated types uint16 and uint32. The replacements for these types are uint16_t and uint32_t. More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.17-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.17 released!",
+ "url": "/cups-filters-1.28.17-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, to more reliably discover all printer capablities from driverless printers, especially borderless printing, and to preferably use Apple Raster instead of PWG Raster or PCLM",
+ "content": "Bug fix release, to more reliably discover all printer capablities from driverless printers, especially borderless printing, and to preferably use Apple Raster instead of PWG Raster or PCLM. libcupsfilters: In PPD generator create only one *cupsFilter2: line for raster. Only use the most desirable/reliable format, usually Apple Raster (Issue #498). libcupsfilters: In get_printer_attributes() poll media-col-database separately if needed. On some printers one gets media-col-database only this way. Often it reveals important functionality, like for example borderless printing (Issue #492). libcupsfilters: Let PPD generator also parse media-col-ready IPP attribute. media-col-ready lists the loaded media, in contrary to media-ready, as list of complete descriptions of the media (media-col data structure). This often lists also variants like borderless (it is the same physical paper). Especially useful when media-col-database is not available (Issue #492). libcupsfilters: In generate_sizes() consider all margin alternatives. When generating the PPD file for a driverless printer, and in the media-{left,right,top,bottom}-margin-supported printer IPP attributes there was more than 1 value, the first value (which often was the 0 for borderless printing) was not considered, leaving the borderless functionality of many printers undiscovered (Issue #492). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.2-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.2 released!",
+ "url": "/cups-filters-1.28.2-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release to mainly fix cups-browsed not shutting down and the driverless utility being slow when listing available printers/faxes",
+ "content": "Bug fix release to mainly fix cups-browsed not shutting down and the driverless utility being slow when listing available printers/faxes driverless: Free allocated memory, use MAX_OUTPUT_LEN (Pull request #304). driverless: driverless: Make the two ippfind tasks(for IPP and IPPS) run in parallel (Pull request #302, #305, #306). braille: Support new liblouis tables not containing a display name (Pull request #303) Build system: Let ./configure not error out when there is more than one DejaVuSans.ttf test font candidate (Issue #300). cups-browsed: Crash when a remote printer set as default gets removed, due to missing variable in printf() call (Issue #299). libcupsfilters: Removed all signal handling and global variables from get_printer_attributes() and ippfind_based_uri_converter(). This is overkill for these quick operations and causes problems when shutting down cups-browsed (Issue #298). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.3-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.3 released!",
+ "url": "/cups-filters-1.28.3-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release to sove problems caused by an inconsistency between the resolvers for DNS-SD-based URIs",
+ "content": "Bug fix release to sove problems caused by an inconsistency between the resolvers for DNS-SD-based URIs libcupsfilters, cups-browsed: Fixed inconsistency between resolvers for DNS-SD-based URIs, resolve_uri() and ippfind_based_uri_converter(). Now both return a freeable string. libcupsfilters: Fix uninitialized buffer and parsing ippfind output in ippfind_based_uri_converter() function (Issue #308, Pull request #309). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.4-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.4 released!",
+ "url": "/cups-filters-1.28.4-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, mainly to solve CUPS performance problems caused by the IPP fax support of the \"driverless\" utility",
+ "content": "Bug fix release, mainly to solve CUPS performance problems caused by the IPP fax support of the \"driverless\" utility driverless: Avoid duplicate PPD list entries from the same device via UUID driverless: Reduce ippfind calls by \"driverless\" and \"driverless-fax\"called by CUPS. Let \"driverless list\" list both print and fax PPDs and \"driverless-fax list\" do nothing. driverless: Avoid duplicate listings in printer discovery, by \"driverless-fax\" not listing any URI as \"driverless\" lists them all already. driverless: Vastly improve performance by doing only one ippfind call instead of two (IPP, IPPS) as ippfind accepts more than one reg type on the command line. Sample PPDs: Corrected manufacturer name in Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd. More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.5-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.5 released!",
+ "url": "/cups-filters-1.28.5-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release for a quick, potential crasher correction in cups-browsed",
+ "content": "Bug fix release for a quick, potential crasher correction in cups-browsed cups-browsed: UUID from IPP response was used after its pointer was freed by ippDelete() (Pull request #311). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.6-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.6 released!",
+ "url": "/cups-filters-1.28.6-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, especially memory leaks and performance of cups-browsed, but also on the PPD generator and foomatic-rip",
+ "content": "Bug fix release, fixing lots of memory leaks in cups-browsed, fixed cups-browsed hanging several seconds when there are local print queue with invalid DNS-SD-based URIs, several fixes on the PPD generator for IPP printers, taken from OpenPrinting's fork of CUPS, and fixing bugs on foomatic-rip libcupsfilters: In generated PPDs add a grayscale mode if there are only color printing modes (from OpenPrinting CUPS). libcupsfilters: In generated PPDs add an \"OutputBin\" option also if it has only one choice (OpenPrinting CUPS pull request #18). libcupsfilters: Generated PPDs could have an \"Unknown\" default InputSlot (OpenPrinting CUPS issue #44). cups-browsed: Removed unneeded IPP attribute additions preventing the created local queues from preserving a location or description the user assigns to them (Issue #323). cups-browsed: Removed all calls of the resolve_uri() function of libcupsfilters, as these are not actually needed and in case the supplied DNS-SD-based URI is not resolvable, the function gets stuck for ~5 seconds. cups-browsed: Fixed several memory leaks, mainly from the code to merge printer IPP attributes for clusters (Pull request #322). cups-browsed: Silenced compiler warning. foomatic-rip: Fix infinite loop and input from file on raw printing (Pull request #318). foomatic-rip: Remove temporary file created during pdf-to-ps conversion (Pull request #313). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.7-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.7 released!",
+ "url": "/cups-filters-1.28.7-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release to remove the support quality check from the \"driverless\" utility to do not break CUPS' PPD listing facility and several fixes for generating PPDs for driverless printers",
+ "content": "Bug fix release to remove the support quality check from the \"driverless\" utility to do not break CUPS' PPD listing facility and several fixes for generating PPDs for driverless printers driverless: Removed the support quality check from Pull request #235 as it takes significant time for each printer being listed, making cups-driverd (lpinfo -m) timing out when there are many printers (OpenPrinting CUPS issue #65). libcupsfilters: In the PPD generator give priority to Apple Raster against PDF (Issue #331). libcupsfilters: Added NULL check when removing \".Borderless\" suffixes from page size names (Issue #314, Pull request #328). libcupsfilters: In the cupsRasterParseIPPOptions() map the color spaces the same way as in the PPD generator (Issue #326, Pull request #327). libcupsfilters: Fixed addition of grayscale mode in generated PPD files, to avoid duplicate entries (OpenPrinting CUPS issue #59). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.8-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.8 released!",
+ "url": "/cups-filters-1.28.8-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bugfix release, to fix several different issues",
+ "content": "Bug fix release, to fix several different issues libcupsfilters: Made check whether the driverless PPD to generate should be a fax out PPD more reliable (Issue #343). foomatic-rip: Options in the 5th command line argument of the CUPS filter command line are separated only by white space and not by comma, also make sure that an option \"none\" is not considered a custom page size (Issue #348). implicitclass: Raise timeout for cups-browsed's answer from 20s to 60s (Pull request #346). libcupsfilters: In the PPD generator really give priority to Apple Raster against PDF (Issue #331). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-1.28.9-released",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters 1.28.9 released!",
+ "url": "/cups-filters-1.28.9-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Bug fix release, fixes backported from the master (2.x) branch",
+ "content": "Bug fix release, fixes backported from the master (2.x) branch. libcupsfilters: Silenced compiler warnings libcupsfilters: Removed duplicate code in the apply_filters() function. driverless: If there are no driverless IPP printers available let \"driverless\" terminate with exit code 0 and not 1, to follow CUPS' standard of backends in discovery mode terminating with 0 if there are no appropriate printers found (Issue #375). gstoraster, foomatic-rip: Fixed Ghostscript command line for counting pages as it took too long on PDFs from evince when printing DjVu files (Issue #354, Pull request #371, Ubuntu bug #1920730). cups-browsed: Renamed ldap_connect() due to conflict in new openldap (Issue #367, Pull request #370). pdftoraster: Free color data after processing of each page (Pull request #363). cups-browsed: Always save \"...-default\" option entries from printers.conf, regardless of presence or absense of PPD file (Pull request #359). cups-browsed: Start after network-online.target (Pull request #360). texttopdf: Set default margins when no PPD file is used (Pull request #356). More Details and Download"
+ },
+ {
+ "id": "post:cups-filters-Second-Generation-Final-2.0.0-Release",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters Second Generation - Final 2.0.0 Release!",
+ "url": "/cups-filters-Second-Generation-Final-2.0.0-Release",
+ "headings": [
+ "libppd Postscript Parsing Heap Overflow (CVE-2023-4504)",
+ "Miscellaneous fixes",
+ "libcupsfilters",
+ "libppd",
+ "cups-filters",
+ "cups-browsed",
+ "Packages"
+ ],
+ "tags": [],
+ "snippet": "Now it is there! The 2.0.0 release! Security vulnerability fix and final bug fixes",
+ "content": "Now, in the last 3 months, we got only few bug reports, and a security vulnerability in CUPS, in code which got overtaken into libppd, and therefore the vulnerability is also there. To get the security fix into a release and 3 months being a long time after RC2 I am finally releasing 2.0.0 right now. From the bug report: The ppd_scan_ps() function in the libppd code base provides functionality that scans through a string looking for the next Postscript object. When iterating through a string which contains an open parenthesis and ends with a single backslash (0x5c) character, the code incorrectly iterates forward a character without properly checking the bounds of the string resulting in a 1 byte read beyond the allocated heap buffer. This is fixed by adding the missing NULL check when, after a backslash was read, the character escaped by the backslash is read. A few other bugs got reported and fixed since RC2. These fixes are also included. See the lists below. And here are the lists of all the changes in detail: cfFilterUniversal(): Support application/vnd.cups-postscript Some filters (like hpps from HPLIP) produce this MIME type, so if the client uses a classic driver/Printer Application and the server IPP Everywhere, jobs fail because the library is not able to find a suitable conversion (Pull request #31). CHANGES.md: Added reference to Chromium bug report. INSTALL: We need Ghostscript 10.01.1 to get all changes for Raster output ppd_scan_ps(): Fix CVE-2023-4504 Added check for end of buffer/string when reading escaped character after backslash, return NULL (invalid string) if no character follows. Promoted the static function \"ppd_decode()\" of ppd/ppd.c into the API function \"ppdDecode()\". ppdEmitJCLPDF(): Decode \"JCLToPDFInterpreter\" value in ppdEmitJCLPDF() Fixes \"classic\" (non-driverless) PDF printing (Issue #24). ppdLoadAttributes(): Apply cfIEEE1284NormalizeMakeModel() to NickName Make and model for the printer IPP attributes are extracted from the PPD's NickName, which sometimes misses the manufacturer's name. Extract it from the PPD's Manufacturer field or derive it from the model name if possible. Enhanced alternative for pull request #21. Makefile.am: Fix disabling testppdfile Missing conditionals made the binary built when disabled (Pull request #18). universal: Enable application/vnd.cups-postscript as input There are filters which produce this MIME type (such as hpps of HPLIP), and if someone uses such driver on a client and the server has an IPP Everywhere/driverless printer, the job fails (Pull request #534, requires libcupsfilters 2.0.0). Ensure we always send a valid name to remove_bad_chars() In case the found queue is a CUPS remote queue shared via DNS-SD, the rp_value can be without '/', which leads to cups-browsed crash if it is set to create the local queue based on the remote name (Pull request #13). Use description/location from server if available, otherwise from client When we create a local queue we first check whether we actually got description and location strings from the remote server/printer, if they are empty we do not set empty strings but use the IPP attributes saved locally for our local queue. This way, if the server does not provide description/location and the user sets their own, that one is conserved through reboots and daemon restarts (Issue #16). libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion cups-filters: More Details and Download, Discussion cups-browsed: More Details and Download, Discussion Note that braille-printer-app will only be released once the conversion to a Printer Application got implemented."
+ },
+ {
+ "id": "post:cups-filters-Second-Generation-First-Beta-Release",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters Second Generation - First Beta Release!",
+ "url": "/cups-filters-Second-Generation-First-Beta-Release",
+ "headings": [],
+ "tags": [],
+ "snippet": "cups-filters is now split into 5 sub-repositories and we have released the first beta of the 2.x series",
+ "content": "We now finally completed the first beta of the second generation of cups-filters! The cups-filters project is now split into several parts, similar to CUPS on its transition to the 3.x series. There are the following parts: libcupsfilters: The central library with the filter functions and some useful functions for printer drivers, human-readable strings and translation handling for IPP attributes, ... It does not contain any support for PPD files. libppd: PPD file support library providing the complete support for PPD files from libcups (2.x and earlier, see ppd/ppd.h), the CUPS PPD compiler and utilities (ppdc, see ppd/ppdc.h) and functions to convert PPD Options into IPP attributes, to add PPD file support to the filter functions of libcupsfilters, to handle collections of PPD files, ... This library is only for legacy PPD and driver support, it should not motivate anyone to create new PPD files! cups-filters: Legacy CUPS filter/backend executables for CUPS 2.x. Uses both libcupsfilters and libppd. Any XXXtoYYY filters, foomatic-rip, driverless, ... braille-printer-app: The Braille embosser driver code plus Chandresh Soni's GSoC work to turn this code into a Printer Application. cups-browsed: Daemon to automatically create local print queues for network printers and remote CUPS queues and to create printer clusters. Will be turned into a Printer Application later (GSoC project?). libcupsfilters is completely free of PPD file support, same for braille-printer-app. libcupsfilters can be used for all kinds of Printer Applications and wherever print data or scanned data has to get converted. The Braille Printer Application is a native Printer Application, it does not use PPD files internally. libppd contains the complete PPD file support for Printer Applications which retro-fit PostScript PPD files or classic CUPS drivers. These Printer Applications are usually created based on pappl-retrofit. Distributions using the New Architecture for printing and scanning will not install libppd by default, as it is not needed any more. cups-filters provides the filter executables needed by CUPS 2.x or earlier. Most executables are just simple wrappers and all the internal workings have moved into the filter functions in libcupsfilters, and the PPD file support into libppd. This package requires libppd, but it is for PPD-based classic CUPS versions only anyway. cups-browsed is currently supporting and generating PPD files (for CUPS 2.x), and therefore also depending on libppd. In a later version, when it is turned into a Printer Application, the PPD file support will be removed. An important goal of the separation is to put all PPD support in their own project so that they can get discontinued later and this way we can easily stop maintaining the PPD file support code while all the other useful code of the former cups-filters will live on. libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion cups-filters: More Details and Download, Discussion cups-browsed: More Details and Download, Discussion Note that braille-printer-app will only be released once the conversion to a Printer Application got committed."
+ },
+ {
+ "id": "post:cups-filters-Second-Generation-Release-Candidate-2",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters Second Generation - Release Candidate 2!",
+ "url": "/cups-filters-Second-Generation-Release-Candidate-2",
+ "headings": [
+ "cups-browsed 100% CPU!",
+ "The Unsupported Resolution Attack!!",
+ "All-Snap Ubuntu Desktop",
+ "libppd sync-up with CUPS",
+ "First Vulnerability Report",
+ "libcupsfilters",
+ "libppd",
+ "cups-filters",
+ "cups-browsed",
+ "Packages"
+ ],
+ "tags": [],
+ "snippet": "Now we are really close - Resolution handling, mirrored output, no output at all, beh vulnerability, cups-browsed 100% CPU, libppd vs. CUPS sync",
+ "content": "After the cups-filters 2.x release party in Brno (Ubuntu 23.04 and Fedora 38 with 2.0rc1) there also came the first bug reports from users. And together with other fixes a lot of stuff came together, so I decided to issue a second release candidate before actually landing the final. First bug report coming up was that cups-browsed is taking up between 25% and 100% of one CPU core (Ubuntu bug #2018504). Especially my colleagues complained about this when we were all meeting for a week at Canonical's Engineering Sprint two weeks after the Ubuntu 23.04 release (and one of them posted this bug report), and after we were all home again nobody was able to reproduce it any more. Fortunately there were other users able to reproduce this bug and so we do not need to wait for the next Engineering Sprint in November to get it fixed. Even not able to reproduce it by myself I investigated the workflow, especially after multi-threading got introduced. And there I found that if during creation or update of a local print queue the destination IPP printer cannot get accessed a global variable is set, to stop the loop of updating all local queues and remove the local queue whose destination got lost. Main problem was that the variable did not get reset, so all future update loops got immediately stopped, without even a first update being done, and as the updates still were due, the loop got immediately started again, causing a busy loop for the rest of the life of the cups-browsed process. To fix this, I have simply done away with this variable altogether and simply mark the printer as disappeared for the local queue be removed in the next updating round. This is my original design and was already done with multi-threading in mind. What actually happened on the Engineering Sprint was that I have a lot of shared printers on my laptop, of the Printer Applications I am developing and testing, and when I left our team's meeting room for a meeting with other people, the shared printers got unaccessible for the colleague's laptops and the bug showed up ... There were also some Ubuntu and Fedora users reporting bugs on printing, starting from uglinesses like all jobs coming out mirrored, or, the more ecological way, nothing coming out at all, up to unsupported resolution attacks. The unsupported resolution attack was performed by the Chromium Browser, sending jobs with resolution=96dpi option and these getting printed as garbage by CUPS. It was not intended to save ink by printing less pixels, but simply a bad choice for a default resolution when no resolution info is provided by the PPD and also missing support for PPD files with only *DefaultResolution=... but no \"Resolution\" option. The Chromium developers have fixed that on the Chromium side, but the final solution is on the way. The reporter of the bug also reported the problem to us and made us aware that we do not ignore unsupported resolutions and simply rasterized in them, instead of, as with other job attributes/options, to ignore unsupported values. Now this is fixed to defend our users against such attacks from applications. And, once investigating our resolution handling, I have fixed also some other resolution-related bugs to get more consistent behavior and especially resolution settings in the pseudo-PostScript code of non-\"Resolution\" options of the PPDs (like \"cupsPrintQuality\") being respected. During the development work on the all-Snap Ubuntu Desktop my colleagues started to test the CUPS Snap (which is included in the installation image but not in the immutable operating system core) amd we found out that cups-browsed broke printing when restoring saved printer settings and attributes due to a CUPS bug with the print-quality attribute, making CUPS setting the invalid default velue \"0\" when it receives any invalid value and not simply ignoring that inquiry (and logging an error). We work around this CUPS problem now by not saving and restoring printer IPP attribute default for the local queues any more (the PPD option defaults should be good enough). The development of libppd, a library which conserves all of CUPS' PPD file support for retro-fitting Printer Applications before it gets removed from CUPS in the 3.x generation, started nearly exactly 3 years ago. Now in these 3 years after grabbing CUPS' PPD supporting code for libppd a lot has happened with CUPS and also this code received several bug fixes (including some memory leaks) and also even small feature additions by adding extra attributes to generated PPDs so that CUPS can better support all IPP functionality of all driverless printers. I have overtaken these changes now to be in sync with CUPS. Especially retro-fitting Printer Applications now always list all media types of the PPD file! And last, but not least, our second release candidate contains the fix for our first security vulnerability reported via GitHub. It was the beh CUPS backend (Backend Error Handler) allowing to execute arbitrary commands by supplying jobs with forged job titles. The backend is not that often used, but this was also a nice case to find out how to handle any reported vulnerability (which made me writing a tutorial). And here are the lists of all the changes in detail: Ignore unsupported resolution values when preparing a Raster header via cfRasterPrepareHeader() function, to avoid rasterization with wrong resolution (Issue #29, Ubuntu bug: #2022929, Chromium issue #1448735). cfRasterPrepareHeader(): When taking default resolution from urf-supported printer IPP attribute, use first value (lowest) of the list, to match the ppdLoadAttributes() function of libppd. cfIPPAttrResolutionForPrinter(): List of resolutions is not IPP_TAG_RANGE, corrected the search to use IPP_TAG_ZERO. cfIEEE1284NormalizeMakeModel(): Do not consider \"XPrinter\" as made by Xerox, only \"XPrint\" is (OpenPrinting CUPS pull request #506). INSTALL: Recommend QPDF 11.4.0 as it fixes loss of content filled into interactive forms as (Issue #28). INSTALL: Fixed some typos. ppdFilterPSToPS(): Fixed reverse output order. When converting the former pstops CUPS filter into the filter function, some function calls got wrongly replaced by new ones, resulting in no output at all when the input should be re-arranged into reverse order. This broke printing with all PostScript printers (and proprietary CUPS drivers needing PostScript as input) which do reverse-order by default (Issue #20, Ubuntu bug #2022943). Fixed resolution handling when converting PPDs to printer IPP attributes For PWG/Apple Raster or PCLm output resolutions in job options or pseudo-PostScript code in the PPD get ignored and instead, the lowest resolution of the description of the Raster format used in the PPD file gets always used, which reduced output quality (Ubuntu bug #2022929). ppdFilterLoadPPD(): Actually create sample Raster header also for Apple/PWG Raster All PPD files with \"MirrorPrint\" option cuased mirrored printout If a PPD contains an option \"MirrorPrint\", the ppdFilterLoadPPD() sent the option mirror=true to the filter functions, regardless of the actual setting of \"MirrorPrint\" (which is usually \"False\" by default), making all jobs coming out with mirrored pages (Ubuntu bug #2018538). PPD file generator: Put *cupsSingleFile: True into generated PPD as some driverless IPP printers do not support multi-file jobs (CUPS issue #643). Add CUPS PPD attributes *cupsLanguages: ... and *cupsStringsURI ... to generated PPDs so that CUPS loads printer-specific option names and translations from the printer and uses them without need of static translations in the PPD file. CUPS renames the PPD option choice name \"Custom\" to \"_Custom\" when a fixed choice is named as such, to distinguish from CUPS' facility for custom option values. We do now the same when loading PPD files. Prevent duplicate PPD->IPP media-type name mappings, now we do not have dropping of some media types in the Printer Applications any more. When not specifying a media source and the page size is small (5x7\" or smaller) do not request the photo tray but auto instead. Do not override color settings from print dialog (\"ColorModel\") with print-color-mode setting. Make ppdFilterPSToPS() recognize %%PageRequirements: DSC comment. Correctly display \"Xprinter\" instead of Xerox for Xprinter devices Fix the job-pages-per-set value (used to apply finishings correctly) for duplex and N-up printing. Make the testppd build test program also work if it is started from an environment with non-English locale. Minor bug fixes, silencing warnings (especially of clang), fixing typos in comments, coding style, ..., and also some fixes for memory leaks. beh backend: Use execv() instead of system() - CVE-2023-24805 With execv() command line arguments are passed as separate strings and not the full command line in a single string. This prevents arbitrary command execution by escaping the quoting of the arguments in a job with forged job title. beh backend: Extra checks against odd/forged input - CVE-2023-24805 Do not allow / in the scheme of the URI (= backend executable name), to assure that only backends inside /usr/lib/cups/backend/ are used. Pre-define scheme buffer to empty string, to be defined for case of URI being NULL. URI must have :, to split off scheme, otherwise error. Check return value of snprintf() to create call path for the backend, to error out on truncation of a too long scheme or on complete failure due to a completely odd scheme. beh backend: Further improvements - CVE-2023-24805 Use strncat() instead of strncpy() for getting scheme from URI, the latter does not require setting terminating zero byte in case of truncation. Also exclude . or .. as scheme, as directories are not valid CUPS backends. Do not use fprintf() in sigterm_handler(), to not interfere with a fprintf() which could be running in the main process when sigterm_handler() is triggered. Use static volatile int for global variable job_canceled. parallel backend: Added missing #include lines Fixed cups-browsed getting stuck in busy loop When the function create_queue() fails to create a local print queue and the failure is not intermittent, it sets a global variable to stop the main thread's loop for updating local queues. With the variable not reset no queue updates happened ever again and cups-browsed fell into a busy loop taking up to 100% CPU. We have solved this by doing away with the variable and simply mark these printers as disappeared (Ubuntu bug #2018504). Do not record *-default IPP attributes of local CUPS queues Many of the *-default IPP attributes represent properties already covered by the PPD option defaults which we also record. In addition, there is also print-quality-default where IPP reports draft, normal, and high settings while CUPS only accepts 3, 4, and 5, and on everything else it sets print-quality-default=0 which is invalid and jobs do not get printed. So we stop saving and loading these attributes. Build system: Removed unnecessary lines in Makefile.am Removed the TESTdir and TEST_SCRIPTS entries in Makefile.am. They are not needed and let make install try to install run-tests.sh in the source directory, where it already is, causing an error. run-tests.sh: Use pkgconfig instead of deprecated cups-config (Pull request #9). libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion cups-filters: More Details and Download, Discussion cups-browsed: More Details and Download, Discussion Note that braille-printer-app will only be released once the conversion to a Printer Application got implemented."
+ },
+ {
+ "id": "post:cups-filters-Second-Generation-Release-Candidate",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters Second Generation - Release Candidate!",
+ "url": "/cups-filters-Second-Generation-Release-Candidate",
+ "headings": [
+ "libcupsfilters",
+ "libppd",
+ "cups-filters",
+ "cups-browsed",
+ "Packages"
+ ],
+ "tags": [],
+ "snippet": "Release approaching - Page orientation, image scaling, text in landscape, 16-bit color and 1-bit mono, API adjustment for libcups3, color on color printers fast ...",
+ "content": "Now we are finally coming to the final release of the components of the second generation of cups-filters, version 2.0.0. This means going through open bug reports and pull requests, looking for what can get fixed and merged, checking whether the work from the assignments given to GSoC contributor candidates during the selection process got actually included, ... Also one or another bug report motivates to do further, more intense and systematic testing, as for example GSoC candidate Sourabh Sav did not find a way to suppress auto-rotation of an image when one prints it. This made me discover that the orientation-requested attribute was mostly not working with our filter functions and I tested systematically to make it working as expected everywhere, and so not only stopped auto-rotation when desired but also gave full control about orientation of images and text, even discovered that one could not layout plain text input in landscape orientation on the sheet. Now this is all fixed and working. The beta releases being included in Ubuntu 23.04 helped on finding bugs, too, as for example in Ubuntu bug #2014976 a user has a driverless color printer for which cups-browsed auto-creates a print queue. The printer takes too long to print the pages and also prints grayscale by default. The grayscale was caused by libppd's PPD file generator for driverless printers not auto-selecting color as default color mode option when the printer's IPP response reports \"auto\" (commit). The slow printing was caused by cups-browsed's implicitclass CUPS backend choosing PDF as output format when the printer in addition supports the much more reliable Apple Raster (commit). This is all fixed in the Release Candidate which today made it in time into Ubuntu 23.04 before tomorrow's Final Freeze (release Thursday next week). And the Release Candidate is the stage when the API has to be finalized. Having given the addition of libcups 3.x support to libcupsfilters as an assignment to GSoC contributor candidate Gayatri Kapse I have found out that we are using 2 dirty workarounds to convert a DNS-SD-based device URI for IPP printers into a standard host-name-based device URI. These 2 had both their own API functions. As the new libcups will finally have a proper API function for this task I have adapted the API already now, despite the libcups3 support will actually be added only in versions 2.1.0 of all the components. And here are the lists of all the changes in detail: Make orientation-requested work correctly In the filter functions cfFilterImageToRaster(), cfFilterImageToPDF(), cfFilterTextToPDF(), and cfFilterPDFToPDF() supplying the attributes orientation-requested or (no)landscape do the expected, rotating content 0/90/180/270 degrees. Auto-rotation is always done in the printer's default direction, +90 or -90 degrees as described by the landscape-orientation-requested-preferred IPP attribute or by the \"*LandscapeOrientation: ...\" PPD keyword (via libppd). The ppi attribute works correctly now,no cropping and using more than one sheet if the image gets too large. If more than one image-scaling-related attribute is supplied, only the one with the highest priority is used, no mixing with unexpected results. Default is always print-scaling=auto. cfFilterTextToPDF() is now capable of printing text in landscape layout, controlled by the orientation-requested and landscape attributes. The prettyprint attribute of the cfFilterTextToPDF() now uses wider margins for binding/stitching/punching as originally designed. If the printer has even wider margins this is taken into account. cfFilterImageToRaster(), cfFilterImageToPDF(), cfFilterTextToPDF(), and cfFilterPDFToPDF() all work now correctly also with no printer attributes/capabilities supplied at all, and also with and without supplying a page size. With PDF input the input page sizes are used if applicable. As last mean we resort to US Letter page size (Issue #26). The cfFilterUniversal() filter function now considers the output of cfFilterImageToPDF() correctly as application/vnd.cups-pdf and not as application/pdf, avoiding duplicate application of margins or rotation. cfFilterImageToRaster() now produces 16-bit-per-color output if requested by the job/printer, and does not output a blank page any more (Issue #25, pull request #22). On 1-bit dithered output white background got a grid of dots An off-by-one bug in cfOneBitLine() made white areas appear with a grid of black dots (1 per 16x16 square). This corrected now (Issue #20). DNS-SD device URI resolution: Cleaned API for upcoming libcups3 support. For resolving DNS-SD-service-name-based device URIs for IPP printers as CUPS uses them, libcups2 does not offer any useful API and we therefore ended up implementing 2 workarounds. As libcups3 has an API function for it we have adapted our API for its use (libcups3 support will get actually added in version 2.1.0). Cleaned up the image scaling and rotation code in cfFilterImage...(), removing duplicate code and doing some simplification. cfFilterImageToPDF() could crash when an image could not get loaded and print-scaling was set to fill or none, as a part of the image processing was not covered by the NULL check. cfFilterUniversal(): Added NULL checks for parameters, so that the function can get called without parameters. Added -std=c++17 C++ compiler flag (Pull request #18) Needed to build libcupsfilters with QPDF 11. Removed unneeded #include entries for libcups PPD generator for driverless printers: Set default color mode when printer attrs say \"auto\" Actual printer default color mode did not get set and then often \"Gray\" got set for color printers. Now we always choose the \"best\" mode (Ubuntu bug #2014976). ppdLoadAttributes(): Find default page size also by dimensions Some PPDs can contain the same page size twice with different names, whereas the PWG cache created from the PPD contains each size only once. This could make the default size not being found when the PPD is converted to IPP attributes. Now we search also by size and not only by name (Caused Ubuntu bug #2013131). PPD generator for driverless printers: Add *LandscapeOrientation: according to the landscape-orientation-requested-preferred printer IPP attribute. ppdFilterLoadPPD(): Corrected PPD attribute name so that for printers which receive PWG Raster a sample Raster header gets created. Make the testppdfile utility getting built and installed by default. Improved formatting of reports generated by ppdTest(). foomatic-rip: Fix a SIGPIPE error when calling gs (Pull request #517) Ubuntu's autopkgtest for foo2zjs shows foo2zjs's testsuite failing with cups-filters 2.0beta3 only on the ppc64el architecture. This is cause by a timing issue in foomatic-rip which is fixed now. Coverity check done by Zdenek Dohnal for the inclusion of cups-filters 2.x in Fedora and Red Hat. Zdenek has fixed all the issues: Missing free(), files not closed, potential string overflows, ... Thanks a lot! (Pull request #510). Dropped all C++ references and obsolete C standards (Pull requests #504 and #513) With no C++ compiler needed, there is no need for any checks or setting for C++ in configure.ac. configure.ac: Change deprecated AC_PROG_LIBTOOL for LT_INIT (Pull request #508) Prefer sending jobs in Apple Raster instead of in PDF If a destination printer supports both PDF and Apple Raster, and if it is not a remote CUPS queue, prefer sending the job in Apple Raster, as printers print this more reliably (Ubuntu bug #2014976) run-tests.sh: Let emulated printers support PDF input To test that cups-browsed prefers Apple Raster when the printer supports both PDF and Apple Raster as input format, we let the printers emulated by ippeveprinter also support PDF. implicitclass backend: NULL-initialize filter data field for Raster header We are running a filter chain without PPD file, so we do not have Raster header, so initialize it to NULL. libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion cups-filters: More Details and Download, Discussion cups-browsed: More Details and Download, Discussion Note that braille-printer-app will only be released once the conversion to a Printer Application got implemented."
+ },
+ {
+ "id": "post:cups-filters-Second-Generation-Second-Beta-Release",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters Second Generation - Second Beta Release!",
+ "url": "/cups-filters-Second-Generation-Second-Beta-Release",
+ "headings": [
+ "libcupsfilters",
+ "libppd",
+ "cups-filters",
+ "General",
+ "Packages"
+ ],
+ "tags": [],
+ "snippet": "First round of bug fixes, for page size handling, translation support, build systems, source code documentation",
+ "content": "During creation of the Debian/Ubuntu packages for the components of the 2nd-generation cups-filters and also during the further development of the Common Print Dialog Backends (CPDB) some bugs were discovered which are fixed now. Also the adaptation of the source code documentation files to the individual components was not yet complete. So there were many things to fix and these fixes are now available in the second beta release. Filter functions did not handle the page size correctly when no printer IPP attributes are supplied (in case of classic CUPS filter no PPD file). Now if a page size is supplied with the job, this one is simply used, otherwise the sizes of the input pages and as a last mean US Letter. In the cfCatalog...() API for obtaining human-readable strings and translations of attribute/option and choice names, we added suport for specifying the user's UI language now, to receive the requested strings in the correct language, and not only human-readable strings in English. In the cfCatalog...() API also removed the const qualifiers from output string pointers as these strings get allocated by the functions. Let API header files catalog.h and ipp.h not include config.h. Fixed building libcupsfilters with and without libpoppler. By default, libpoppler is used, to not use it, supply the --disable-poppler option to ./configure. Unnecessary ./configure options for the former PDF-to-PostScript filter function (has moved to libppd as ppdFilterPDFToPS) which were forgotten during the separation, are removed now. All AC_DEFINE macro calls in configure.ac got corrected, setting the macros in config.h really to 1 after testing positive. libcupsfilters does not use glib, removed the check in configure.ac. In libcupsfilters.pc.in added libqpdf under Libs.private. In the PPD file generator for driverless printing with CUPS we now support more than 2 resolutions in Apple Raster/AirPrint. The urf-supported IPP attribute was only parsed correctly when its RS part had only 1 or 2 and not more resolutions specified. We have corrected now for an arbitrary amount of resolutions, taking the lowest for \"draft\", the highest for \"high\" and one in the middle for \"normal\" print quality. Update cfCatalogLoad() calls for API change in libcupsfilters. In libcupsfilters we have added language/translation support to the cfCatalog...() API functions via OpenPrinting/libcupsfilters#2. This changes the cfCatalogLoad() calls in libppd (both in the PPD generator for driverless printing). For a quick solution we supply NULL as language for now, resembling the old behavior. We look into language support in the PPD generator later. ppdFilterEmitJCL(): Added NULL check for PPD not being supplied. Classic CUPS filters created based on filter functions using ppdFilterCUPSWrapper() and also filter functions of libppd (ppdFilter...()) should also work without PPD file and not crash if no PPD file is supplied. Make build of genstrings optional. genstrings is only a development tool for the PPD compiler, not a user tool, therefore we make its build optional. Corrected installation path for include files for *.drv files. The PPD compiler ppdc (and underlying functions) of libppd searches for include files in /usr/share/ppdc and not in /usr/share/cups/ppdc any more. Tons of fixes in the source code documentation: README.md, INSTALL, DEVELOPING.md, CONTRIBUTING.md, COPYING, NOTICE, ... Adapted the files to the individual components, added links. Include NOTICE in distribution tarballs In configure.ac added foreign to to AM_INIT_AUTOMAKE() calls. Makes automake not require a file named README. Removed the empty README files. Cleaned up .gitignore libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion cups-filters: More Details and Download, Discussion cups-browsed: More Details and Download, Discussion Note that braille-printer-app will only be released once the conversion to a Printer Application got committed."
+ },
+ {
+ "id": "post:cups-filters-Second-Generation-Third-Beta-Release",
+ "source": "static",
+ "type": "post",
+ "title": "cups-filters Second Generation - Third Beta Release!",
+ "url": "/cups-filters-Second-Generation-Third-Beta-Release",
+ "headings": [
+ "libcupsfilters",
+ "cups-filters",
+ "General",
+ "Packages"
+ ],
+ "tags": [],
+ "snippet": "More bug fixes, especially for those discovered during the distro packaging, mainly in build system and source code documentation.",
+ "content": "During creation of the Debian, Ubuntu, and Red Hat packages for the components of the 2nd-generation of cups-filters and also during the investigation of reported issues some more bugs got discovered and fixed. Especially in all the component's source code tarballs the LICENSE file was missing, which is a problem for Linux distributions using the packages. Now all license- and copyright-relevant files, AUTHORS, COPYING, LICENSE, and NOTICE are included in the source tarballs of all the 4 components. Also unnecessary dependencies, remaining from the times when everything was only a single repository, and overlooked during the separation, got removed, especially in libcupsfilters. And minor functional glitches and shortcomings, discovered by users (using cups-filters 1.x but the problem continued in 2.x) and by Debian´s and Ubuntu's automatic testing during package build (autopkgtest), got spotted and fixed. cfFilterGhostscript(): Select correct ICC profile for PCL-XL. When using the cfFilterGhostscript() filter function to generate PCL-XL (PXL, PCL 6, Ghostscript output devices \"pxlmono\", \"pxlcolor\") output, always the color IPP profile srgb.c was used, also for monochrome output (\"pxlmono\") and this makes Ghostscript error out. Now we correctly select sgray.icc for monochrome output. cfGetPrinterAttributes(): Poll media-col-database separately if needed. Some printers are not able to handle a get-printer-attributes request querying both the all group attribute and the media-col-database attribute, so query the latter with a separate call in such cases. cfGenerateSizes(): Also parse the media-col-ready IPP attribute for page sizes and margins. This often reveals extra margin variants, like borderless. Removed public cfPDFOut...() API (cupsfilters/pdfutils.h). This API only makes sense if the API of fontembed is also public, but this we made private earlier. Build system, README.md: Remove unnecessary dependencies overlooked during the separation: zlib (only needed by libppd), Freetype (not needed any more after removal of pdftoopvp), Avahi and GLib (both only needed by cups-browsed). Thanks a lot, Zdenek Dohnal (Pull request #7). COPYING, NOTICE: Added copyright year 2023 COPYING, NOTICE, AUTHORS: Added Jai Luthra and Vikrant Malik texttopdf: Do not include fontconfig.h in the CUPS filter wrapper Build system: Do not explicitly check for libpoppler-cpp The cups-filters package does not contain any code using libpoppler-cpp, therefore we let ./configure not check for it. Add templates for issue reports on GitHub. This makes a selection screen appear when clicking \"New Issue\" in the web UI, to select whether the issue is a regular bug, a feature request, or a security vulnerability. COPYING, NOTICE: Simplification for autotools-generated files autotools-generated files can be included under the license of the upstream code, and FSF copyright added to upstream copyright list. Simplified COPYING appropriately. Makefile.am: Include LICENSE in distribution tarball libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion cups-filters: More Details and Download, Discussion cups-browsed: More Details and Download, Discussion Note that braille-printer-app will only be released once the conversion to a Printer Application got committed."
+ },
+ {
+ "id": "post:hp-printer-app-1.3.0",
+ "source": "static",
+ "type": "post",
+ "title": "HP Printer Application 1.3.0",
+ "url": "/hp-printer-app-1.3.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "HP Printer Application v1.3.0 adds support for snap server configuration settings and updates the builds.",
+ "content": "HP Printer Application v1.3.0 adds support for snap server configuration settings and updates the builds. Changes include: Switched to using a configure script. Updated documentation for current PAPPL. Added support for snap server configuration settings (Issue #21) Updated macOS and Linux binaries to use PAPPL 1.4.x. Enjoy! Download HP Printer Application v1.3.0 Install HP Printer Application Snap Home Page"
+ },
+ {
+ "id": "post:ippusbxd-1.34-released",
+ "source": "static",
+ "type": "post",
+ "title": "ippusbxd 1.34 released!",
+ "url": "/ippusbxd-1.34-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "This release is mainly to improve the DNS-SD advertising to equal the one of the network mode of the device and also to advertise its AirScan scanning capabilities, but we also have some communication and code base improvements.",
+ "content": "This release is mainly to improve the DNS-SD advertising to equal the one of the network mode of the device and also to advertise its AirScan scanning capabilities, but we also have some communication and code base improvements. DNS-SD-advertise the devices capabilities based on polling the device via IPP (printing and send-fax part) and via HTTP (eSCL scanning part, if available), the records now contain the same information as the DNS-SD records which the printer broadcasts through its network connection Improved code base by formatting, header files, comments in the header files, and improving debug output Added exponential backoff for print read requests when printer's responses are empty for saving resources and reducing log file spam Apparmor: Matched path when bin and sbin directories are merged More Details and Download"
+ },
+ {
+ "id": "post:libcups-3.0.0",
+ "source": "static",
+ "type": "post",
+ "title": "libcups v3.0.0",
+ "url": "/libcups-3.0.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "libcups v3.0.0 is the first stable release of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs.",
+ "content": "libcups v3.0.0 is the first stable release of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs. Changes include: Added cupsLangIsRTL API. Added cupsOAuthGetDeviceGrant, cupsOAuthGetJWKS, and cupsOAuthGetUserId APIs. Added httpGetCookieValue and httpGetSecurity APIs. Added an \"install\" sub-command to the cups-x509 command. Added a \"--user-agent\" option to the ipptool command. Updated documentation (Issue #113) Updated the cupsOAuth APIs to support sharing of some OAuth values between the system (root) and per-user cache values. Updated the cupsJWTNew API to accept an optional JSON claims object. Updated the httpSetCookie API to support multiple \"Set-Cookie:\" header values. Updated ippfind to use the cupsGetClock API. Updated ippeveprinter to include all ready and supported attributes and values in the environment when processing a job. Fixed ipptransform media handling to preserve input document dimensions when \"media\" or \"media-col\" are not specified (Issue #102) Fixed cupsJSONExport functions with empty arrays or objects. Fixed httpGetDateTime for dates in the far future (Issue #124) Fixed input checks for cupsCreateCredentials and cupsCreateCredentialsRequest APIs (Issue #125) Fixed return values of ippDateToTime when the timezone isn't GMT. Fixed a potential timing issue with cupsEnumDests. Fixed a bug in the Avahi implementation of cupsDNSSDBrowseNew. Fixed a memory leak in httpClose. Fixed some Coverity-detected issues. Fixed support for device authorization grants. Enjoy! Download v3.0.0"
+ },
+ {
+ "id": "post:libcups-3.0b1",
+ "source": "static",
+ "type": "post",
+ "title": "libcups v3.0b1",
+ "url": "/libcups-3.0b1",
+ "headings": [],
+ "tags": [],
+ "snippet": "libcups v3.0b1 is the first beta release of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs.",
+ "content": "libcups v3.0b1 is the first beta release of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs. Changes include: Documentation updates (Issue #32) Split out libcups and tools from CUPS 2.x. Simplified the configure script. Now require a C99-capable C compiler. Now require GNU TLS, LibreSSL, or OpenSSL. Now require ZLIB. Now require POSIX or Windows threading support. Now require the poll function (WSAPoll on Windows). Now install with a prefix by default to allow coexistance with CUPS 2.x (Issue #21) Added new GENERATE-FILE directive for ipptool test files. Added new ATTR-IF-DEFINED and ATTR-IF-NOT-DEFINED directives to IPP data files (Issue #3) Added ippFile API for working with IPP data files as used by ipptool, ippexeprinter, and other tools (Issue #14) Added a roll to the default color ippeveprinter printer. Added new DNS-SD API (Issue #19) Added new PWG media sizes. Added new WITH-ALL-VALUES-FROM predicate for ipptool files (Issue #20) Added new SAVE-ALL-CONTENT, WITH-ALL-CONTENT, and WITH-ALL-MIME-TYPES predicates for ipptool files (Issue #22) Added, modernized, and promoted the localization interfaces to public API (Issue #24) Added public JSON API (Issue #31) Added new basename variable for use in ipptool files (Issue #44) Updated the CUPS API for consistency. Fixed ipptool's handling of EXPECT for member attributes (Issue #4) Fixed ipptool's support for octetString values (Issue #23) Removed all obsolete/deprecated CUPS 2.x APIs. Removed (obsolete) Kerberos support. Removed support for SecureTransport (macOS) due to deprecation of the platform API. Removed support for SChannel (Windows) due to restrictions on its use in domain accounts. Enjoy! Download v3.0b1"
+ },
+ {
+ "id": "post:libcups-3.0b2",
+ "source": "static",
+ "type": "post",
+ "title": "libcups v3.0b2",
+ "url": "/libcups-3.0b2",
+ "headings": [],
+ "tags": [],
+ "snippet": "libcups v3.0b2 is the second beta release of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs.",
+ "content": "libcups v3.0b2 is the second beta release of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs. Changes include: Added the ipptransform command to replace/upgrade the ippevepcl and ippeveps commands (Issue #65) Added cupsFormDecode and cupsFormEncode APIs (Issue #49) Added cupsJWT APIs to support JSON Web Tokens (Issue #50, Issue #52) Added ippAddCredentialsString and ippCopyCredentialsString APIs (Issue #58) Added cupsCreateCredentialsRequest and cupsSignCredentialsRequest APIs and updated cupsCreateCredentials API to better support X.509 certificates (Issue #59) Updated the configure script to add _FORTIFY_SOURCE=3 (previous level was 2) when not using address sanitizer and when it hasn't already been added (Issue #51) Updated the httpAddrListen function to use the maximum backlog value. Fixed ipptool limit on the size of an attribute value that would be printed (Issue #5) Fixed some configure script issues (Issue #48) Fixed JSON output bug in ipptool. Fixed CUPS_DNSSD_IF_INDEX_LOCAL when using Avahi. Enjoy! Download v3.0b2"
+ },
+ {
+ "id": "post:libcups-3.0rc1",
+ "source": "static",
+ "type": "post",
+ "title": "libcups v3.0rc1",
+ "url": "/libcups-3.0rc1",
+ "headings": [],
+ "tags": [],
+ "snippet": "libcups v3.0rc1 is the first release candidate of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs.",
+ "content": "libcups v3.0rc1 is the first release candidate of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs. Changes include: Added cupsFormatString and cupsFormatStringv APIs to safely format UTF-8 strings. Added support for per-user instances of cups-locald (Issue #69) Added httpConnectURI API. Added \"end\" argument to cupsParseOptions API. Renamed httpReconnect to httpConnectAgain. Updated cupsDestInfo to accept a cups_dest_flags_t argument. Updated cupsCopyString and cupsConcatString APIs to safely terminate UTF-8 strings. Updated list of attributes included in the destination options. Updated cupsAddIntegerOption and cupsGetIntegerOption to use the long type. Updated httpAddrConnect() to handle POLLHUP together with POLLIN or POLLOUT. Updated the various tool man pages, usage output, and examples. Updated ippCreateRequestedArray for the Get-Documents and Get-Output-Device-Attributes operations. Updated ipptool to validate IPP, PDF, and .strings files using the \"WITH-[ALL-]CONTENT\" predicate (Issue #87) Now use installed PDFio library, if available. Now use NotoSansMono font for ipptransform text conversions. Brought back IPP/2.x and related conformance test files (Issue #85) The ipptransform program now supports uncollated copies. Fixed GNU TLS crash. Fixed PCL output from ipptransform (Issue #72) Fixed JSON output from ipptool. Fixed hang/crash in cupsEnumDests/cupsGetDests (Issue #74) Fixed encoding of IPv6 addresses in HTTP requests (Issue #78) Fixed encoding of IPP_TAG_EXTENSION values in IPP messages (Issue #80) Fixed error handling when reading a mixed 1setOf attribute (Issue #83) Fixed non-quick copy of collection values. Fixed error handling in cupsConnectDest. Fixed TLS negotiation using OpenSSL with servers that require the TLS SNI extension. Fixed a certificate loading issue with OpenSSL. Fixed cupsAreCredentialsValidForName with OpenSSL. Fixed how ippeveprinter responds to an unsupported request character set. Enjoy! Download v3.0rc1"
+ },
+ {
+ "id": "post:libcups-3.0rc2",
+ "source": "static",
+ "type": "post",
+ "title": "libcups v3.0rc2",
+ "url": "/libcups-3.0rc2",
+ "headings": [],
+ "tags": [],
+ "snippet": "libcups v3.0rc2 is the second release candidate of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs.",
+ "content": "libcups v3.0rc2 is the second release candidate of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs. Changes include: Updated httpConnectAgain to re-validate the server's X.509 certificate (Issue #90) Updated the source tarball script to include the PDFio sources. Fixed handling of empty resolution values passed to ipptool (Issue #63) Fixed a compressed file error handling bug (Issue #91) Fixed the default User-Agent string sent in requests. Fixed a recursion issue in ippReadIO. Enjoy! Download v3.0rc2"
+ },
+ {
+ "id": "post:libcups-3.0rc3",
+ "source": "static",
+ "type": "post",
+ "title": "libcups v3.0rc3",
+ "url": "/libcups-3.0rc3",
+ "headings": [],
+ "tags": [],
+ "snippet": "libcups v3.0rc3 is the third release candidate of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs.",
+ "content": "libcups v3.0rc3 is the third release candidate of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs. Changes include: Updated cupsCreateCertificateRequest to store the new private key separately. Updated cupsSaveCredentials to validate the input credentials, support using a saved private key from cupsCreateCertificateRequest, and support credential removal as documented. Updated the raster functions to report more issues via cupsRasterGetErrorString. Fixed a crash bug on Windows. Enjoy! Download v3.0rc3"
+ },
+ {
+ "id": "post:libcups-3.0rc4",
+ "source": "static",
+ "type": "post",
+ "title": "libcups v3.0rc4",
+ "url": "/libcups-3.0rc4",
+ "headings": [],
+ "tags": [],
+ "snippet": "libcups v3.0rc4 is the fourth release candidate of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs.",
+ "content": "libcups v3.0rc4 is the fourth release candidate of the CUPS v3 library and tools which remove deprecated APIs, add new APIs, and normalize existing APIs. Changes include: Added cupsCopyCredentialsPublicKey API. Added cupsGetClock API. Added cupsJWTLoadCredentials API. Added \"client.conf\" man page. Added cups-oauth and cups-x509 utilities (Issue #108) Updated documentation (Issue #99) Updated cupsDNSSD APIs on Windows (Issue #29) Updated the ipptool utility to support the --bearer-token and --client-name options. Updated cupsOAuthGetMetadata to support Microsoft Azure/Entra OAuth servers. Updated ipptransform to support generation of PCLm output in addition to PWG Raster data. Updated cupsEnumDests and cupsGetDests to support printer browsing and filtering options in client.conf (Issue #106) Fixed handling of finishings/finishings-col and media/media-col in the ippeveprinter tool (Issue #95) Fixed a duplicate printer reporting bug in cupsGetDests. Fixed handling of NULL path in cupsSaveCredentials API. Fixed handling of default authorization strings. Fixed validation of dateTime values with time zones more than UTC+11. Enjoy! Download v3.0rc4"
+ },
+ {
+ "id": "post:libcupsfilters,-libppd,-cups-filters-2.1.0-Releases-including-vulnerability-fix",
+ "source": "static",
+ "type": "post",
+ "title": "libcupsfilters, libppd, cups-browsed - 2.1.0 Releases including vulnerability fixes",
+ "url": "/libcupsfilters,-libppd,-cups-filters-2.1.0-Releases-including-vulnerability-fix",
+ "headings": [
+ "Contained security fixes",
+ "New features since 2.0.0",
+ "Packages"
+ ],
+ "tags": [],
+ "snippet": "All available fixes of recent RCE and DoS vulnerability CVEs included, also libcups3 support and filter workflow testing.",
+ "content": "These releases, skipping the beta phases, are quick releases after having fixed most of the security bugs making up a Remote Code Execution (RCE) vulnerability reported some weeks ago and a DoS vulnerability reported somewhat later. I had posted in detail here. The fixes provided by these releases are sufficient to prevent the described exploits, but there is still the bug of arbitrary command lines being allowed to be used by foomatic-rip, CVE-2024-47177, which will get fixed in both the 1.x and 2.x branches of cups-filters in the next days. cups-filters 1.29.0 and 2.1.0 will get released once this fix is in place. libcupsfilters CVE-2024-47076: cfGetPrinterAttributes5() does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker-controlled data to the rest of the CUPS system (GHSA) Fix libppd CVE-2024-47175: ppdCreatePPDFromIPP2() does not validate or sanitize the IPP attributes when writing them to the PPD file, allowing the injection of attacker-controlled data into the resulting PPD (GHSA) Fix cups-browsed CVE-2024-47176: cups-browsed binds on UDP INADDR_ANY:631 trusting any packet from any source to trigger a get-printer-attributes IPP request to an attacker-controlled URL (GHSA) CVE-2024-47850: cups-browsed (before 2.5b1?) will send an HTTP POST request to an arbitrary destination and port in response to a single IPP UDP packet requesting a printer to be added. The request is meant to probe the new printer but can be used to create DDoS amplification attacks (on non-printer devices). This is a different vulnerability than CVE-2024-47176 but the remedy is the same, turning off or removing legacy CUPS browsing support in cups-browsed (GHSA) Preliminary fix turning off CUPS browsing in configuration file
Final fix removing CUPS browsing and LDAP support libcupsfilters Support for building with libcups3, CUPS library of CUPS 3.x. Support for building with libcups of CUPS 2.5.x (Issue #36) CI/build/unit testing of filter functions using a table of test cases, each with input file, input and output formats, option settings, allows especially to create regression test cases based on reported bugs Convert INSTALL to INSTALL.md (Pull request #45) Add GitHub workflow for Canonical Open Documentation Academy OpenPrinting is participating in Canonical's Open Documentation Academy, as an organization in need of documentation. The workflow is still experimental and serves for auto-forwarding documentation-related issues. libppd Support for building with libcups3, CUPS library of CUPS 3.x (Pull request #27) Convert INSTALL to INSTALL.md (Pull request #34) cups-browsed Removed support for legacy CUPS browsing and for LDAP Legacy CUPS browsing is not needed any more and, our implementation accepting any UDP packet on port 631, causes vulnerabilities, and our LDAP support does not comply with RFC 7612 and is therefore limited. Fixes CVE-2024-47176 and CVE-2024-47850 as mentioned above libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion cups-browsed: More Details and Download, Discussion"
+ },
+ {
+ "id": "post:libcupsfilters-and-libppd-Second-Generation-Forth-Beta-Release",
+ "source": "static",
+ "type": "post",
+ "title": "libcupsfilters and libppd Second Generation - Forth Beta Release!",
+ "url": "/libcupsfilters-and-libppd-Second-Generation-Forth-Beta-Release",
+ "headings": [
+ "libcupsfilters",
+ "libppd",
+ "General",
+ "Packages"
+ ],
+ "tags": [],
+ "snippet": "Coverity scans and appropriate fixes, QPDF 11+ compatibility, cupstestppd successor, lots of bug fixes",
+ "content": "Continuing the packaging for Debian, Ubuntu, and Red Hat distributions more bugs got found and fixed. First, Zdenek Dohnal from Red Hat has run all the components of the new generation of cups-filters through Coverity and found several bugs: Memory leaks, files not closed, possible string overflows, ... He fixed all these bugs in the upstream code. This assures reliability and security of all the new components, especially if being part of permanently running daemons. Thanks a lot, Zdenek! During the selection process for contributors for the Google Summer of Code 2023 we give some assignments to the candidates, usually reported bugs, but also other code-related work items which occur at OpenPrinting. This way we got some bugs fixed, from users reporting that their printer does not work in driverless mode or something wrong or nothing comes out as the printout. Especially with one candidate, having gotten assigned a bug report about the PostScript Printer Application not preventing the use of malformed, user-supplied PPD files, we realized that we did not transfer CUPS' valuable command line tool cupstestppd into libppd. This the candidate has done yet, as the library function ppdTest(), easily callable from a PPD-retrofitting Printer Application. libcupsfilters got updated to work with the latest version of QPDF (11) as building it showed a lot of warnings about the use of deprecated functions in QPDF. Now it should be ready for the upcoming QPDF 12. Do not free cf_image_t data structure in _cfImageZoomDelete() (cups-filters issue #507) The library-internal _cfImageZoom...() API does not create the cf_image_t data structure, so it should not free it, to avoid double-free crashes. This made the cfFilterImageToRaster() filter function (imagetoraster CUPS filter) crash. cfImageOpenFP(): Removed leftover HAVE_LIBZ conditionals In the 3rd beta we have removed the dependency on libz from the build system as there is no explicit dependency on it in libcupsfilters. Having forgotten to remove HAVE_LIBZ from the conditionals in cfImageOpenFP() PNG images were rendered as blank pages. See cups-filters issue #465. Compatibility with QPDF 11 and later Replaced deprecated PointerHolder with shared_ptr (PR #13) cfFilterPDFToPDF(): Replaced deprecated QPDF function name replaceOrRemoveKey by replaceKey. Set CXXFLAGS=\"-DPOINTERHOLDER_TRANSITION=0\" to silence QPDF warnings. INSTALL: Explain dependencies (PR #10) Transfer CUPS' cupstestppd utility to ppdTest() library function The valuable tool got forgotten in the first place, now it is available as ppdTest() library function and testppdfile command line utility. The command line utility only gets installed with ./configure called with --enable-testppdfile argument. In auto-generated PPDs do not set RGB default on mono printers (CUPS Issue #614) When a PPD for a driverless printer is generated by the ppdCreatePPDFromIPP() function and the get-printer-attributes IPP response gives \"print-color-mode-default=auto\" the PPD's default setting for \"ColorModel\" is always \"RGB\", even on monochrome printers, which makes printing fail on most devices. Now we ignore the \"print-color-mode-default\" if set to \"auto\". ppdLoadAttributes(): Added NULL check for missing PPD PageSize default Some PPDs, even \"everywhere\" PPDs generated by CUPS for a driverless IPP printer do not have a valid default value for the default page size, like \"Unknown\". Added a NULL check to avoid a crash by such PPD files. testppd: String got freed too early In this test program run by make check a string was used after already gotten freed. Discovered via a compiler warning, but program could have actually crashed. Coverity check done by Zdenek Dohnal for the inclusion of libppd in Fedora and Red Hat. Zdenek has fixed all the issues: Missing free(), files not closed, potential string overflows, ... Thanks a lot! configure.ac: Change deprecated AC_PROG_LIBTOOL for LT_INIT (PR #12) libcupsfilters: More Details and Download, Discussion libppd: More Details and Download, Discussion"
+ },
+ {
+ "id": "post:lprint-1.1.0",
+ "source": "static",
+ "type": "post",
+ "title": "LPrint 1.1.0",
+ "url": "/lprint-1.1.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "LPrint v1.1.0 adds support for EPL and 600dpi ZPL label printers, adds several auto-connfiguration and status reporting improvements, and fixes all known bugs in the previous release.",
+ "content": "LPrint v1.1.0 adds support for EPL and 600dpi ZPL label printers, adds status reporting and automatic label configuration for ZPL label printers, adds auto-setup and test labels for printers, adds system service files for macOS and Linux, and fixes all known bugs in the previous release. Changes include: Switched to PAPPL (Issue #20, #35) Fixed lprint default and lprint delete not working (Issue #17, Issue #40) Fixed server crashes on SIGINT (Issue #18) Fixed the reported date and time information when no printers were added (Issue #26) Fixed a startup bug on macOS (Issue #34) Now support auto-detection of printer drivers and auto-add USB printers the first time LPrint is run. Added the missing macOS binary package (Issue #33) Added launchd and systemd service files for running lprint as a service. Added support for Zebra/Eltron EPL2 printers (Issue #38) Added support for 600dpi ZPL thermal transfer printers. Added support for ZPL status/ready media updates. Added support for test pages. Temporarily removed support for DYMO LabelWriter Wireless printer (Issue #23) Enjoy! Download LPrint 1.1.0 Install lprint Snap Home Page"
+ },
+ {
+ "id": "post:lprint-1.2.0",
+ "source": "static",
+ "type": "post",
+ "title": "LPrint 1.2.0",
+ "url": "/lprint-1.2.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "LPrint v1.2.0 adds support for snap configuration and EPL/ZPL auto-typing support, and fixes a number of bugs.",
+ "content": "LPrint v1.2.0 adds support for snap configuration and EPL/ZPL auto-typing support, and fixes a number of bugs. Changes include: Documentation corrections (Issue #53, Issue #76) Added snap server configuration. Added --with-systemd configure option and install to $prefix/lib/systemd/system by default (Issue #50) Added EPL2 and ZPL auto-typing support (Issue #64) Changed the default log level for systemd to info (Issue #82) Fixed macOS installer to start LPrint server (Issue #48) Fixed configure script not using warning/preprocessor options in build (Issue #60) Fixed printer renaming algorithm to not truncate the name (Issue #60) Fixed missing \"print-color-mode=bi-level\" for bar code printing (Issue #76) Fixed label mode support in EPL and ZPL drivers (Issue #79) Fixed driver names for EPL printers (Issue #52) Enjoy! Download LPrint 1.2.0 Install lprint Snap Home Page"
+ },
+ {
+ "id": "post:lprint-1.3.0",
+ "source": "static",
+ "type": "post",
+ "title": "LPrint 1.3.0",
+ "url": "/lprint-1.3.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "LPrint v1.3.0 adds a new dithering algorithm, support for new printers, support for configuration files, and fixes a number of bugs.",
+ "content": "LPrint v1.3.0 adds a new dithering algorithm, support for new printers, support for configuration files, and fixes a number of bugs. Changes include: Added new dithering algorithm to better support barcode printing with shaded content. Added experimental Brother printer support (Issue #15) Added basic TSPL printer support (Issue #54) Added basic SEIKO printer support (Issue #58) Added experimental Zebra CPCL printer support. Added support for configuration files in \"/etc\", \"/usr/local/etc\", or \"/Library/Application Support\" (macOS). Updated ZPL driver to report 'media-needed' reason when out of labels during a job. Fixed copies support for ZPL printers (Issue #100) Fixed darkness calculations for EPL and ZPL printers (Issue #104) Enjoy! Download LPrint 1.3.0 Install lprint Snap Home Page"
+ },
+ {
+ "id": "post:lprint-1.3.1",
+ "source": "static",
+ "type": "post",
+ "title": "LPrint 1.3.1",
+ "url": "/lprint-1.3.1",
+ "headings": [],
+ "tags": [],
+ "snippet": "LPrint v1.3.1 is a bug fix release.",
+ "content": "LPrint v1.3.1 is a bug fix release. Changes include: Updated \"print-speed\" support in TSPL driver (Issue #120 and #121) Fixed lprint-modify man page (Issue #122 and #126) Fixed snap documentation for connecting LPrint to Avahi. Enjoy! Download LPrint 1.3.1 Install lprint Snap Home Page"
+ },
+ {
+ "id": "post:pappl-1.0.0",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL v1.0.0",
+ "url": "/pappl-1.0.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL is a simple C-based framework/library for developing CUPS Printer Applications, which are the recommended replacement for printer drivers.",
+ "content": "The first stable release of PAPPL is now available for download. PAPPL is a simple C-based framework/library for developing CUPS Printer Applications, which are the recommended replacement for printer drivers. Download PAPPL v1.0.0 Home Page Changes in 1.0.0 include: papplSystemLoadState would not load printers whose device IDs contained the # character (Issue #92) Passing \"auto\" for the driver name would cause a crash if there was no auto- add callback. Added papplPrinterGetPath API to get the path for a printer web page (Issue #97) The papplPrinterAddLink and papplSystemAddLink functions now accept an \"options\" argument instead of the \"secure\" boolean in order to allow links to be added to multiple places on the web interface in addition to requesting a secure (HTTPS) link (Issue #98) Enjoy!"
+ },
+ {
+ "id": "post:pappl-1.1.0",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.1.0",
+ "url": "/pappl-1.1.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.1.0 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10.",
+ "content": "PAPPL v1.1.0 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher. Enjoy! Download v1.1.0"
+ },
+ {
+ "id": "post:pappl-1.1b1",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.1b1",
+ "url": "/pappl-1.1b1",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10.",
+ "content": "The first beta release of PAPPL v1.1 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher. Changes include: Added support for Windows 10 and higher. Added PAPPL_SOPTIONS_NO_TLS option to disable TLS support. Added Wi-Fi callbacks to support configuration over IPP-USB (Issue #45) Added buttons and sub-commands to pause and resume printers (Issue #124) papplMainLoop now uses a persistent location for state and spool files by default (Issue #128) papplMainLoop now supports clients talking to a system-wide server running as root (Issue #148) Added a \"set default\" button to the web interface (Issue #150) The drivers sub-command now reports the IEEE-1284 device ID for a given driver (Issue #157) Jobs can now be canceled and printers deleted when a processing job is trying to connect to a printer (Issue #163) The default media is now updated if the ready media for a given tray is updated (Issue #164) Fixed an issue with the \"drivers\" sub-command not working if you don't have a system callback. Fixed a deadlock issue on macOS. Added a new papplJobCreateWithFile API to allow printer applications to submit print jobs internally. Refactored the papplSystem hostname/port APIs to be consistent with the naming used for the papplClient APIs. Enjoy! Download v1.1b1"
+ },
+ {
+ "id": "post:pappl-1.1b2",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.1b2",
+ "url": "/pappl-1.1b2",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10.",
+ "content": "The second beta release of PAPPL v1.1 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto- add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher. Changes in 1.1b2 include: Added support for papplDeviceGetID with network devices (Issue #95) Added support for the \"compression\" option. Added English names for Tabloid and A3 media sizes in the web interface. Added \"server-hostname\" and \"listen-hostname\" server options to the default mainloop system callback. Fixed support for default printers, added indicator in web interface (Issue #182) Fixed support for printers with spaces in their names. Fixed the \"jobs\" subcommand. Fixed support for page-ranges. Fixed support for printers that do PDF beyond converting it to raster. Fixed support for mainloop subcommands on Windows. Fixed error message when Bonjour for Windows is not installed. Enjoy! Download v1.1b2"
+ },
+ {
+ "id": "post:pappl-1.1b3",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.1b3",
+ "url": "/pappl-1.1b3",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto-add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10.",
+ "content": "The third beta release of PAPPL v1.1 is now available for download. PAPPL v1.1 adds support for Wi-Fi configuration, IPP-USB, printer driver lookup and auto- add functionality, improves management of multiple printers, and adds support for Microsoft® Windows® 10 and higher. Changes in 1.1b3 include: Added a new papplSystemSetAuthCallback API to support alternate authentication mechanisms (Issue #185) Added papplCreateTempFile and papplPrinterOpenFile file creation functions (Issue #186) Added support for a server-options option for the server sub-command (Issue #187) Added an optional callback for processing USB gadget print data. Added papplCopyString, papplGetRand, and papplGetTempDir utility functions. Calling papplSystemSetHostName did not also update the default TLS common name. Now map file:///dev/null to NUL: on Windows. Enjoy! Download v1.1b3"
+ },
+ {
+ "id": "post:pappl-1.2.0",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.2.0",
+ "url": "/pappl-1.2.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.rc1 adds full localization, support for additional IPP features, and some other improvements.",
+ "content": "PAPPL v1.2.0 is now available for download. PAPPL v1.2 adds full localization, support for additional IPP features, and some other improvements. Changes in 1.2.0 include: Added papplMainloopShutdown API to trigger a shutdown of the system that was started by papplMainloop. Fixed mapping of MIME media types to IEEE-1284 Command Set values. Fixed a crash bug when no printers are added. Fixed compatibility issues with libcups3. The macOS menu extra did not update the list of available printers. No longer try to show the macOS menu extra when running from a root launchd service (Issue #201) Enjoy! Download v1.2.0"
+ },
+ {
+ "id": "post:pappl-1.2.1",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.2.1",
+ "url": "/pappl-1.2.1",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.2.1 fixes key issues with localization, client limits, and compilation.",
+ "content": "PAPPL v1.2.1 is now available for download and fixes some key issues with localization, client limits, and compiling against older versions of CUPS. Changes in 1.2.1 include: Fixed a bug in the max-clients support code (Issue #205) Fixed compiler warnings (Issue #206, Issue #207) Fixed corruption in the English localization file. PAPPL didn't compile against CUPS 2.2.6 and earlier. Enjoy! Download v1.2.1"
+ },
+ {
+ "id": "post:pappl-1.2.2",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.2.2",
+ "url": "/pappl-1.2.2",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.2.2 fixes key issues with localization, client limits, and compilation.",
+ "content": "PAPPL v1.2.2 is now available for download and is a general bug fix release. Changes in 1.2.2 include: Added debug logging for device management. Fixed a device race condition with job processing. Fixed a potential value overflow when reading SNMP OIDs (Issue #210) Fixed more CUPS 2.2.x compatibility issues (Issue #212) Fixed a 100% CPU usage bug when cleaning the job history (Issue #218) Fixed the default values of --with-papplstatedir and --with-papplsockdir to use the localstatedir value (Issue #219) Fixed a initialization timing issue with USB gadgets on newer Linux kernels. Enjoy! Download v1.2.2"
+ },
+ {
+ "id": "post:pappl-1.2.3",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.2.3",
+ "url": "/pappl-1.2.3",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.2.3 fixes TLS upgrade, USB device ID, and vendor text option bugs.",
+ "content": "PAPPL v1.2.3 is now available for download and is a general bug fix release. Changes in 1.2.3 include: Fixed a bug in the TLS upgrade logic. Fixed a potential memory underflow with USB device IDs. Fixed web interface support for vendor text options (Issue #142) Enjoy! Download v1.2.3"
+ },
+ {
+ "id": "post:pappl-1.2b1",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.2b1",
+ "url": "/pappl-1.2b1",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.b1 adds full localization, support for additional IPP features, and some other improvements.",
+ "content": "PAPPL v1.2b1 is now available for download. PAPPL v1.2 adds full localization, support for additional IPP features, and some other improvements. Changes include: Added macOS menubar icon/menu (Issue #27) Added support for localization, with base localizations for English, French, German, Italian, Japanese, and Spanish (Issue #58) Added interpolation when printing JPEG images or when using the papplJobFilterImage function with smoothing enabled (Issue #64) Added papplDeviceGetSupplies API to query supply levels via SNMP (Issue #83) Added support for custom media sizes in millimeters (Issue #118) Added papplPrinterGet/SetMaxPreservedJobs API and reprint web interface (Issue #189) Added IPP notifications support with papplSystemAddEvent and papplSubscriptionXxx functions (Issue #191) Added papplPrinterDisable and papplPrinterEnable functions and proper support for the IPP \"printer-is-accepting-jobs\" attribute. Added OpenSSL/LibreSSL support (Issue #195) Added papplSystemGet/SetMaxClients API (Issue #198) Updated papplPrinterSetReadyMedia to support up to PAPPL_MAX_SOURCE media entries, regardless of the number of sources. Enjoy! Download v1.2b1"
+ },
+ {
+ "id": "post:pappl-1.2rc1",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.2rc1",
+ "url": "/pappl-1.2rc1",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.rc1 adds full localization, support for additional IPP features, and some other improvements.",
+ "content": "PAPPL v1.2rc1 is now available for download. PAPPL v1.2 adds full localization, support for additional IPP features, and some other improvements. Changes in 1.2rc1 include: Added explicit support for running macOS printer applications as a server. Added unit test support for the new SNMP-based supply level and status monitoring code. Updated USB gadget code to not enable gadget until system is started or USB options are set. Updated default spool directory to use a persistent, per-user location. Fixed DNS-SD advertising when adding a printer from the web interface. Fixed double \"Supplies\" buttons in the web interface. Fixed human-readable location fields in web interfaces. Fixed an issue with the default system callback for papplMainloop. Fixed an issue with papplDeviceList and DNS-SD discovery when there was no active system. Fixed printer compatibility issues with the new papplDeviceGetSupplies API. Fixed some locking issues with the macOS menubar icon. Enjoy! Download v1.2rc1"
+ },
+ {
+ "id": "post:pappl-1.3.0",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.3.0",
+ "url": "/pappl-1.3.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.3.0 adds new job management, image printing, localization, and configuration features.",
+ "content": "PAPPL v1.3.0 is now available for download and adds new job management, image printing, localization, and configuration features. Changes in 1.3.0 include: Added debug logging for device management. Added support for job hold and release (Issue #15) Added support for PNG image scaling using embedded resolution information (Issue #65) Added papplLocGetDefaultMediaSizeName function to get the default media size for the current country (Issue #167) Added support for localized banners at the top of printer and system web pages (Issue #183) Added timer APIs to manage periodic tasks (Issue #208) Added support for network configuration via callbacks (Issue #217) Added APIs to limit the maximum size of JPEG/PNG images (Issue #224) Added support for the Clang/GCC ThreadSanitizer with the --enable-tsanitizer configure option. Added Norwegian Bokmål, Polish, and Turkish localizations. Added a password visibility button to the Wi-Fi password field. Changed names of PAPPL-specific attributes to use \"smi55357\" prefix. Updated USB device code to generate a 1284 device ID and use the manufacturer and product strings when necessary (Issue #234) Updated the USB gadget code to handle disconnections. Updated PAPPL to conform to the new prototype PWG 5100.13 specification (Issue #216) Fixed a device race condition with job processing. Fixed a initialization timing issue with USB gadgets on newer Linux kernels. Fixed a potential memory underflow with USB device IDs. Fixed web interface support for vendor text options (Issue #142) Fixed a potential value overflow when reading SNMP OIDs (Issue #210) Fixed more CUPS 2.2.x compatibility issues (Issue #212) Fixed a 100% CPU usage bug when cleaning the job history (Issue #218) Fixed the default values of --with-papplstatedir and --with-papplsockdir to use the localstatedir value (Issue #219) Fixed storage of label offsets for printers that implement them. Fixed some thread access issues on ARM. Fixed when the kernel USB printer driver is unloaded on Linux (Issue #233) Fixed papplDevicePrintf to allow the \"%c\" character to be 0. Enjoy! Download v1.3.0"
+ },
+ {
+ "id": "post:pappl-1.3.1",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.3.1",
+ "url": "/pappl-1.3.1",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.3.1 is a general bug fix release.",
+ "content": "PAPPL v1.3.1 is now available for download and is a general bug fix release. Changes in 1.3.1 include: Fixed auto-add of USB printers Updated \"ipp-attribute-fidelity\" support Reduced sleep interval for USB gadget initialization Enjoy! Download v1.3.1"
+ },
+ {
+ "id": "post:pappl-1.3.4",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.3.4",
+ "url": "/pappl-1.3.4",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.3.4 is a general bug fix release.",
+ "content": "PAPPL v1.3.4 is now available for download and is a general bug fix release. Changes in 1.3.4 include: Fixed builds with GNU TLS (Issue #292) Fixed a HTML error on the network configuration page. Changes in 1.3.3 include: Fixed USB serial number for DYMO printers (Issue #271) Fixed DNS-SD advertisements when the server name is set to \"localhost\" (Issue #274) Fixed hostname change detection when using mDNSResponder (Issue #282) Fixed authentication cookie comparisons for simple password mode. Fixed a potential time-of-use issue with PAPPL-created directories. Fixed handling of trailing '%' in log format strings. Updated TLS certificate generation to support more types of certificates and to use modern OpenSSL/GNU TLS APIs. Enjoy! Download v1.3.4"
+ },
+ {
+ "id": "post:pappl-1.3",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.3.2",
+ "url": "/pappl-1.3",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.3.2 is a general bug fix release.",
+ "content": "PAPPL v1.3.2 is now available for download and is a general bug fix release. Changes in 1.3.2 include: Fixed PWG ImageBox values in raster page header Fixed a bug in the \"ipp-attribute-fidelity\" support Fixed printing of 1/2/4-bit grayscale PNG images (Issue #267) Fixed a potential buffer overflow in the logging code (Issue #272) Fixed reporting of \"xxx-k-octet-supported\" attributes. Updated the Wi-Fi configuration page to support hidden networks. Updated the Wi-Fi configuration page reload time to 30 seconds. Enjoy! Download v1.3.2"
+ },
+ {
+ "id": "post:pappl-1.4.0",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.4.0",
+ "url": "/pappl-1.4.0",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.4.0 is a feature release.",
+ "content": "PAPPL v1.4.0 is now available for download and is a feature release. Changes in 1.4.0 include: Added support for \"job-retain-until\" (Issue #14) Added new PAPPL-Create-Printers operation, and the PAPPL mainloop API now auto-adds local printers the first time a server is run (Issue #245) Added new papplDeviceRemoveScheme and papplDeviceRemoveTypes APIs to disable unwanted device types (Issue #259) Added support for suspending and resuming jobs at copy boundaries (Issue #266) Added support for server configuration files (Issue #279) Now preserve the paused state of printers (Issue #286) Fixed reporting of \"xxx-k-octet-supported\" attributes. Fixed printing of 1/2/4-bit grayscale PNG images (Issue #267) Fixed USB serial number for DYMO printers (Issue #271) Fixed a potential buffer overflow in the logging code (Issue #272) Fixed DNS-SD advertisements when the server name is set to \"localhost\" (Issue #274) Fixed hostname change detection when using mDNSResponder (Issue #282) Fixed authentication cookie comparisons for simple password mode. Fixed a potential time-of-use issue with PAPPL-created directories. Fixed handling of trailing '%' in log format strings. Updated the options sub-command to list vendor options and values (Issue #255) Updated web interface to show the age of jobs (Issue #256) Updated \"devices\" sub-command to have the PAPPL server find the devices instead of doing it directly (Issue #262) Updated default logging to be less chatty (Issue #270) Updated the Wi-Fi configuration page to support hidden networks. Updated the Wi-Fi configuration page reload time to 30 seconds. Updated TLS certificate generation to support more types of certificates and to use modern OpenSSL/GNU TLS APIs. Enjoy! Download v1.4.0"
+ },
+ {
+ "id": "post:pappl-1.4.2",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.4.2",
+ "url": "/pappl-1.4.2",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.4.2 is a bug fix release.",
+ "content": "PAPPL v1.4.2 is now available for download and is a bug fix release. Changes include: Fixed potential crash while listing devices (Issue #296) Fixed potential deadlock issue (Issue #297) Fixed loading of previous state (Issue #298) Enjoy! Download v1.4.2"
+ },
+ {
+ "id": "post:pappl-1.4.3",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.4.3",
+ "url": "/pappl-1.4.3",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.4.3 is a bug fix release.",
+ "content": "PAPPL v1.4.3 is now available for download and is a bug fix release. Changes include: Added \"smi55357-device-uri\" and \"smi55357-driver\" Printer Status attributes to Get-Printer-Attributes responses. Fixed missing mutex unlock in DNS-SD code (Issue #299) Fixed \"printer-id\" value for new printers (Issue #301) Fixed DNS-SD device list crash (Issue #302) Fixed Set-Printer-Attributes for \"output-bin-default\" and \"sides-default\" (Issue #305) Fixed default \"copies\" value with papplJobCreateWithFile. Enjoy! Download v1.4.3"
+ },
+ {
+ "id": "post:pappl-1.4.4",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.4.4",
+ "url": "/pappl-1.4.4",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.4.4 is a bug fix release.",
+ "content": "PAPPL v1.4.4 is now available for download and is a bug fix release. Changes include: Fixed \"printer-settable-attributes-supported\" value (Issue #311) Fixed -n support for setting number of copies (Issue #312) Fixed papplPrinterSetDriverDefaults didn't set the \"orientation-requested-default\" value (Issue #313) Fixed job file preservation logic. Fixed builds against current libcups3. Enjoy! Download v1.4.4"
+ },
+ {
+ "id": "post:pappl-1.4.5",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.4.5",
+ "url": "/pappl-1.4.5",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.4.5 is a bug fix release.",
+ "content": "PAPPL v1.4.5 is now available for download and is a bug fix release. Changes include: Fixed --disable-libpam configure option. Fixed support for \"finishings\", \"output-bin\", and \"sides\" options. Fixed IEEE-1284 device ID generation code. Fixed crash in retrofit printer application (Issue #322) Fixed some Coverity-detected threading issues. Enjoy! Download v1.4.5"
+ },
+ {
+ "id": "post:pappl-1.4.6",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.4.6",
+ "url": "/pappl-1.4.6",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.4.6 is a bug fix release.",
+ "content": "PAPPL v1.4.6 is now available for download and is a bug fix release. Changes include: Fixed reporting of \"printer-strings-languages-supported\" attribute (Issue #328) Fixed saving of \"print-darkness-default\" and \"print-speed-default\" values (Issue #330 and #337) Fixed incoming \"raw\" print socket support (Issue #331 and #338) Fixed web interface support for \"printer-darkness\" (Issue #333) Fixed some issues discovered by OpenScanHub (Issue #335) Fixed localization of command-line (main loop) interface. Enjoy! Download v1.4.6"
+ },
+ {
+ "id": "post:pappl-1.4.7",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.4.7",
+ "url": "/pappl-1.4.7",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.4.7 is a bug fix release.",
+ "content": "PAPPL v1.4.7 is now available for download and is a bug fix release. Changes include: PAM-based authentication did not work on Linux due to a glibc incompatibility (Issue #343) Fixed the web interface for setting the admin and print groups (Issue #356) Fixed the web interface for adding network printers on non-standard port numbers (Issue #360) Fixed some USB gadget error conditions. Fixed the Wi-Fi configuration web page. Fixed a logging deadlock issue. Fixed some threading issues. Fixed how PAPPL responds to an unsupported request character set. Fixed the \"no-tls\" server option. Enjoy! Download v1.4.7"
+ },
+ {
+ "id": "post:pappl-1.4.8",
+ "source": "static",
+ "type": "post",
+ "title": "PAPPL 1.4.8",
+ "url": "/pappl-1.4.8",
+ "headings": [],
+ "tags": [],
+ "snippet": "PAPPL v1.4.8 is a bug fix release.",
+ "content": "PAPPL v1.4.8 is now available for download and is a bug fix release. Changes include: SECURITY: The web interface password didn't work properly (Issue #373) Now use the \"listen-hostname\" hostname as system hostname if a name is specified (Issue #369) Enjoy! Download v1.4.8"
+ },
+ {
+ "id": "post:pappl-retrofit-First-Beta-Release",
+ "source": "static",
+ "type": "post",
+ "title": "pappl-retrofit - First Beta Release!",
+ "url": "/pappl-retrofit-First-Beta-Release",
+ "headings": [],
+ "tags": [],
+ "snippet": "pappl-retrofit 1.0b1 - Library for converting classic CUPS drivers/PPD files into Printer Applications",
+ "content": "This is the first beta release of the upcoming pappl-retrofit 1.0.0. This is a library to convert classic CUPS drivers, consisting of PPD files, CUPS filters, and sometimes also CUPS backends, into Printer Applications, the new format of printer drivers, mainly for CUPS 3.x which goes all-IPP and does not support the PPD/filter concept for printer drivers any more. Printer Applications are emulations of driverless IPP printers which on their other end pass on the jobs to the actual printer. pappl-retrofit uses PAPPL, library for Printer Applications, as its base, and so it does not need to care of the general functionality of Printer Applications. So it only contains the code to adapt classic CUPS drivers and PPD files into the Printer Application framework. To support as many classic drivers as possible pappl-retrofit supports all kinds of PPD files, with and without specification of a CUPS filter, installable accessory settings, CUPS extension for custom option values, *.drv PPD compiler files, PPD-file-generating executables, CUPS filters, CUPS backends, side and back channels for filter/backend communication, pre-filtering from the driverless-IPP-standard input formats to the input formats of the driver filters. pappl-retrofit also comes with the Legacy Printer Application, which when it is classically (not as Snap or other container) installed sees all classically installed CUPS drivers on the system and maps them into its IPP printer emulation, so that CUPS 3.x can make use of all these drivers. This way the user does not loose their old printer drivers on the transition to CUPS 3.x, which is especially important for (often proprietary) drivers from printer manufacturers. As this library was developed along with the 4 retro-fitting Printer Applications for PostScript, Ghostscript, HPLIP, and Gutenprint as the base for them, it has grown with these applications and contains all functionality they need. It has also grown with PAPPL, getting support for PAPPL's newest features. So we are not releasing now because we completed a pre-planned feature list but rather to have releases of this package and the Printer Applications for their easier adoption into Linux distributions. With this we will also version the Printer Application Snaps in the Snap Store, so that when distributions adopt them as their default printer drivers, they can also better manage their customer support. Feature-wise we are even not 100% complete. We will still add ink level read-out from the printer (SNMP-based network printers, same as supported by CUPS) and internationalization, but this will not cause any compatibility-breaking API changes. More Details and Download GitHub Discussion"
+ },
+ {
+ "id": "post:pappl-retrofit-Second-Beta-Release",
+ "source": "static",
+ "type": "post",
+ "title": "pappl-retrofit - Second Beta Release!",
+ "url": "/pappl-retrofit-Second-Beta-Release",
+ "headings": [],
+ "tags": [],
+ "snippet": "pappl-retrofit 1.0b2 - Fix issues in source code docs and allow installation of Legacy Printer Application as permanently running system daemon.",
+ "content": "This is the second beta release of the upcoming pappl-retrofit 1.0.0, to fix some issues in the source code documentation and to allow installation of the Legacy Printer Application as a permanently running system daemon. Support for Legacy Printer Application as system daemon We have added a systemd *.service file and an install mode for installing the Legacy Printer Application as system daemon. The mode is triggered by the --enable-legacy-printer-app-as-daemon option for ./configure. Then the *.service file gets installed and the executable legacy-printer-app gets installed into /usr/(local/)sbin/. README.md: Updated TODOs and fixed minor glitches Especially the PAPPL development got already far enough for localization and ink level reporting support, so that we do not need to tell any more that we are waiting for further the devlopment of PAPPL. CONTRIBUTING.md: Updated text to reflect pappl-retrofit COPYING, NOTICE: Fixed copyright year 2023 and simplified the file based on the fact that one can assign the package's license to all autotools-generated files. Adapted DEVELOPING.md to the pappl-retrofit API, it was still reflecting the CUPS API (file was copied over from CUPS. Removed _prDefaultPaperSize() from pappl-retrofit-private.h. The function got removed when PAPPL had introduced papplLocGetDefaultMediaSizeName() which replaces this functionality. More Details and Download GitHub Discussion"
+ },
+ {
+ "id": "post:pycups-2.0.3",
+ "source": "static",
+ "type": "post",
+ "title": "Pycups 2.0.3",
+ "url": "/pycups-2.0.3",
+ "headings": [],
+ "tags": [],
+ "snippet": "Pycups 2.0.3 contains changes related to deprecations and removals in newer Python3 versions.",
+ "content": "pycups 2.0.3 contains changes from 2.0.2 - mainly changes related to newer Python3 versions: removed shebang from example/cupstree.py ignore driverless utilities for postscriptdriver tags creation (Fedora bug #1873385) remove epydoc from Makefile (#27) fix invalid delete of pointer (#11) Makefile uses wrong Python (#32) define PY_SSIZE_T_CLEAN in cupsipp.h - fixes traceback during IPPRequest.writeIO with Python 3.10 fix the test.py when there is no printer installed (#46) Use PyObject_Call() instead of deprecated PyEval_CallObject() Version 2.0.3 was created to attempt to fix pycups installation via pip, but it was unsuccessful. Enjoy! Download Pycups v2.0.3 Home Page"
+ },
+ {
+ "id": "post:pycups-2.0.4",
+ "source": "static",
+ "type": "post",
+ "title": "Pycups 2.0.4",
+ "url": "/pycups-2.0.4",
+ "headings": [],
+ "tags": [],
+ "snippet": "Pycups 2.0.4 hotfix release",
+ "content": "The hotfix release removes install_requires from setup.py, which is used for generating OS requirements. Enjoy! Download Pycups v2.0.4 Home Page"
+ },
+ {
+ "id": "post:pyppd-1.1.0-released",
+ "source": "static",
+ "type": "post",
+ "title": "pyppd 1.1.0 released!",
+ "url": "/pyppd-1.1.0-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Vastly reduced memory consumption when extracting a PPD file and incorporated the patches of the Debian/Ubuntu package",
+ "content": "Vastly reduced memory consumption when extracting a PPD file and incorporated the patches of the Debian/Ubuntu package When extracting a PPD file from the archive streaming decompression is used now instead of decompressing the whole archive into memory at once (Issue #2), Thanks to Sambhav Dusad (@dsam82). Use JSON dumps instead of Pickle dumps, from Ubuntu/Debian to make archive reproducible, but also faster than Pickle dumps. Thanks to Didier Raboud (@OdyX). Sort PPD list before archiving, from Ubuntu/Debian to make archive reproducable. Thanks to Didier Raboud (@OdyX) Use \"python3\" in shebangs, from Debian/Ubuntu More Details and Download"
+ },
+ {
+ "id": "post:system-config-printer-1.5.16-released",
+ "source": "static",
+ "type": "post",
+ "title": "system-config-printer 1.5.16 released!",
+ "url": "/system-config-printer-1.5.16-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Release covering one year of bug fixes, translations, and updated README.md",
+ "content": "Release covering one year of bug fixes, translations, and updated README.md updates in README.md: build/install instructions, changes related to s-c-p with CUPS 3.x (IPP services/Printer Applications, no PPDs/drivers/static queues), TODOs, need of new developer(s) fix preserve_job_files default settings add debugprint covering failed fingerprint retrieval attempts Remove travis .travis.yml: run on focal and its newer python Make sure that applet.py is running one instance per user fix incorrect use of urllib.request remove python3-requests build: Migrate build system from Intltool to Gettext Makefile.am: Remove zanata usage udev-configure-printer.c: Fix possible use after frees and leaks scp-dbus-service.py: Fix typo in method call add option to disable xmlto manual generation allow + in device uris - gutenprint has a backend with + (fixes #208) tons of translations More Details and Download"
+ },
+ {
+ "id": "post:system-config-printer-1.5.17-released",
+ "source": "static",
+ "type": "post",
+ "title": "system-config-printer 1.5.17 released!",
+ "url": "/system-config-printer-1.5.17-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "Release covering half a year of bug fixes and translations",
+ "content": "Release covering half a year of bug fixes and translations Migrate from deprecated splittype to urlparse (#268) Support GNOME 42 dark style preference (#263) More Details and Download"
+ },
+ {
+ "id": "post:system-config-printer-1.5.18-released",
+ "source": "static",
+ "type": "post",
+ "title": "system-config-printer 1.5.18",
+ "url": "/system-config-printer-1.5.18-released",
+ "headings": [],
+ "tags": [],
+ "snippet": "system-config-printer-1.5.18 brings fix for application crash if libhandy is not installed and other fixes",
+ "content": "system-config-printer-1.5.18 brings fix for application crash if libhandy is not installed, which crashes the application on non-GNOME desktops, and other fixes, the complete list is here: Add
[2] CUPS Snap
[3] PAPPL
[4] Tutorial to Design Printer Drivers
[5] Tutorial to Design Scanner Drivers
[6] Packaging Drivers and Uploading them to Snap Store
[7] User Manual
[8] CUPS Filters"
+ },
+ {
+ "id": "documentation:02-designing-printer-drivers",
+ "source": "static",
+ "type": "documentation",
+ "title": "Designing Printer Drivers",
+ "url": "/documentation/02-designing-printer-drivers",
+ "headings": [
+ "papplMainLoop",
+ "Version number",
+ "Autoadd Callback",
+ "Sub-command name",
+ "Data"
+ ],
+ "tags": [],
+ "snippet": "This document contains a complete tutorial as well as information for manufacturers with examples for designing printer drivers. If you are looking for information regarding the...",
+ "content": "This document contains a complete tutorial as well as information for manufacturers with examples for designing printer drivers. If you are looking for information regarding the use of printer drivers, kindly refer to User Manual A driver is a code or data specific to a certain model or group of hardware devices, needed to make the hardware work with the hardware-model-independent code of the operating system. Printing in Linux has moved towards Driverless Printing, which means there is no need for any hardware-model-specific code or data. However, there are some problems with the current framework. For example, some printers(especially the old ones) that cannot handle IPP requests are devoid of driverless printing capability. Printer Applications help to address these issues. Kindly refer Printer Applications - A new way to print in Linux to learn more about Printer Applications, its working and benefits. For Designing the Printer Application Driver, it would be a lot of re-inventing the wheel if everyone who wants to create a printer driver has to implement all things from scratch. Therefore Michael Sweet has developed PAPPL, a library that provides all the common functionality which is required in every Printer Application. The flowchart below mentions the components of the driver that needs to be designed by you (boxes in blue color), along with the PAPPL utilities (boxes in red color) that would be used by your designed components. Flowchart The following tutorial helps you to understand how to design each component and integrate the PAPPL Utilities to reduce your work. papplMainLoop is the main entry point for the application. It runs a standard main loop with a system callback. Also allows the printer application to define its own usage callback and have an application specific subcommand. The papplMainloop function runs until all processing for the current sub-command is complete, returning the exit status for the program. Before looking at the arguments, you must be aware that there are two ways to configure the papplMainloop: Use system callback argument The system is an object of type pappl_system_t that manages client and device connections, listeners, the log, printers, and resources. In addition, it provides an optional embedded web interface, raw socket printing, and USB printer gadget (Linux only). The system callback argument specifies a function that will create a new system, i.e. a pappl_system_t object. You can use the callback function to customisably configure system properties using the PAPPL System Utilities. This includes configuring Footer HTML on your web interface and setting up drivers. You can refer designing system callback guidelines for retrieving more information about the System Callback function. Without system callback function PAPPL allows the manufacture to refrain from the hardships of designing a system callback to create a system. You can specify the system callback as NULL and pass on only a few arguments: Footer HTML Number of drivers Drivers Driver Callback If the \"system_cb\" argument is passed as NULL, PAPPL automatically sets up the list of drivers passed as \"drivers\" arguments and add the Footer HTML for the web interface (in \"footer\" argument is not NULL). A default system object is created for the printer application, which supports multiple printers and a web interface. The argc and argv arguments for papplMainLoop are those provided to the main function. Other arguments are given below. This argument is simply a string literal, denoting the numeric version of the printer driver that conforms to semantic versioning guidelines with up to four numbers, for example \"1.2.3.4\" Examples of valid version number are \"1.0\", \"2.1\", etc. The \"footer_html\" argument can be provided to override the default footer text that appears at the bottom of the web interface. As mentioned above, you can pass this argument as NULL and add the footer in system callback function. If system callback and \"footer_html\" argument both are NULL the default is used. The \"num_drivers\" argument specifies the number of drivers for printers. Specify 0 if the drivers are configured in the system callback. The drivers list is a collection of names, descriptions, IEEE-1284 device IDs, and extension pointers. You can pass this argument as NULL if the drivers are configured in the system callback. A valid example for HP DeskJet, HP LaserJet, and a generic PCL driver, looks like this: The driver callback is responsible for providing the data associated with each driver and is called when the system is creating a new printer. It also responsible for letting the application know what functions to call when performing job functions like starting a job, starting a page, writing a line, ending a page, ending a job, printing a raw job, etc. You can pass this argument as NULL if the drivers are configured in the system callback. Else, for designing the driver callback function, refer to the design driver callback guidelines. The \"autoadd_cb\" argument specifies a callback for automatically adding new printers with the \"autoadd\" sub-command. It tells PAPPL which driver to use for the printers it finds. This argument is a string literal that denotes the additional custom sub-command supported by your printer driver. By default, PAPPL helps each driver to support the following sub-commands: add cancel default delete devices drivers jobs modify options printers server shutdown status submit If your printer doesn't support any additional custom sub-command, you may specify the argument as NULL. This callback argument is the function that is to be executed when the sub-command(other than the default sub-commands) is specified. Since each driver is not bound to support additional sub-command, one may specify this argument as NULL in case the printer driver does not support any additional sub-command. If you wish to support additional sub-command, then specify the name of the sub-command in the sub-command name argument and design a function using the design sub-command callback guidelines. The System Callback function creates a system object and allows restoring the previous system configuration(if any). Kindly refer to the Design system callback guidelines for retrieving more information about the System Callback function. This function helps the user to know about the capabilities of your printer by showing the set of sub-commands and options supported by your printer. For retrieving the output of this function, the user needs to pass the --help argument. One may specify the usage callback argument as NULL in the papplMainloop function. The default function is utilized in this situation. The default function shows the default list of sub-commands and options. The output of the default usage callback function is shown below. If your printer supports only the default set of sub-commands, you can use the default usage callback function. If you wish to output different information when the user uses --help command-line argument, follow the designing usage callback function guidelines. This argument is a string literal and provides the application-specific data for any of the callback functions. The usage callback function receives only one argument, i.e. the callback data. The function objective is to show the usage details of the printer. Hence, the design guidelines for this function is quite trivial. It consists of a series of printf statements describing each supported sub-command and option. It can then return. This function allows the printer application to have an application-specific subcommand. The Sub-Command callback function receives six arguments Basename, Number of options, Options, Number of files, Name of files, and Callback data. It then returns a new sub-command object. The system callback function receives three arguments Number of options, Options, and Callback data. It then returns a new system object. Design Guidelines: Declare Objects and Variables The following objects and variables have to be declared: | DataType | Variable Name | Significance | |------------------|---------------|----------------------| | pappl_system_t* | system | System object | | char* | val | Current option value | | char* | hostname | Hostname | | char* | logfile | Log file | | char* | system_name | System name | | char* | spooldir_name | spool-directory | | char* | authservice | auth-service || pappl_loglevel_t | loglevel | Log level | | int | port | Port number | | pappl_soptions_t | soptions | System options | | pappl_version_t | versions | Software versions | | Note | |--------------------------------------------------------------------------------------------------------------------------------------------| |Naturally, you can define other names for variables. We have assumed them as given in the table to reduce ambiguity in the subsequent steps.| Fetch values using cupsGetOption From the above listed objects/variables, the following variables can get their values from corressponding option name, using cupsGetOption PAPPL utility: | Variable Name | Option name | |---------------|-----------------| | loglevel | log-level | | logfile | log-file | | hostname | server-hostname | | system_name | system-name | | port | server-port | The syntax for using cupsGetOption is: Notes: The return type for cupsGetOption utility is char*. Hence for \"log-level\" and \"server-port\" options, first fetch them into the val variable. The values taken by loglevel variable based on value returned by \"log-level\" cupsGetOption can be summarised using the following table: | log-level Option | Value for loglevel variable | |------------------|-----------------------------| | fatal | PAPPL_LOGLEVEL_FATAL | | error | PAPPL_LOGLEVEL_ERROR | | warn | PAPPL_LOGLEVEL_WARN | | info | PAPPL_LOGLEVEL_INFO | | debug | PAPPL_LOGLEVEL_DEBUG | The port variable can be retrived from \"server-port\" option using atoi function. Don't forget to add a check for the port number. It must be between 0 to 65535(both inclusive). Create a system using papplSystemCreate The variables defined and fetched above are passed to papplSystemCreate utility to create a system. The system is an object of type pappl_system_t that manages client and device connections, listeners, the log, printers, and resources. It implements a subset of the IPP System Service (PWG 5100.22) with each printer implementing IPP Everywhere™ (PWG 5100.14) and some extensions to provide compatibility with the full range of mobile and desktop client devices. In addition, it provides an optional embedded web interface, raw socket printing, and USB printer gadget (Linux only). The soptions variable is passed as the first argument, which is an bitwise ORed of the following options: | System Option | Significance | |:---------------------------:|:------------------------------------------------------------------:| | PAPPL_SOPTIONS_DNSSD_HOST | Use hostname in DNS-SD service names instead of serial number/UUID | | PAPPL_SOPTIONS_LOG | Include link to log file | | PAPPL_SOPTIONS_MULTI_QUEUE | Support multiple printers | | PAPPL_SOPTIONS_NETWORK | Include network settings page | | PAPPL_SOPTIONS_NONE | No options | | PAPPL_SOPTIONS_RAW_SOCKET | Accept jobs via raw sockets | | PAPPL_SOPTIONS_REMOTE_ADMIN | Allow remote queue management (vs. localhost only) | | PAPPL_SOPTIONS_SECURITY | Include user/password settings page | | PAPPL_SOPTIONS_STANDARD | Include the standard web pages | | PAPPL_SOPTIONS_TLS | Include TLS settings page | The system_name variable fetched in 2nd Step is passed as second argument. Note that the system-name might be NULL. So, don't forget to add a check and pass a default value, in case the fetched system-name is NULL. The port number is passed as the third argument. You may pass it as 0 for auto. The 4th argument is a string literal that signifies DNS-SD sub-types. One may pass NULL for none. Pass the spooldir, logfile and loglevel variable fetched in 2nd Step as fifth, sixth and seventh argument respectively. You can pass NULL for the fifth and sixth arguments for default values. The 8th argument signifies the PAM authentication service. You may pass auth_service variable fetched in 2nd Step or NULL for none. If the system only supports TLS connection, pass true in the 9th argument, else false. Add system configurations The system object has tons of configurable attributes and correspondingly a huge number of PAPPL utilities to configure them. These include utilities like Setting Hostname, Setting the footer HTML for the web interface, etc. A detailed list of these function can be found at PAPPL System Utilities. Call the Driver setup function Pass the system object created in previous steps as an argument to the Driver setup function. See the design guidlines for knowing about the Driver setup function. Return System Object The system object created and set up in the previous steps is returned in this step. This function defines the list of printer drivers and driver callback function. The Driver setup function receives only one argument, i.e. system object. Design Guidelines: Define Drivers name and description Create two arrays of string literals, one for the names of the drivers and the other for their corresponding descriptions. Initialise them suitably and use as directed in 2nd Step. Call papplSystemSetPrintDrivers The received pappl_system_t object is passed as the first argument. Pass the number of drivers as the second argument The defined driver name and description array are passed as the third and fourth arguments respectively. Pass the Driver Callback Function as fifth argument. Pass the callback data as the 6th argument. This function tells the printer application what functions to call when performing job functions like starting a job, starting a page, writing a line, ending a page, ending a job, printing a raw job. Driver capability information and defaults(such as resolution, color, etc.) are also provided here. The callback function receives six arguments System object, Driver name, Device URI, Driver data, Driver Attributes, and Callback data. It then returns either true on success or false on failure. Design Guidelines: Add suitable checks You may check that the passed values of driver_name, device_uri, driver_data, and data variable is non-NULL. Further, you must verify that the callback data is the same as the data variable. Assign values to common driver_data members All the required information is stored in the pappl_pdriver_data_t [1] structure. These are a few examples of common driver attributes. For the entire list of attributes that can be provided, please look at the pappl_pdriver_data_t [1] structure. | Member | Significance | |--------------------|------------------------------------------------------| | identify | Identify-Printer function | | identify_default | \"identify-actions-default\" values | | identify_supported | \"identify-actions-supported\" values | | print | Print (file) function | | rendjob | End raster job function | | rendpage | End raster page function | | rstartjob | Start raster job function | | rstartpage | Start raster page function | | rwrite | Write raster line function | | status | Status function | | format | Printer-specific format | | orient_default | \"orientation-requested-default\" value | | quality_default | \"print-quality-default\" value | Assign rest of the values driver_data members based on driver_name Here is the list of all the attributes of pappl_pdriver_data_t structure, used to describe driver capability information and defaults. The ones that were not assigned in the previous step may be assigned depending on the name of the driver. | Member | Significance | |-------------------------------|-----------------------------------------------------| | bin[PAPPL_MAX_BIN] | Output bins | | bin_default | Default output bin | | borderless | Borderless margins supported? | | bottom_top | Bottom and top margins in hundredths of millimeters | | color_default | \"print-color-mode-default\" value | | content_default | \"print-content-default\" value | | darkness_supported | printer/print-darkness-supported (0 for none) | | duplex | Duplex printing modes supported | | features[PAPPL_MAX_VENDOR] | \"ipp-features-supported\" values | | finishings | \"finishings-supported\" values | | force_raster_type | Force a particular raster type? | | format | Printer-specific format | | gdither | , 'text', and 'graphic' dither array | | icons[3] | \"printer-icons\" values | | identify | Identify-Printer function | | identify_supported | \"identify-actions-supported\" values | | kind | \"printer-kind\" values | | make_and_model[128] | \"printer-make-and-model\" value | | media[PAPPL_MAX_MEDIA] | Supported media | | media_ready[PAPPL_MAX_SOURCE] | Ready media | | mode_supported | label-mode-supported | | num_bin | Number of output bins | | num_features | Number of \"ipp-features-supported\" values | | num_media | Number of supported media | | num_source | Number of media sources (trays/rolls) | | num_type | Number of media types | | num_vendor | Number of vendor attributes | | orient_default | \"orientation-requested-default\" value | | output_face_up | Does output media come out face-up? | | pdither | dither array | | ppm_color | \"pages-per-minute-color\" value, if any | | print | Print (file) function | | quality_default | \"print-quality-default\" value | | raster_types | \"pwg-raster-document-type-supported\" values | | rendjob | End raster job function | | rendpage | End raster page function | | rstartjob | Start raster job function | | rstartpage | Start raster page function | | rwrite | Write raster line function | | scaling_default | \"print-scaling-default\" value | | sides_default | \"sides-default\" value | | source[PAPPL_MAX_SOURCE] | Media sources | | speed_default | print-speed-default | | status | Status function | | tear_offset_supported[2] | label-tear-offset-supported (0,0 for none) | | top_offset_supported[2] | media-top-offset-supported (0,0 for none) | | tracking_supported | media-tracking-supported | | type[PAPPL_MAX_TYPE] | Media types | | vendor[PAPPL_MAX_VENDOR] | Vendor attribute names | | y_default | Default resolution | Difference between print and write function Both the print and write functions execute a similar task, but they are invoked by the printer application in a different situation. If the printer-specific format, i.e. the format which is understood by the printer and the format of the Job supplied is the same, then the print function is invoked. One may rightly guess that this is the case of raw print since no format conversion or processing is required. In the other case, the write function is used. This is complemented using other functions such as rstartpage, rendpage, rstartjob, and rendjob. rwriteVSrprint The function helps to identify a printer using display, flash, sound, or speech. The Identify function receives three arguments that are the Printer, Actions to take, and Messages (if any). The Identification methods are summarised in the table: | Identification Method | Action | |--------------------------------|--------------------------------| | PAPPL_IDENTIFY_ACTIONS_SOUND | Make a sound | | PAPPL_IDENTIFY_ACTIONS_DISPLAY | display a message (argument) | | PAPPL_IDENTIFY_ACTIONS_SPEAK | speak a message (argument) | | PAPPL_IDENTIFY_ACTIONS_FLASH | flashes a light on the printer | It is used to print a raw job (printer-ready) file, i.e. if the job format is the same as the format specified by the driver callback. The Print function receives three arguments that are Job, Job Options, and device. The \"job\" argument provides the current job object. The \"options\" pointer provides the current print job options. The \"device\" argument is a pointer used to send data to the printer. The function returns true on success and false on failure. This callback will sometimes send some printer initialization commands followed by the job file and then any cleanup commands. It may also be able to count the number of pages (impressions) in the file, although that is not a requirement. This function is called at the end of each page where the driver will typically eject the current page. The End Job function receives three arguments that are Job, Job Options, and device. The \"job\" argument provides the current job object. The \"options\" pointer provides the current print job options. The \"device\" argument is a pointer used to send data to the printer. The function returns true on success and false on failure. Note that the job data set by Start Job Function must be freed in this function. This function is called each time a page is completed. It helps in resetting the buffers used by the driver. The End Page function receives four arguments that are Job, Job Options, Device, and Page Number. The \"job\" argument provides the current job object. The \"options\" pointer provides the current print job options. The \"device\" argument is a pointer used to send data to the printer. The \"page\" argument specifies the current page number staring at 0. The function returns true on success and false on failure. This function is called at the beginning of a job to allow the driver to initialize the printer for the current job. The Start-Job function, like the End Job Function, receives three arguments that are Job, Job Options, and device. The \"job\" argument provides the current job object. The \"options\" pointer provides the current print job options. The \"device\" argument is a pointer used to send data to the printer. The function returns true on success and false on failure. This function is called when starting a page to allow the driver to do any per-page initialization and/or memory allocations and send any printer commands that are necessary to start a new page. Information regarding the page is obtained from the page header and attributes like resolution, margins, page size, orientation, and graphics are set appropriately. The Start Page function receives four arguments that are Job, Job Options, Device, and Page Number. The \"job\" argument provides the current job object. The \"options\" pointer provides the current print job options. The \"device\" argument is a pointer used to send data to the printer. The \"page\" argument specifies the current page number staring at 0. The function returns true on success and false on failure. This function writes a line of graphics and is called for each raster line on the page. It is typically responsible for dithering and compressing the raster data for the printer. The Write Line function receives five arguments that are Job, Job Options, Device, Line number, and Line. The \"job\" argument provides the current job object. The \"options\" pointer provides the current print job options. The \"device\" argument is a pointer used to send data to the printer. The \"y\" argument specifies the current line number. The \"pixels\" argument is a pointer to the content of current line. The function returns true on success and false on failure. The PAPPL status callback is used to update the printer state, supply levels, and/or ready media for the printer: The Printer Status Function receives only one argument and that is the printer. It returns true on success and false on failure. The callback can open a connection to the printer using the papplPrinterOpenDevice function. Currently, PAPPL supports only raster printers and that too for very few specific input formats like JPEG and PNG. For adding support for non-raster printers like PDF and PostScript printers, you need to supply an external utility that converts the whole job's data into a data stream which the printer understands. Refer to the below-mentioned steps to know how to implement the same. Set the printer-specific format in callback function. You need to set driver_data.format in callback function to the printer-specific format, i.e. the format/language accepted by the printer. A few examples could be \"application/postscript\", \"application/pdf\", etc. Add a filter callback You need to add filter callback from format received by the printer application(formats which you wish your printer can support and accept the job in) to printer-specific format(format/languages that the printer actually understands) using papplSystemAddMIMEFilter utility. | Parameter | Significance | |-----------|-----------------------------------------------| | system | System | | srctype | Source MIME media type (constant) string | | dsttype | Destination MIME media type (constant) string | | cb | Filter callback function | | data | Filter callback data | This utility is added in system callback after calling setup function in Step 5. The filter callback function converts the whole job's data into a data stream which the printer understands. The filter callback function receives 3 parameters, that are the Job, the Device, and the Filter data. Depending upon the features, stability, ease of use, documentation, pricing, and license you may use any third party API to perform this task of conversion. The default filter callback function added in PAPPL are _papplJobFilterJPEG and _papplJobFilterPNG which can be found in the file Job-Filter.c and can be referenced for writing your own callback function. 1 Printer/Scanner Application = 1 Snap: Don't make a Snap which contains tons of different printer and scanner applications. This is to ensure that you don't occupy lots of ports and network resources when you have many printer and scanner applications. Printer/Scanner/Fax support can be in a single application: To support multi-function devices you can put all the printer, scanner, and fax support into one application. For example, we recommend HPLIP to be put into one single application. Recommended: 1 Printer/Scanner Application per project or manufacturer/product line: It may be possible that a multi-function device may be served by different applications for printing and scanning. For example for legacy devices, scanning may be supported by retrofitted sane-airscan scanner application while printing is supported by the Gutenprint printer application. But here it is easier and better for the project, organization, and management that each project has its own printer/scanner application snap. So SANE will maintain a SANE scanner application snap and they put it on the Snap Store. Similarly, Gutenprint, HPLIP, foo2zjs, Epson, Canon, Ricoh, and so on will do the same. NOT make 1 Printer/Scanner Application for each device: For example, HP Laserjet 4 and HP Laserjet 5 should not have different applications. Otherwise, Snap Store will be cluttered with thousands of applications, and spotting the real application would be difficult. Also, it would result in a lot of code duplication, requiring more storage on the user's machine. 1 Printer/Scanner Application = 1 Port: If there are several devices connected to the system and they are served by one printer/scanner application, do not open ports for each device. Because you may run out of ports. Also, ports are not always the same on each boot as other applications may start up before on the next boot. For more than 1 device on 1 Application use URI: ipp://localhost:
[2] HP Printer App Example
[3] PAPPL
[4] PAPPL System Utilities
[5] Packaging Drivers and Uploading them to Snap Store
[6] User Manual
[7] PS Printer App Example"
+ },
+ {
+ "id": "documentation:03-designing-scanner-drivers",
+ "source": "static",
+ "type": "documentation",
+ "title": "Designing Scanner Drivers",
+ "url": "/documentation/03-designing-scanner-drivers",
+ "headings": [
+ "Introduction",
+ "How a PAPPL-based Scanner Driver should work",
+ "Designing Components",
+ "Example for PAPPL-based Scanner Driver",
+ "Template for PAPPL-based Scanner Driver",
+ "Design Guidelines",
+ "Resources"
+ ],
+ "tags": [],
+ "snippet": "Currently PAPPL only provides framework for Printer Applications. The codebase is currently under development and will be expanded in a future version of PAPPL to incorporate...",
+ "content": "Currently PAPPL only provides framework for Printer Applications. The codebase is currently under development and will be expanded in a future version of PAPPL to incorporate Multi Function Printer (MFP) functionalities such as scanning. This document contains information for manufacturers for designing scanner drivers. Note that since the codebase is still under development, the document describes things as planned to be executed. In case of any changes, it will be updated as soon as possible. Also a complete tutorial along with examples will be provided after the support for MFP functionality is released. A driver is code or data specific to a certain model or group of hardware devices, needed to make the hardware work with the hardware-model-independent code of the operating system. Printing in Linux has moved towards Driverless Printing and so does Scanning, which means there is no need for any hardware-model-specific code or data. Kindly refer to Tutorial to Design Printer Drivers to know more about Printer Applications and their designing. Designing Scanner Applications is very similar and expects the manufacturers to use the PAPPL framework to reduce their effort in implementing all things from scratch.. PAPPL provides support for the below-mentioned sub-commands by default: add cancel default delete devices drivers jobs modify options printers scan server shutdown status submit Once the User issues any of the following sub-commands, the printer/scanner application converts these commands (or corresponding IPP requests) into the necessary USB/network/etc. communication to perform a scan, get capabilities, and so forth. In the class of device that we are supporting with PAPPL, the scanner will only produce raster data. It might provide native TIFF support, but that is probably all about it. PDF for example is not supported. The PAPPL scan interface should pull image data for the current page in one of three formats: 1-bit grayscale, 8-bit grayscale, and 24-bit sRGB. It will then be up to PAPPL to deliver the pages to the Client in PNG, JPEG, TIFF, or PDF format. For PNG and JPEG, each page is a separate document in the scan job. For TIFF and PDF, a single document is generated and streamed to the Client in response to the Get-Next-Document-Data operation. The scanner interface returns a single page at a time as uncompressed (or losslessly compressed) data, and PAPPL will convert that to a handful of formats requested by the Client. In the case of IPP Scan, PDF and JPEG are required and PAPPL should support PNG for lossless compression of single images and TIFF for multi-page images. PAPPL provides callbacks for most of the events including submitting print/scan jobs, querying printer/scanner status and capabilities, and so forth to reduce the manufacturer's workload and hence designing scanner applications is very much similar to designing printer applications. The only difference is the additional callback support provided for the scan command. Since this support is added in PAPPL, you as a manufacturer do not need to worry about this implementation as well. Hence refer to Tutorial to Design Printer Drivers and follow the same for Designing Scanner Applications as well. This section is under development. It will be documented after the support for Multi Function Printer (MFP) functionalities is released. This section is under development. It will be documented after the support for Multi Function Printer (MFP) functionalities is released. 1 Printer/Scanner Application = 1 Snap: Don't make a Snap which contains tons of different printer and scanner applications. This is to ensure that you don't occupy lots of ports and network resources when you have many printer and scanner applications. Printer/Scanner/Fax support can be in a single application: To support multi-function devices you can put all the printer, scanner, and fax support into one application. For example, we recommend HPLIP to be put into one single application. Recommended: 1 Printer/Scanner Application per project or manufacturer/product line: It may be possible that a multi-function device may be served by different applications for printing and scanning. For example for legacy devices, scanning may be supported by retrofitted sane-airscan scanner application while printing is supported by the Gutenprint printer application. But here it is easier and better for the project, organization, and management that each project has its own printer/scanner application snap. So SANE will maintain a SANE scanner application snap and they put it on the Snap Store. Similarly, Gutenprint, HPLIP, foo2zjs, Epson, Canon, Ricoh, and so on will do the same. NOT make 1 Printer/Scanner Application for each device: For example, HP Laserjet 4 and HP Laserjet 5 should not have different applications. Otherwise, Snap Store will be cluttered with thousands of applications, and spotting the real application would be difficult. Also, it would result in a lot of code duplication, requiring more storage on the user's machine. 1 Printer/Scanner Application = 1 Port: If there are several devices connected to the system and they are served by one printer/scanner application, do not open ports for each device. Because you may run out of ports. Also, ports are not always the same on each boot as other applications may start up before on the next boot. For more than 1 device on 1 Application use URI: ipp://localhost:
[2] PAPPL
[3] PAPPL System Utilities
[4] Packaging Drivers and Uploading them to Snap Store"
+ },
+ {
+ "id": "documentation:04-packaging-drivers",
+ "source": "static",
+ "type": "documentation",
+ "title": "Packaging Drivers and Release them to the Snap Store",
+ "url": "/documentation/04-packaging-drivers",
+ "headings": [
+ "Benefits of using snaps",
+ "Top Level metadata",
+ "Apps Metadata",
+ "Parts Metadata"
+ ],
+ "tags": [],
+ "snippet": "This document contains a complete tutorial as well as information for manufacturers with examples for packaging printer/scanner drivers and releasing them to the Snap Store. If...",
+ "content": "This document contains a complete tutorial as well as information for manufacturers with examples for packaging printer/scanner drivers and releasing them to the Snap Store. If you are looking for information regarding the designing of printer/scanner drivers, kindly refer to Tutorial to Design Printer Drivers and Tutorial to Design Scanner Drivers respectively. After designing the printer/scanner application, you need to distribute these applications, so that the users can directly download and install these applications to support the printers and scanners manufactured by your company. One of the primary concerns while packaging the driver is Distribution-independent packaging. The classical printer driver binaries were specifically built for Linux distributions because the distribution provides the layout of CUPS, the libraries, and so on. Also, they have different packaging formats DEB, RPM, and many more. For each distro, drivers need to be built, packaged, and tested separately. It made the task next to impossible to execute. As a result, most of the hardware manufacturers refrained from making these drivers. But OpenPrinting has reduced the intensity of your task to a great extent as now you only need one driver for all printers, for all distributions, and distribute it through snaps. Snaps are app packages for desktop, cloud, and IoT that are easy to install, secure, cross-platform and dependency-free. A snap is a bundle of an app and its dependencies that works without modification across many different Linux distributions. Snaps are more secure. Every package with all its libraries and files in its own sandbox(isolated from other snaps and the host system), fine-grained control for communication between packages. Snaps are easily discoverable and installable from the Snap Store, an app store with an audience of millions who can browse and install snaps graphically in the Snap Store or from the command-line. You are encouraged to dive deep into the official Snap Documentation to explore more about it. Most Snaps we create are driven using snapcraft.yaml. This file describes a snap’s build dependencies and run-time requirements, it integrates remote repositories and extensions and runs custom scripts and hooks for better integration with CI systems. As a distributor, you would create a snapcraft.yaml file. This will be used by the snapcraft command to build your snap. Next, you would upload this .snap file to the Snap Store and release it on the stable channel. To start building your snap, the initial step is to install snapcraft. Kindly refer the installation guidelines to follow the same. After installation, navigate to the directory containing your application and use the following command. This creates a buildable snapcraft.yaml template within a snap sub-directory relative to your current filesystem location. The snapcraft.yaml file starts with a small amount of human-readable metadata. This data is used in the presentation of your app in the Snap Store. The former keys define the build dependencies and run-time requirements. name
This is the identifying name of the snap. It must start with an ASCII character and can only contain letters in lower case, numbers, and hyphens, and it can’t start or end with a hyphen. The name must be unique if you want to publish it to the Snap Store. In this field, you may wish to use the name of your organization along the part it is designed for. For help on choosing a name and registering it on the Snap Store, see Registering your app name. base
The base keyword declares which base snap to use with your project. A base snap is a special kind of snap that provides a run-time environment alongside a minimal set of libraries that are common to most applications: As used above, core18 is the current standard base for snap building and is based on Ubuntu 18.04 LTS. See Base snaps for more details. version
A human-readable string(enclosed within single-quotes) of maximum size 32 characters, represents the version number of your snap. A higher version number generally corresponds to a new application. summary
A single line summary that maybe 79 characters long, describes the snap in short and simple terms. It is used when users are searching through the Store for your application. description
Description is used to provide a little more detail about your application. You could as many lines as you want in this field. grade
Grade defines the quality grade of the snap. It can have two values. devel: a development version of the snap, so as not to be published to the stable or candidate channels. stable: a stable release or release candidate, which can be released to all channels. We would be using the grade value as stable. confinement
Confinement determines if the snap should be restricted in access or not. It could have three possible values. strict: for no access outside of declared interfaces through plugs. Can be published easily and installed without any special command-line argument. devmode: for unrestricted access to system resources. Snaps having this confinement cannot be published to Snap Store. classic: Allows access to your system’s resources in much the same way traditional packages do. To safeguard against abuse, publishing a classic snap requires manual approval, and installation requires the --classic command-line argument. We would be using the confinement value as strict. There is other metadata that can be used to provide more information to snapcraft besides the above-listed ones. One may refer to Snapcraft top-level format documentation to know about it. The apps keys and values in snapcraft.yaml detail the applications and services that a snap wants to expose, including how they’re executed and which resources they can access. Each application or service is an independent block, defined by a
The command to run inside the snap when
Declares that
A list of plugs for interfaces to connect to. Other snapcraft apps metadata may be referred from Snapcraft Apps Metadata Documentation. A most basic example for writing apps metadata is given below: Note that you must specify the
The plugin that will drive the build-process for this part. source
A URL or path to a source tree to build. This can be a local path or remote and can refer to a directory tree, a compressed archive, or a revision control repository. source-type
Used when the type of source entry cannot be detected. build-packages
A list of packages required to build a snap. stage-packages
A list of packages required at runtime by a snap. after
Ensures that all the parts listed in after are staged before this part begins its lifecycle. Here is only a few parts metadata that is must to be used in a printer/scanner application. The other metadata can be referred from Snapcraft parts documentation. Your Application will contain at least these 3 parts: PAPPL dependency (jpeglib) PAPPL Application Other parts includes additional dependencies if needed by your application. Default Parts for Application
These parts must be included in every application. They do not require modification and the developers may consider using it as boilerplate code for their applications. JPEGLIB PAPPL supports JPEG and PNG format and for loading the image data, it uses the jpeglib library. Hence it is a dependency for PAPPL and built using the autotool plugin. The Tape Archive (TAR) file can be fetched from the below-mentioned URL. PAPPL It is the most important part of an application and is also built using the autotool plugin. It is fetched from Michael's GitHub repository using the \"git\" source-type. The build-packages and stage-packages are mentioned below. Note the after key is essential as jpeglib is a building dependency for PAPPL. Hence PAPPL must be staged after jpeglib. Non-Default Parts for Application Application Dependency (Optional) Your application may use different libraries / Utilities / APIs, for example, the ones used for converting one format of data to another format, especially in the case of non-raster printers. In this case, those libraries are a dependency for the application, which needs to be specified in the parts section. Application The core of the snap. Note that the application has a dependency on libraries as well as PAPPL. Hence don't forget to add the after key so that the application must be staged at the last. Once you have a snap that works under strict or classic confinement, you’re ready to publish the snap in the Snap Store where it can be showcased to millions. The further steps are extensively covered in the official documentation of Snaps and can be located at Releasing to Snap Documentation."
+ },
+ {
+ "id": "documentation:05-User-Manual",
+ "source": "static",
+ "type": "documentation",
+ "title": "User Manual for Printer Applications",
+ "url": "/documentation/05-User-Manual",
+ "headings": [
+ "Introduction",
+ "Before we start",
+ "What printer application do you need?",
+ "Installation",
+ "Snap",
+ "Applications",
+ "Web Interface",
+ "Create and Delete Printers",
+ "View Logs",
+ "Update the TLS certificates",
+ "Configure Printing Defaults",
+ "Set Location and DNS-SD name",
+ "Configure Networking Settings",
+ "Printer Specific Utilities",
+ "Working with Command-Line",
+ "Server Daemon",
+ "Devices",
+ "Handling Jobs",
+ "Other Utilities",
+ "Resources"
+ ],
+ "tags": [],
+ "snippet": "This document is a user manual, containing information about installing drivers provided as Printer/Scanner Applications, installing the CUPS Snap, configuring and using web...",
+ "content": "This document is a user manual, containing information about installing drivers provided as Printer/Scanner Applications, installing the CUPS Snap, configuring and using web interface options, and finally use the printer or scanner to print and scan respectively. The user is relieved from most of the complexities arising from classic CUPS printer drivers, like needing packages for their particular distro (or at least compatible with it). With new format for printer drivers they just need to install the driver provided as a Printer/Scanner Application (based on the manufacturer and model) and use the same to get their devices working. Further, many manufacturer's devices have options that cannot be translated into IPP attributes. So the users can change their printer/scanner properties through the Web GUI provided with the Printer/Scanner Application. If you have a modern, driverless IPP printer or scanner (AirPrint, Mopria, IPP Everywhere, Wi-Fi Direct Print), you do not need any Printer/Scanner Application. The Printer/Scanner Application you need to use depends on your printer's manufacturer, model and which classic driver supports it. We at OpenPrinting have developed Printer Applications covering printer drivers which are available in Debian/Ubuntu to provide retro-fitting (to keep the old devices working, but without adding new features) support for older devices which are currently supported in the distributions, and we provide the Legacy Printer Application for devices, which drivers are no longer supported by the manufacturer or they aren't in distributions for various reasons (no open-source license, no public source code, nobody packaged it...). The Legacy Printer Application is able to find classic drivers installed on the system and print on the supported printers. The PostScript Printer Application also allows uploading PPD files for printers via its web administration interface. We at OpenPrinting provide Printer Applications as Snaps, so these manuals contain Snap-related information. However distributions might provide Printer Applications packaged under classic packaging systems like DEB or RPM, or by another container solution, f.e. Podman or OCI containers. The exception is the Legacy Printer Application, which cannot be containerized due to its nature, so it is part of pappl-retrofit and can be shipped only by classic packaging systems. All the four Printer Applications currently available at OpenPrinting are only for retrofitting purposes and any new drivers should be written as native Printer/Scanner Applications, which can be shipped as a container (Snap, Podman, OCI containers) or via classic packaging systems. The Native Printer Applications can be provided by the printer's manufacturer or by community developers who have access to the printer. In case you require a classic driver, there are two ways depending on the source of your driver: For your printer you have used a driver which came with your distribution. Thn one of the Printer Applications at OpenPrinting contains it. For your printer you used a driver which is not in any package in your distribution, a proprietary driver from the printer's manufacturer for example. Install the Legacy Printer Application and it will see your classically installed driver and will use it. For installing Printer/Scanner Applications, you should have snap installed on your system. On many systems snap is already installed (for example Ubuntu), if not you can usually easily install it. To install snap from the Software Manager application, search for snapd and click Install. Alternatively, snapd can be installed from the command line: Once snap is installed, you can easily install any driver. Find the name of the application compatible with your device. This information will be provided by your device manufacturer. You can install the application browsing the Snap Store or from the command line: Many interfaces are automatically connected when a snap is installed, and this ability is a property of either the interface itself or the snap. Interfaces not connected automatically require the user to make a manual connection using the snap connect command. Information regarding which interfaces require manual connection will be mentioned by the manufacturer. The embedded server can also provide a web interface to the Printer/Scanner Application, and PAPPL includes a standard web interface that can be customized and/or overridden. Aside from the usual status monitoring functionality, the web interface can be configured to allow remote users (with proper authentication) to: Create and delete printers Set the printer location and DNS-SD name Configure the loaded media Configure remote access accounts Configure networking settings such as the hostname Update the TLS certificates used by the server Interface Create printers Resource path: /addprinter Add Printer The addition of a printer requires only the following attributes: Name of the printer Device can be one of the following: Label Printer Office Printer Network Printer The choices here vary with the Printer Application and the available printer devices. Usually, here you will see printers which were discovered on your system, both local (USB and also manufacturer-specific or legacy connection types) and network printers. ideally only the ones supported by this Printer Application. Sometimes also manual options, like \"Network Printer\" with the possibility to enter a hostname/IP in the next field, are available, too. Hostname/IP Address of the printer required only in the case of a Network Printer. Driver Name needs to be selected from the available list of drivers provided by the manufacturer. Resource path: /logs Logs The complete system logs can be viewed here. If you prefer to read the text file instead, use the resource path: /logfile.txt. Following are the options that can be used to update the Transport Layer Security (TLS) certificates used by the server: Create New TLS Certificate Resource path: /tls-new-crt Create New TLS Certificate This form creates a new 'self-signed' TLS certificate for secure printing. Self-signed certificates are not automatically trusted by web browsers. Create TLS Certificate Request Resource path: /tls-new-csr Create TLS Certificate This form creates a certificate signing request ('CSR') that you can send to a Certificate Authority ('CA') to obtain a trusted TLS certificate. The private key is saved separately for use with the certificate you get from the CA. Install TLS Certificate Resource path: /tls-install-crt TLS Install This form will install a trusted TLS certificate you have obtained from a Certificate Authority ('CA'). Once installed, it will be used immediately. Printing Resource path: /
Before adding devices and submitting jobs, you must start the application as a server daemon: The list of options you could use are: | Option | Significance | |-----------------|----------------------| | spool-directory | Spool directory | | log-file | Log File | | server-hostname | Hostname | | log-level | Log Level | | server-port | Port | | admin-group | Administrative Group | Close Server
You can close the daemon using the following command: Adding Device Add a printer queue. The following fields are required to be mentioned for creating a printer queue: Device name Device URI Driver Name Default Options (Optional) You can obtain the possible list of
[2] Snap Documentation
[3] PS Printer App README
[4] HP Printer App Man Page
[5] PAPPL Documentation"
+ },
+ {
+ "id": "project:00-cups",
+ "source": "static",
+ "type": "project",
+ "title": "CUPS",
+ "url": "/project/00-cups",
+ "headings": [
+ "Project Links"
+ ],
+ "tags": [],
+ "snippet": "CUPS is the standards-based, open source printing system for Unix®-like operating systems. CUPS uses the Internet Printing Protocol (IPP) to support printing to local and network...",
+ "content": "CUPS is the standards-based, open source printing system for Unix®-like operating systems. CUPS uses the Internet Printing Protocol (IPP) to support printing to local and network printers. OpenPrinting is continuing the development of CUPS to further improve printing. Home Page GitHub Downloads"
+ },
+ {
+ "id": "project:01-cups-filters",
+ "source": "static",
+ "type": "project",
+ "title": "Cups-Filters",
+ "url": "/project/01-cups-filters",
+ "headings": [
+ "Project Links"
+ ],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "project:02-foomatic",
+ "source": "static",
+ "type": "project",
+ "title": "Foomatic",
+ "url": "/project/02-foomatic",
+ "headings": [
+ "Project Links"
+ ],
+ "tags": [],
+ "snippet": "Foomatic is a database-driven system for integrating free software printer drivers with the CUPS printing system and also with an easy-to-use command-line interface for direct,...",
+ "content": "Foomatic is a database-driven system for integrating free software printer drivers with the CUPS printing system and also with an easy-to-use command-line interface for direct, spooler-less printing. Foomatic consists of three packages: foomatic-db-engine Foomatic's database engine generates PPD files from the data in Foomatic's XML database. It also contains scripts to directly configure print queues and handle jobs. foomatic-db The collected knowledge about printers, drivers, and driver options in XML files, used by foomatic-db-engine to generate PPD files. It also contains manufacturer-supplied PPD files which got released under free software licenses. foomatic-db-nonfree Foomatic database extension consisting of manufacturer-supplied PPD files released under non-free licenses which restricts them in how they can get redistributed."
+ },
+ {
+ "id": "project:03-ippusbxd",
+ "source": "static",
+ "type": "project",
+ "title": "IPPUSBXD",
+ "url": "/project/03-ippusbxd",
+ "headings": [
+ "Project Links"
+ ],
+ "tags": [],
+ "snippet": "IPPUSBXD is a userland driver for IPP-over-USB class USB devices. It has been designed for Linux but uses a cross platform usb library allowing eventual porting to Windows and...",
+ "content": "IPPUSBXD is a userland driver for IPP-over-USB class USB devices. It has been designed for Linux but uses a cross platform usb library allowing eventual porting to Windows and other non-POSIX platforms. The IPP-over-USB standard was ratified by the USB forum in 2012. As of 2014 Mac OS X implemented this standard and with the addition of ippusbxd Linux shall as well. IPPUSBXD depends on POSIX threads, POSIX networking, and libusb as developed by the community at libusb.info IPPUSBXD has the following advantages: At runtime links only with libc, pthreads, libusb, and libavahi*. On a typical system these libraries will already be in RAM. This gives ippusbxd a minimal ram footprint. Requires no read access to any files. Ships with a strict AppArmor profile. Runs warning & leak free in valgrind Compiles warning free in clang Analyzed warning free in Coverity Can be installed anywhere Near zero CPU usage while idle Low CPU usage while working"
+ },
+ {
+ "id": "project:031-driverless-printing",
+ "source": "static",
+ "type": "project",
+ "title": "Driverless Printing",
+ "url": "/project/031-driverless-printing",
+ "headings": [],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "project:04-print-dialog",
+ "source": "static",
+ "type": "project",
+ "title": "Common Print Dialog Backends",
+ "url": "/project/04-print-dialog",
+ "headings": [
+ "Project Links"
+ ],
+ "tags": [],
+ "snippet": "The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, LibreOffice, ...)...",
+ "content": "The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, LibreOffice, ...) from the different print technologies (CUPS/IPP, Google Cloud Print, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly. If one opens the print dialog, the dialog will not talk directly to CUPS, Google Cloud Print, or any other printing system. For this communication there are the backends. The dialog will find all available backend and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selcted printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added."
+ },
+ {
+ "id": "project:05-miscellaneous",
+ "source": "static",
+ "type": "project",
+ "title": "Miscellaneous",
+ "url": "/project/05-miscellaneous",
+ "headings": [
+ "Implementing PWG standards for Linux and other Posix-style operating systems",
+ "Work with printer manufacturers on making printer drivers"
+ ],
+ "tags": [],
+ "snippet": "We help printer manufacturers to write print drivers and get printers working on Linux and other Posix-style operating systems.",
+ "content": "We help printer manufacturers to write print drivers and get printers working on Linux and other Posix-style operating systems."
+ },
+ {
+ "id": "page:about-us",
+ "source": "static",
+ "type": "page",
+ "title": "About Us",
+ "url": "/about-us",
+ "headings": [
+ "OpenPrinting",
+ "A Brief History",
+ "Major Roles",
+ "Our Code of Conduct: Code of Conduct"
+ ],
+ "tags": [],
+ "snippet": "Learn more about OpenPrinting",
+ "content": "How did this all begin? Our principal achievements What we are currently doing Before 2006, linuxprinting.org and Free Standards Group's OpenPrinting WorkGroup were working on the printing architecture for Linux. Till Kamppeter was the manager of linuxprinting.org and FSG's OpenPrinting WG was led by Tom Hastings, Michael Sweet, Ira McDonald, Claudia Alimpich, Glen Petrie, and Norm Jacobs. linuxprinting.org was known as the de facto standard repository for printer drivers on Linux. In parallel, FSG's OpenPrinting workgroup designed standard APIs for the Linux/Unix printing workflow. In July 2006 linuxprinting.org merged with FSG's OP WorkGroup and Till Kamppeter was hired to lead OpenPrinting. On January 22, 2007, the FSG and the Open Source Development Labs(OSDL) merged to form The Linux Foundation. Now, OpenPrinting is a free software organization under The Linux Foundation. OpenPrinting Works on the development of new printing architectures, technologies, printing infrastructure, and interface standards for Linux and UNIX-style operating systems. Collaborates with IEEE-ISTO Printer Working Group (PWG) on IPP projects. Is working with SANE to make driverless scanning a reality. Maintains cups-filters which allows CUPS to be used on any Unix-based (non-macOS) system. Is responsible for the Foomatic database. Is working on the Common Print Dialog Backends project. Takes care of integrating the printing infrastructure with all types of operating systems (classic distro, immutable distro, ...) and software distribution technologies (Snap, Docker, ...)"
+ },
+ {
+ "id": "page:achievements",
+ "source": "static",
+ "type": "page",
+ "title": "OpenPrinting - Our principal achievements",
+ "url": "/achievements",
+ "headings": [
+ "All free drivers to be used with CUPS",
+ "Getting all Linux distributions to use CUPS",
+ "PDF instead of PostScript as standard print job format",
+ "Common Print Dialog",
+ "Grand Unified Ghostscript: CUPS support, third-party built-in drivers ...",
+ "cups-filters",
+ "cups-browsed",
+ "Common Print Dialog Backends",
+ "CUPS upstream home is OpenPrinting now",
+ "The CUPS Snap",
+ "All free drivers in a PPD-less world - OR - All free drivers in Snaps",
+ "Driverless printers on USB - IPP-over-USB",
+ "\"localhost\" support in Avahi",
+ "SANE backends for driverless scanning - eSCL and WSD (AirScan)",
+ "The OpenPrinting web site"
+ ],
+ "tags": [],
+ "snippet": "What we have done so far",
+ "content": "This page represents the state of August 2022 In the 21 years from the beginning of OpenPrinting up to now we have changed a lot of things to improve the user experience with printing on free software and Posix-style operating systems (like Linux). I have worked on this full-time since mid-2000, first at MandrakeSoft in Paris, from mid-2006 on I got paid by the Free Standards Group and from 2007 on by the Linux Foundation, for leading the OpenPrinting project, and in addition part-time by Canonical for maintaining the printing part of Ubuntu. And from Feb 2012 on I got full-time employee of Canonical, to continue leading the OpenPrinting project. So thanks to MandrakeSoft/Mandriva, the Linux Foundation, and Canonical to make this project possible and successful! My first task back in 2000 at MandrakeSoft was to switch over Mandrake Linux from LPD to CUPS, and this was not only making the first RPM packages of CUPS, but also to make sure that for the users of the first ever Linux distribution which uses CUPS as printing system all hardware (printers) which was supported in the previous distro version (using LPD) is still supported. THis meant especially that I need PPD files and CUPS filters (wrappers) for all drivers, and there were already many in the free software printing stone age ... Printer drivers were not such a well-defined thing as current CUPS drivers consisting of filters and PPD files or even Printer Applications are. They somehow turned a standard input format (usually PostScript or some bitmap format which Ghostscript was able to generate) into what the printer needs, but this was all what made a software be a printer driver. Drivers could be some output device compiled into Ghostscript, or some tiny, simple filter executable which turns Ghostscript's output into at least one of the input data formats of the printer, or one had Ghostscript Uniprint files to use the first data-driven Ghostscript driver, ... But anything machine-readable which tells how to use the driver and which user-settable options are there was usually not included. Here third-party projects like Magic Filters or apsfilter came into play ... Fortunately, there was a site named linuxprinting.org which tried exactly this. Exactly it was a database of printer models and of free software drivers, telling which printers work with free software (and therefore is not a \"Paperweight\") and if so, with which driver. But the very special thing of the site was that it did some automated, systematic integration of printer drivers with printing systems, and there were several printing systems: LPD, LPRng, PDQ, and ... CUPS! So this system provided a universal wrapper CUPS filter for printer drivers, named cups-o-matic plus a generator for PPD files which uses the printer and driver properties (page sizes, color modes, trays, other user-settable options, driver command lines, ...) stored in the database to generate a PPD for each valid printer/driver pair. The problem was that the database was not completely populated, many drivers were missing the information on how to execute them (command line, options, ...). So I asked the site's author to complete the missing info and as he did not have the time to enter this detaiiled information, he gave me full write access and I could complete the database by myself, solving the driver integration problem. So now I had PPD files and the universal cups-o-matic filter for all drivers and so the printer drivers made it into the age of CUPS. So the second generation of printing with free software could start. Later on, with Grant not having time for his project any more and me coming up with more and more feature requests he passed the project over to me in mid-2001 and so I got the leader of linuxprinting.org, also known as Foomatic. Now, with one distribution, Mandrake Linux, using CUPS as its standard printing system, me, together with Kurt Pfeifle, continued marketing CUPS on conferences and especially by organizing a community booth about printing every year on the LinuxTag, in that time the largest free software show in Europe, from 2001 on until 2006. This, and probably also the good user experience with printing in Mandrake Linux, also convinced the other distributions, Red Hat, SUSE, Debian, ... to switch over to CUPS, using my Foomatic work. CUPS got the new standard for printing on all Posix-style operating systems! Even Mac OS had adopted CUPS in 2002 (where I do not know whether my work had also influence on Apple. Have I perhaps promoted Michael Sweet to make it into Apple?)! Decades ago, when it began with the POSIX-style operating systems, there were commercial Unix systems, usually used in data centers at universities or larger companies. Printers were either line printers which printed plain text or PostScript laser printers as only option for text-and-graphics printing. So applications sent jobs in plain text or PostScript and PostScript turned to be the standard print job format for graphical printing. Later on, and especially with the introduction of Linux for PCs, there was also need for printing on consumer-grade, usually non-PostScript printers. Here Ghostscript came into place to render the PostScript coming in from applications and either generate the printer's format with a built-in driver or a generic bitmap format for an external driver. This principally works but is not the best solution. PostScript is a format from 1984 and does not support important elements of modern document creation, like transparency. It is also a Turing-complete programming language which opens possibilities for abuse. Also for publishing printable documents on the internet PDF, Adobe's successor of PostScript was already used. And PDF is still developed on by Adobe. So Michael Sweet and me, we decided on making the standard print job format to be PDF and I announced this decision on the first OpenPrinting Summit which I organized, 2006 in Atlanta. Principally, PDF as standard print job format means that applications send jobs in PDF and non-PDF input is converted to PDF by CUPS, then page management (N-up, output order, selected pages, ...) is done in PDF, and after that the PDF is converted to the final format needed by the printer. To implement this we needed several new CUPS filters for the PDF-based print workflow, imagine, as a first approach, to replace all pstoXXX filters by pdftoXXX. Also the central pstops filter had to be replaced by a pdftopdf filter. Fortunately, Ghostscript accepts also PDF and not only PostScript as input, so that all printer drivers involving Ghostscript could be continued to be used. Also CUPS itself did not need any change as its excellent filter system, completely controlled by MIME types and MIME conversion rules and the filters themselves being separate executables, one only needed to add the new filters and to change the conversion rules. For coding the filters I have found volunteers in the community and at some member companies of the PWG. Later on, when we started participating in the Google Summer of Code in 2008, we ran also some filter implementation projects there. GUI and application projects have practically all switched to send print jobs as PDF. As I am maintainer of the CUPS package in Ubuntu I had switched it to the PDF-based print workflow as soon as I had all filters together, not yet having an organized upstream home for these filters, neither an extra upstream project nor imclusion in CUPS. I simply added a filter source package to the CUPS package of Ubuntu. Only when I introduced cups-filters in the end of 2011 I was able to switch the official CUPS filters (which were cups-filters then) to the PDF-based printing workflow and so all distributions got switched over. This is the only project on which we failed (but others succeeded, see below). On the first OpenPrinting Summit in 2006, at Lanier (now Ricoh) in Atlanta, Georgia we had a group of GUI/Usability experts to brain-storm about a better print dialog design and we had them even meeting again on further Summits continuing in breakout sessions. The result was not only new approaches in the GUI design of the print dialog, but also the idea of having one and the same print dialog for all applications, independent which toolkit they use, which we called the Common Print Dialog. For this the print dialog should be a part of the desktop environment (GNOME, KDE, ...) and available for the applications as a D-Bus service. The applications will then shout into the D-Bus instead of opening their own print dialog, ending up with always having the GTK dialog when using GNOME and always having the Qt dialog when using KDE. So the user will see only one type of print dialog in their desktop environment, independent which applications they are using. The actual coding started in 2008, when we (the Linux Foundation, not only OpenPrinting) were for the first time mentoring in the Google Summer of Code. Lars Karlitski (Lars Übernickel in that time) has created the D-Bus interface and also coded on the GTK dialog while another student coded on the Qt dialog. The D-Bus interface got completed and working, but the dialog GUIs got far from complete. Also students in the 2009 GSoC (where Lars was mentoring) did not complete the dialogs. Also Lars, Peter Sikking (one of the GUI experts on the Summits, running a GUI/usability design firm), and me regularly met in-person (very rare in the free software world) in Berlin (Peter and me lived there, Lars 2 hours driving away from Berlin) to work on the GUI design of the dialog. As we did not succeed to complete the coding of the complex design of the dialog we tried to get funding for paid developers completing it. The German government organization Bundesamt für Sicherheit in der Informationstechnik (BSI, Federal Authority for IT Security) wanted to give a part as they were switching around 200 work places from Windows to Linux and wanted an easy printing experience for their users. Later on we also got Canonical into the boat. They hired Lars full-time for this task, but as soon as he was hired I told this to the people from the BSI but then they did not answer my e-mails any more and so we considered the project failed. It was no problem for Canonical having hired Lars and our project being discontinued. There was enough GTK/GNOME work for Lars to do, and after some years he switched to Red Hat. So I have got him into a nice career. In my opinion our failure was trying to create the perfect GUI for the dialog. If we had simply used the D-Bus interface and the original print dialogs of GTK and Qt we had probably succeeded ... But, many years later, I have seen this idea being actually implemented. But it is not clear whether it got picked up from my presentations of the idea of the Common Print Dialog on conferences or whether it was created independently. The implementation happened to be in the Flatpak system for distribution-independent packaging of desktop applications (in contrary to Snap only desktop applications, no command line utilities, system daemons, system components, or core systems). Flatpak comes from freedesktop.org, and is popular in the RedHat-ish world. Flatpaked desktop applications communicate with the host system/the outside world through so-called Portals, so for printing they use the Printing Portal. In contrary 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, ...), 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. See more details in my \"Flatpak and Printing\" article. When Michael Sweet created printer drivers (ESP Print) and finally CUPS during the 90s of the previous century, he included a modified version of Ghostscript as PostScript interpreter to print incoming PostScript jobs from applications on non-PostScript printers. Main modification was most probably adding the output of the device-independent CUPS Raster format or a predecessor of it. Later on, when CUPS was released as free software, the modified Ghostscript was also made available as free software, named ESP Ghostscript. This Ghostscript got the Ghostscript of the Linux distributions when they adopted the CUPS printing system. Michael Sweet and me, we continued its development. Especially I added all the third-party Ghostscript drivers which the distributions had to add to GPL Ghostscript as patches on their own, making Ghostscript in distributions always one of the packages with the most patches. ESP Ghostscript also got an improved, easier to control build system based on autoconf and I added a patch from Mandrake which made the X11 output device dynamically loadable, so that the same binary executable of Ghostscript can be used in both desktop and headless server systems. In May 2006, the Ghostscript developers announced that from version 8.54 on they will merge the former commercial, leading-edge (AFPL) and the free GPL development branch, which was only based on the previous major release, and so doing the leading-edge developemnt as free software, usable by the Linux distributions. Ghostscript leading edge is now GPL! Posted 7 Jun 2006 by raph I have some great news to report. The leading edge of Ghostscript development is now under GPL license, as is the latest release, Ghostscript 8.54. By switching to the GPL, we're reaffirming our commitment to the free software world. One big reason for this decision was to reduce the lead time between bugs being fixed in the development tree and users seeing the fixes, especially those users dependent on Linux distributions. Moving forward, we'd also like to resolve the effective fork with \"ESP Ghostscript\", so that our development tree is suitable directly for use in Linux distributions without a lot of extra patches. It would be very nice if all the GPL patches could be incorporated into the main tree without any license restrictions (which means that we need copyright assignment), but realistically, we'll still have to implement an apartheid system of some kind, so that a GPL-only subdirectory exists that gets deleted out of our commercial releases. Linux distributions continued using ESP Ghostscript though, due to the CUPS Raster output device and the complete set of built-in printer drivers. As the upstream Ghostscript development is under GPL now, Michael Sweet decided to discontinue the separate ESP Ghostscript development and merge ESP Ghostscript into GPL Ghostscript. In April 2007 I started the merger moving all the extra features of ESP Ghostscript into GPL Ghostscript, making up the Grand Unified Ghostscript, which was released as version 8.60 in August 2007. It was really a large surgery on GPL Ghostscript but worked out smoothly with the great collaboration of Ghostscript's upstream developers of that time (esp. Ralph Giles, Raph Levien, Ray Johnston), Michael Sweet, distribution package maintainers Werner Fink (SUSE) and Bernhard Rosenkränzer (Ark Linux), for testing all the changes, adapting patches to GPL Ghostscript, upstreamizing distribution patches ... In the CUPS Blog I posted: The Grand Unified Ghostscript Officially Released: GPL Ghostscript 8.60 Now the merger between ESP Ghostscript and GPL (upstream) Ghostscript is done and available in an official, stable release. Artifex has released GPL Ghostscript 8.60, which is is now the Ghostscript recommended for use in Linux distributions. Now the latest and greatest Ghostscript will make it into the distros. This new version contains especially the CUPS raster output device, IJS and OpenPrinting Vector interfaces for driver plug-ins, all built-in printer drivers listed in the OpenPrinting database, X display drivers in a separate shared library, and many more improvements and bug fixes. From then on, all distributions switched to GPL Ghostscript (Ubuntu Gutsy Gibbon, 7.10 and the patch hell in the distribution packaging had an end. In February 2007, Apple acquired ownership of the CUPS source code and hired Michael Sweet, for continuing CUPS developemnt as free software (GPL2/LGPL2 licensing terms), and for using CUPS as the printing system of Mac OS. As Apple uses their own, proprietary filter suite (note that one can easily replace the filters in CUPS, see \"PDF instead of PostScript as standard print job format\" section above) and not the free software filters which originally came with CUPS, they dropped the further development of most of these filters, removed them from the CUPS source code repository, and passed them over to OpenPrinting. This happened with the CUPS 1.6.0 release in July 2012. As the actual pass-over happened somewhat earlier, I created the cups-filters project starting from the filters and backends which Apple had abandoned end of 2011. Right away, even before I did the very first release of cups-filters, I pulled the plunge for the PDF-based printing workflow everywhere, adding the PDF-related filters which we developed already since 2006 and tested already for several years in Ubuntu. This way, right away when distributions had to include cups-filters when they updated CUPS to version 1.6.x, they automatically got switched to the PDF-based print workflow. This did not cause any complaints and most applications probably had already switched over that time. During the following 11 years up to now the filters were continuously maintained and developed. Especially we are preparing cups-filters for the New Architecture of printing, meaning that we do not have PPD files any more and classic printer drivers are replaced by Printer Applications (emulators of IPP printers): Driverless printing support: Output formats for driverless printing got included:PDF, PWG Raster, Apple Raster, PCLm) Filter functions: Filter executables turned into filter functions, library functions with standardized call scheme, also for easy chaining. This rerduces external function calls and also makes it easier to use the filters from Printer Applications (Software-emulated IPP printers to replace printer drivers). They also do not use environment variables and log into a log function, to make them also easy to use in non-CUPS environments. Use without PPD files: As use of PPD files will end with CUPS 3.x and already the CUPS Snap does not support adding PPD files for new printer drivers any more, the filter functions can now also be used with IPP attributes instead of with PPD files. These changes will soon appear in the second generation of cups-filters, version 2.x. CUPS 1.6.x did not only drop the free software filters but also switched from its own broadcasting/browsing to easily share queues to remote systems using CUPS to the standard DNS-SD method. This way CUPS is especially a complete emulation of a driverless IPP printer, advertising itself via DNS-SD, speaking IPP 2.x, and understanding standard data formats like PDF, and in addition, we have less clutter by different network communication protocols being used. What we lost by this is that CUPS clients do not auto-create a queue to a printer shared by a CUPS server any more. The user can find the DNS-SD self-advertising remote CUPS queues but there are no local queues automatically set up any more which point to these remote printers. So the user cannot \"just print\" on a remote CUPS printer any more, without manually setting up a local queue first. Ubuntu 12.10 shipped CUPS 1.6.x for the first time. Filters were there, even for PDF-based printing but the automatic setup of client queues pointing to remote CUPS printers was missing. As there was not much time for creating something new before Feature Freeze I simply patched the broadcasting/browsing functionality of CUPS 1.5.x into Ubuntu's CUPS 1.6.x but clearly expressed that this is an interim solution for only this Ubuntu release and something better will come with the next Ubuntu release, 13.04. And I found the \"something better\". In the end of 2012 I created an auxiliary daemon which gets triggered by the DNS-SD advertising of the remote CUPS queues and this way automatically creates the client queues, it even removes the local queue again when the shared printer disappears (for example when one leaves the network). So this is very close to what are the temporary queues in modern CUPS. I named this daemon \"cups-browsed\" and added it to the cups-filters project. And with this the user experience in the distributions did not change with the transition from CUPS 1.5.x and 1.6.x With the time, cups-browsed got a lot of new features, advancing to be a universal auxliary daemon for CUPS, especially the former Red Hat printing maintainer Tim Waugh added functionality that cups-browsed does (when activated by configuration file) the classic CUPS broadcasting/browsing as there are still many long-term-supported enterprise distributions, both servers and desktops around and they often still have CUPS 1.5.x or older. Also a clustering facility, much more sophisticated than CUPS' implicit classes (which also disappeared with 1.6.x) got added, highly configurable for manual and automatic clustering, different fail-over and load-balancing schemes, and even clusters of completely different printers (laser, photo inkjet) and by the job and its option settings cups-browsed determines which is the most suitable printer. But most importantly, unfortunately, cups-browsed turned a stop-gap for overcome the fact that print dialogs do not support the temporary queues which got introduced in CUPS some years ago. Temporary queues are CUPS' replacement for the missing auto-creation of client queues pointing to remote printers. A client can discover a remote printer via DNS-SD and then send a job to the local CUPS as CUPS had a queeu pointing to this printer. Then CUPS auto-creates the queue, prints the job, and when the queue stays idle for a minute afterwards, removes the queue again. Print dialogs did not switch to the new print destinations API of libcups and so did not discover such printers. So I have added a configuration option to cups-browsed to check whether a discovered remote printer would print on via the local CUPS through a temporary queue and in this case create a permanent queue pointing to this printer, in a way that CUPS considers the creation of a temporary queue unneeded. Once this done I had to keep cups-browsed in the standard desktop installation of Ubuntu up to today, as not all print dialogs support temporary queues yet. I hope I will be able to remove cups-browsed from Ubuntu soon. Some years after having failed with the Common Print Dialog Aveek Basu suggested to revive the project, but I was unsure about that. And when I was fixing a CUPS-related bug in the GTK print dialog I discovered that it uses backends for different print technologies. This brought up a new idea in me to improve the print dialogs. It was back in 2017, CUPS already having the concept of the temporary queues, auto-created by CUPS when a client prints on a DNS-SD-discovered IPP printer through the local CUPS and the local CUPS does not need to have a queue set up for this printer. For a client to know for which printers it can simply send jobs to the local CUPS, it needed a special, newly introduced API of libcups, but in print dialogs the switchover to the new API was missed out for many years, making the dialogs only displaying the permanent, usually manually set up, print queues Also, now with the introduction of the new Architecture of printing, going all-IPP and not using PPD files any more, print dialogs would need another update to not try to load the PPD file from CUPS (or even directly from the file system) to obtain the printer capabilities and options, but instead, use CUPS APIs of libcups, which internally use CUPS's current methods to get the needed information about the printer. The delays in GUI toolkit (GTK, Qt) and desktop application projects to update their print dialogs to new technologies, caused by missing volunteers for maintaining the print dialogs and also long release cycles, led us to the idea to move the responsibility on the communication with the print technology away from GUIs and applications and towards the maintainers of the print technology itself (OPenPrinting in case of CUPS). For this we separated the communication with the actual print technology (CUPS, print-to-file, cloud printing services, ...) out of the print dialog GUIs and applications by using a D-Bus interface. So the communication with the print technology happens in a backend module which provides a standardized D-Bus service, providing methods for listing available printers, listing options an choices for a given printer, printing a job on a given printer, ... The print dialogs get frontends which call these D-Bus methods. There is one backend per print technology (CUPS, print-to-file, cloud printing services, ...) and a print dialog is supposed to shout into the D-Bus and get a list of available printers for each of This we call the \"Common Print Dialog Backands\" and the project started back in the Google Summer of Code 2017. Here is the final report of Nilajana Lodh who worked on cpdb-libs, the central libraries with the D-Bus interface. The D-Bus interface was actually working a support for it in LibreOffice was implemented in the same Google Summer of Code but we did not get it into the GTK and Qt print dialogs yet. In this year's (2022) Google Summer of Code we have another contributor working on it and his work is promising. End of 2019 Michael Sweet left Apple to start Lakeside Robotics. After that any further developemnt of CUPS at Apple stopped. In 2020 there were only a few commits on Apple's CUPS GitHub to fix one urgent security bug. Bug reports stayed untouched and accumulated. In September 2020 Michael teamed up with us to fork Apple CUPS to fix bugs, incorporate distribution patches, and continue its development. In the beginning it was meant to be temporary, until Apple resumes to develop CUPS. As Apple did not resume the upstream work on CUPS in the following months, we have made OpenPrinting now the official upstream home for CUPS. We now continue developing CUPS, independent of Apple. So we can add features and lead CUPS into the New Architecture without PPD files and with Printer Applications. CUPS has a new home page now and what was formerly our fork is now the official CUPS repository. We started releasing the 2.4.x series end-2021, now without \"opX\" suffix of forked CUPS versions. Also all documentation files which come with it are updated to point to the OpenPrinting resources. Mailing list for development discussions is our printing-architecture list. So today Apple CUPS is the version of CUPS that is provided with macOS® and iOS® while OpenPrinting CUPS is the version of CUPS being further developed by OpenPrinting for all operating systems. This way we could establish a roadmap for upcoming CUPS releases, especially in the end of 2023 releasing CUPS 3.x with the NEW Architecture of handling printers IPP-only without PPDs and classic drivers. Michael has presented development plans on Linux Plumbers 2021 and the OpenPrinting Summt/PWG Meeting 2022. In October 2017 I started snapping (= packaging as a Snap) CUPS. Canonical started Snap in that time to have a sandboxed, Linux-distribution-independent packaging system to make distribution of software for Linux as easy as distribution of apps on smartphones. Users of any distribution with snapd installed (and snapd one can easily install on all systemd-based Linuxes) can find application software packages in the Snap Store and install it right away. No need to have packages for exactly that release of the Linux distribution one is using, and finally also software released after the distribution one is using is available. Snap has also a rigorous security system, encapsulating the application's file systems against each other and only allowing controlled communication between different Snaps and also beteween Snaps and the host system via well-defined interfaces. And the Snap Store team has to give explicit permission for automatic connection of interfaces which could be dangerous in some form. So one can easily and safely install third-party software and is not restricted to what one's distribution has packaged for the release in use. My work on the CUPS Snap got motivated by Canonical's plans of creating an all-Snap Linux distribution, not using Debian packages at all any more. So everything, including the printing system (and also the printer drivers) had to be in Snaps. Fortunately, Snap was so well-designed that it allows also packaging command line tools and even system daemons (Flatpak for example only packages GUI applications, see my blog post) and so I could snap right away. But there were a lot of challenges in these 5 years until the CUPS Snap got into production use for the first time: How to add printer drivers (note that Michael Sweet brought in the solution with the Printer Applications only on the OpenPrinting Summit 2018, slides) Providing the \"cups-control\" interface by the CUPS Snap Including D-Bus in \"cups-control\" First idea of a \"cups\" interface for only printing, not managing CUPS System users and groups See the README.md of the CUPS Snap for more links. Once everything working the biggest challenge was the \"cups\" interface through which application Snaps can safely print but canmnot mess up the system's CUPS, independent whether classically installed or the CUPS Snap. Note that the \"cups-control\" interface which was there from the beginning allows full access to the system's CUPS and so was considered \"dangerous\", meaning that in apps uploaded to the Snap Store it does not get connected automatically. The \"cups\" interface is considered \"safe\" and therefore auto-connects. After a year of design and implementation work of me together with Canonical's snapd team we made the \"cups\" interface exclusively connecting to the CUPS Snap, auto-installing the CUPS Snap as a dependency if it is not already installed. The CUPS Snap contains a new-enough CUPS where my Snap mediation functionality is built in, rejecting administrative tasks of Snaps not connecting via \"cups-control\". So if the CUPS Snap is the user's standard CUPS, all is working as expected. If the user has a classically installed CUPS, the CUPS Snap goes into proxy mode, cloning the queues of the system's CUPS and passing all jobs simply through to the system's CUPS, so that the user's queues and drivers (also proprietary ones) continue to get used and the user gets the same experience for snapped and classically installed apps. Administrative CUPS requests from application Snaps get always blocked, so the CUPS Snap's CUPS works as a firewall for the system's CUPS. Here are some threads on the snapcraft.io forum about the development of the interface (including documentation for who wants to snap their apps): New interface: “cups” for all Snaps which print (How to use, how it exactly works) The \"cups\" interface, by Graham Morrison My original documentation request for the \"cups\" interface Handling of the “cups” plug by snapd, especially auto-connection (How we came to the proxy mode of the CUPS Snap) “cups” interface merged into snapd - Additional steps to complete And by the time of writing this, two applications in the Snap Store are actually using the \"cups\" interface: onlyoffice-desktopeditors and FreeCAD. Due to their dependency on the CUPS Snap they made the installation count of the CUPS Snap sky-rocket from 4200 to 75000. And we can expect much more as soon as the Firefox, Chromium, and LibreOffice Snaps switch over ... This also means that the CUPS Snap got integral part of the Snap eco-system. It is live and in production now. Now we are looking forward for the first distribution using the CUPS Snap as its default printing environment (Ubuntu 23.04 ???) and for the first all-Snap Ubuntu distribution. After having transferred all free software drivers from the dark age of LPD to CUPS in the beginning of the glory days of OpenPrinting we now have been at the point of transferring them again, this time from classic CUPS drivers consisting of PPD files and filters into Printer Applicatioms, emulations of IPP printers. Many, many years ago, in the good old times of CUPS 1.4 (August 2009) PPD files got deprecated, but continued to be used up to today, due to lack of a new concept for printer drivers. This concept came up only on the OpenPrinting Summit/PWG Meeting 2018 in Sunnyvale, CA, when Michael Sweet introduced the concept of Printer Applications in his CUPS Plenary. Printer Applications are emulations of driverless IPP printers (IPP Everywhere, AirPrint), so behave exactly like a modern network printer. Internally, they connect to non-driverless printers and convert incoming jobs from at least one of the driverless standard data formats (PDF, PWG Raster, Apple Raster, PCLm) into the printer's native language. They also know about the supported printer's capabilities and supply this information on a client's get-printer-attributes IPP request. They also advertise there presence by DNS-SD as network printers do. This means that printer drivers are emulations of driverless IPP printers, so CUPS only needs to deal with driverless IPP printers, as a printer is either actually a driverless IPP printer, or it is taken care of by a Printer Application, or it is a remote CUPS printer (and CUPS is also an emulation of driverless IPP printers). And this way CUPS can go all-IPP, no PPD files and printer-specific filters any more! And this CUPS we are approaching now: In CUPS 3.x (or if you prefer video: The Ubuntu Indaba) the deprecated PPD file support will get finally removed. Also if the CUPS Snap is used as the standard printing system, we cannot use classic CUPS drivers any more but have to resort to Printer Applications. This is due to the nature of Snaps, having a static, immutable file system where we cannot add extra files, in our case PPD files and filters. One could now say that CUPS is flexible enough to move the PPD and filters directories into the dynamic file system of the Snap (hey, we can add PPD files to the PostScript Printer Application Snap, why not drivers to the CUPS Snap?) but this is not desired, as copying executable files (the filters) into a Snap would break the security principles of Snaps. But now one can think why did we rush the classic printer drivers into Printer Applications right now? We have still time until end of 2023 when CUPS 3.x gets released? The main reason is that I want to switch Ubuntu 23.04 (release April 2023) to use the CUPS Snap as its default printing system, as a dress rehearsal for the New Architecture to test all its shiny new components (the Printer Applications, the GNOME Control Center, the print dialogs with Common Print Dialog Backends, ...). If I wait for the release of CUPS 3.x, the next available Ubuntu release is 24.04 LTS (Long Term Support) and doing such a high-impact change as the New Architecture in an LTS is very risky, therefore I would very much like to make use of the \"small\" Ubuntu releases before. And all the talk about an all-Snap Ubuntu distribution ... Yes, I have transferred all free software printer drivers which come with Debian (and so also with Ubuntu) into 4 driver-retro-fitting Printer Applications. Only driver not transferred (yet) is the Braille printer driver included in cups-filters (but this is in the works now). But do not think I have all these drivers rewritten into filter functions and turned their PPD file generators into get-printer-attributes IPP responders. No, I would never do it, as such code changes one has to test, and how should I test the drivers for ~10000 printer models without having the actual printers, but having a hall with 10000 printers inside one would also need a lot of people to do the testing. So the way to go is \"do not touch the running code\" and encapsulate it in Printer Applications. I started writing a PostScript Printer Application for printing on PostScript printers with their manufacturer's PPD files (~4000 PPDs included in the Snap, all free ones which come with distributions, user can add own ones) and once having this completely working (with support for installable accessories, polling settings from the printer, ...) I decided to generalize this for CUPS drivers and turn this into a library), ending up with the pappl-retrofit project based on Michael Sweet's PAPPL. Using this library the effort for retro-fitting CUPS drivers is low, and needs only very small changes in C code for configuring the Printer Application and for a method to find out which printers are supported. More substantial C programming is only needed if one wants to add some special functionality (like downloading HP's proprietary plugin in the HPLIP Printer Application). The original PPD files (or PPD generators) and filters are then packaged together with the Printer Application and that's it. pappl-retrofit has all functionalities to list the PPD files, to generate get-printer-attributes IPP responses from the PPD files, find the best PPD option settings for given job IPP attributes, create media-ready lists of loaded media, run CUPS filters to execute the print jobs, stream jobs whenever possible, ... Once created this library it was quick and easy to get all these drivers into Printer Applications. 2 of the 4 (HPLIP, Gutenprint) are for still actively maintained drivers and so will sooner or later get replaced by native (= no PPD files used internally) Printer Applications. So we currently have: PostScript Printer Application (Snap Store): Printer Application Snap for PostScript printers which are supported by the manufacturer's PPD files. User can add PPD files if the needed one is not included or outdated. HPLIP Printer Application (Snap Store): HPLIP in a Printer Application Snap. Supports nearly every HP printer ever made. Installing HP's proprietary plugin (needed for a few printers) into the Snap is supported and easily done with the web interface, and it gets automatically updated. Gutenprint Printer Application (Snap Store): High quality output and a lot of knobs to adjust, especially for Epson and Canon inkjets but also for many other printers, for example dye sublimation photo printers, in a Printer Application Snap. Ghostscript Printer Application (Snap Store): Printer Application with Ghostscript and many other drivers, for practically all free-software-supported printers which are not PostScript and not supported by HPLIP or Gutenprint. It contains all the printer drivers for which there is no separate Snap. And Michael Sweet has also made a Printer Application for label printers, based on the label printer drivers which come with CUPS: LPrint (Snap Store): Supports Dymo LabelWriter and Zebra ZPL label printers, with all label-printer-typical options: Label modes, tear-off offsets, media tracking, media top offset, print darkness, resolution, roll selection, speed, ... Note that this is a native Printer Application. It does not simply encapsulate the CUPS filters and PPD files which come with CUPS. And there is also a Legacy Printer Application (included in the pappl-retrofit) project which, when classically installed (do not try to snap it) sees all classically installed CUPS drivers and makes them available in a Printer Application. This is especially useful for proprietary drivers. So we will not lose the support for any of the currently supported printers when switching over into the PPD-less, all-IPP New Architecture ... Now the third generation of printing with free software can start ... IPP, the Internet Printing Protocol, was originally designed as a network protocol, based on HTTP. So one could think that modern, driverless printers are only driverless if connected via the network, and not when connecte dvia USB. This is not the case, as fortunately, the situation was taken care of and driverless IPP printers do also IPP-over-USB, a standard to carry over the driverless nature of such a printer to USB. To get this also working under Linux a daemon is needed which connects to rhe USB device and on the other end listens on a port on localhost and advertises the printer via DNS-SD, so that it appears like a network printer for clients. The first approach was ippusbxd, a GSoC project by Daniel Dressler back in 2014. It is written in C and its architecture is simple: ippusbxd simply relays a TCP connection to USB. This does not work very well. I found Alexander Pevzner presenting his \"airscan\" SANE backend on the SANE mailing list and I told him that this is exactly what I need for driverless scanning support. So hea sked me to test his backend on my printer and we could weed out some bugs. Then I also wanted to know whether my printer which prints via IPP-over-USB would also scan via IPP-over-USB, even with scanning being eSCL and not IPP. So I tried his backend also via ippusbxd and it kind of worked but not really reliably. I told this to Alexander and he created the alternative approach ipp-usb with a first working version within a few hours, and solved my problem this way. I could print, scan, and use the web admin interface of the printer perfectly. About ippusbxd he writes: Unfortunately, the naive implementation, which simply relays a TCP connection to USB, does not work. It happens because closing the TCP connection on the client side has a useful side effect of discarding all data sent to this connection from the server side, but it does not happen with USB connections. In the case of USB, all data not received by the client will remain in the USB buffers, and the next time the client connects to the device, it will receive unexpected data, left from the previous abnormally completed request. Actually, it is an obvious flaw in the IPP-over-USB standard, but we have to live with it. So the implementation, once the HTTP request is sent, must read the entire HTTP response, which means that the implementation must understand the HTTP protocol, and effectively implement a HTTP reverse proxy, backed by the IPP-over-USB connection to the device. And this is what the ipp-usb program actually does. ipp-usb is written in Go, as Go provides an HTTP library with the needed functionality, which is missing in C. But as Go links executables statically, they have a large memory footprint. Therefore the ChromeOS developers do not accept Go programs and continued with ippusbxd for some time and later they came with another from-scratch approach, ippusb_bridge, written in Rust. Due to this there is no known operating system using ippusbxd any more. Therefore development of this project is currently suspended. Linux distributions use ipp-usb and with this driverless printing and scanning on USB-connected devices generally works. Only problem is that this connection type has many device-specific quirks and Alexander is following the reports and trying to fix as many as possible, producing an everytime longer list of quirk workarounds in ipp-usb's code. Especially there are also devices which support the IPP-over-USB USB protocol but not driverless printing and scanning. To support a local non-driverless printer with a Printer Application or a USB-connected driverless printer via IPP-over-USB, one has a daemon running on the local machine and wants to access the emulated IPP network printer from the same machine. In addition, for improved security and privacy one perhaps does not want to share the device in the local network, or one does not even have a network. Then only listening on \"localhost\" (the \"lo\", loopback interface) is the intuitive way to go. Problem with this was that the DNS-SD implementation on Linux, Avahi, did not support the loopback interface, so the device did not get advertised for auto-discovery and one had to manually set up a CUPS queue in order to print. To fix this I have looked into the source code of Avahi and found out that a tiny patch solves the problem and gives Avahi full support for the loopback device. As Trent Lloyd, upstream maintainer of Avahi, was very busy all the time, it took near 3 years until the patch got finally accepted, 10 days before Feature Freeze for Ubuntu 20.04 LTS. This got triggered by Alexander Pevzner, author of the Go-based ippusbxd alternative ipp-usb and the \"airscan\" eSCL SANE backend, when he reached out to Trent Lloyd in an e-mail thread about Debian packaging of his work and Trent answered that he will sort it and do a new release of Avahi before Feature Freeze of Ubuntu 20.04. He released version 0.8.0 with the localhost support included and my name is listed in the \"Thank you\" section of the release notes. Most modern printers do driverless IPP and many of them are multi-function devices with built-in scanner, and these ones do not only driverless printing but also driverless scanning! Driverless scanning means, as also for driverless printing, not needing a driver, where a driver is any type of device-model-specific software or data. And this means that the device has to use standard protocols, for which client software can easily be made part of the operating system. The standard here is AirScan, Apple's extension of AirPrint so that the complete multi-function device can be used with an iPhone or iPad. The underlying communication protocols are eSCL (an HTTP-based protocol, the more common one) and WSD (Web Services for Devices, from Microsoft), one of the two the device has to support in order to fulfill the standard. Back in 2019 the situation was really inSANE, there was no SANE backend supporting eSCL or WSD, but \"between the years\" 2019 and 2020, between Christmas and New Year I was reading great news on the SANE mailing list: Two independently developed backends for eSCL support got announced! These are “escl” (small, light, basic, already included in SANE 1.0.29) and “airscan” (complete functionality). And there is also an AirScan server, AirSane, which is a SANE frontend which emulates an AirScan (eSCL) scanner scanning on any physical scanner supported by SANE, so it is nothing more than an early Scanner Application. After that I worked a lot together with the authors to make it all working on my HP multi-function device and all this even made Alexander Pevzner, author of the “airscan” backend, replace the \"ippusbxd\" IPP-over-USB daemon with the completely new \"ipp-usb\" and made IPP-over-USB finally working reliably (see above). Both \"escl\" (as part of sane-backends) and \"airsane\" (separate package) made it into all major Linux distributions and so the scanners in thousands of multi-function printers are working under Linux now. And the specs of eSCL got finally published by Mopria in May 2021! From the March 2022 New 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 which comes with the foomatic-db-engine package directly from the XML data) we do the same as the distributions do also on the server now. 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 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. This is currently in the works."
+ },
+ {
+ "id": "page:codeofconduct",
+ "source": "static",
+ "type": "page",
+ "title": "Code of Conduct",
+ "url": "/codeofconduct",
+ "headings": [
+ "Our Pledge",
+ "Our Standards",
+ "Our Responsibilities",
+ "Scope",
+ "Enforcement",
+ "Attribution"
+ ],
+ "tags": [],
+ "snippet": "Code of Conduct",
+ "content": "In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Open Printing Code of Conduct Team at contact.openprinting@gmail.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. We will respect confidentiality requests for the purpose of protecting victims of unacceptable behavior. At our discretion, we may publicly name a person about whom we’ve received unacceptable behavior complaints, or privately warn third parties about them, if we believe that doing so will increase the safety of OpenPrinting members or the general public. We will not name victims without their affirmative consent. This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq"
+ },
+ {
+ "id": "page:contact",
+ "source": "static",
+ "type": "page",
+ "title": "Contact Us",
+ "url": "/contact",
+ "headings": [],
+ "tags": [],
+ "snippet": "Feel Free To Contact Us!",
+ "content": ""
+ },
+ {
+ "id": "page:contribute-website",
+ "source": "static",
+ "type": "page",
+ "title": "Contribute to OpenPrinting Website",
+ "url": "/contribute-website",
+ "headings": [
+ "Contributing",
+ "Bugs",
+ "Content Migration",
+ "Solving Issues",
+ "New Ideas"
+ ],
+ "tags": [],
+ "snippet": "Help us Make this Website Better.",
+ "content": "Please go through contributing.md before raising any issue or generating a Pull Request .You can contribute to this project in one of the following ways: Report Bugs Content Migration Solving Issues New Ideas If you find any bugs or issues in the website, please feel free to raise the issue on our github repository. Different browsers render CSS differently. If you find any inconsistency in CSS rendering, please report it. We need to move content from our old website to this website. If you want to move some page or some database, first create Issue for the same and then work on it. You can also help us solve Issues. If you have new ideas, please feel free to share them with the community. Raise a issue regarding your idea."
+ },
+ {
+ "id": "page:contribute",
+ "source": "static",
+ "type": "page",
+ "title": "Contribute",
+ "url": "/contribute",
+ "headings": [
+ "HELP!",
+ "DATA"
+ ],
+ "tags": [],
+ "snippet": "Helping the Advance of Linux Printing",
+ "content": "You can contribute to Openprinting by plenty of ways, so programming knowledge is not required. You can help with any of the following: Data Bug Reports User Support Programming Money, Hardware, Events,... As a user of a certain printer model, please post your experience in the “User Notes” section of your printers' page. Please tell with which driver and which option settings your printer works best, what is supported and what not, whether you use Foomatic or another setup infrastructure. Tell also whether the information in the printer's entry is correct (recommended driver, drivers which support the printer, comments, etc). Please report bugs in the entries also on our forums. If your printer is not listed yet, simply add it by clicking the appropriate links on the printer listings pages or the “Add similar printer” link on a printer entry page of a similar printer. The latter way saves you from a lot of typing as most fields get pre-filled. But be careful to change everything what is different on the new printer. Especially the auto-detection data you should obtain from the actual printer (see instructions on the printer input page). Or go directly to the add printer form. Also reporting that a printer does not work at all is important for us, users should be warned before they buy a “Paperweight”. Please try to make a complete and correct report; entering wrong or unreproducible data will more confuse than help. Developers might even attempt provide complete XML files. Downloading and installing the Foomatic packages gives an environment for testing. Refer to the format description in the end of the README of the foomatic-db-engine package. Do also the needed changes in driver and option XML files and generate a patch to our Bazaar repositories. See the instructions for contributors. If you're really ambitious, you could go through a printer manufacturer's web site and tabulate data in XML for all current models. If you have discovered a free software driver which is not listed, please tell us (in the driver comment field and also on the forums) the driver's home page. If the driver is not available for download any more, please send us the newest source package of it which you can get, so that we can re-host this driver. Please also tell us all your experiences, special tricks, which printers does it support, and how to use the driver. Also here providing XML data as described in the README of the foomatic-db-engine package is welcome. If you generate the XML files with scripts, please send us the scripts, too. You have developed or plan to develop a driver? Then please put it under a free software license and make it available for download (we can host it for you, if needed). Consider also using the OpenPrinting Vector, CUPS Raster, and IJS interfaces to connect your driver to GhostScript and under no circumstances patch it into GhostScript. This way users can easily add the driver to their systems. Include also a generator for PPDs and/or Foomatic data into your driver's source package, so that users can easily set up printer queues with your driver. This also makes it easier for us to list your driver on our site and for distributions to support your driver. Consult the README of the foomatic-db-engine package to obtain the necessary Foomatic background knowledge. If you are a printer manufacturer, test your printers to find which ones work with free software, or provide free software drivers. Ideally, provide Foomatic data and/or PPDs for your printers and drivers. This will lead to useful listings of your printers in the support database and good reports on the Vendor Info and Suggested Printers pages."
+ },
+ {
+ "id": "page:current",
+ "source": "static",
+ "type": "page",
+ "title": "OpenPrinting - What are we doing currently?",
+ "url": "/current",
+ "headings": [
+ "The New Architecture for printing and scanning",
+ "CUPS",
+ "CUPS 2.5.x",
+ "CUPS 3.x",
+ "cups-filters 2.x",
+ "Printer Applications",
+ "PAPPL",
+ "pappl-retrofit",
+ "Native Gutenprint Printer Application",
+ "Native HPLIP Printer Application",
+ "Braille Printer Application",
+ "Reviving legacy printers under Windows",
+ "Scanner Applications",
+ "GNOME Control Center - \"Printers\" module",
+ "The print dialogs",
+ "Optimizing DNS-SD browsing",
+ "Distribution-independent packaging",
+ "Printer Application look-up via the OpenPrinting web site"
+ ],
+ "tags": [],
+ "snippet": "Our current activity",
+ "content": "This page represents the state of August 2022 Even after having achieved many nice things in the last 21 years there is always a lot to do, especially currently, on the way to the New Architecture for printing and scanning, to make everything completely standards-conforming and get rid of obsolete methods and technologies. Also there has been a lot of development of the systems and environments for which we provide the print functionality. Our work will continue to improve software integration. For example, there will be continued work on the printer setup tools and print dialogs of different desktop environments and applications, packaging methods like Snap, Flatpak, Docker, ..., new forms of OS distributions (immutable core, all-Snap, ...), ... In addition we need to improve on things like CI and automated testing of our code. There will also be some work on documentation needed, especially for the APIs of our libraries. For all this we are always in search for contributors of the community. Therefore we are once reaching out by presenting on several conferences, like the OpenPrinting micro-conferences on the Linux Plumbers Conference (2019, 2020, 2021, 2022), Linux App Summit, GUADEC, ..., and also internet platforms, like Ubuntu on Air (YouTube channel). And second, we are participating in the Google Summer of Code (GSoC) every year, having 5-8 3-month projects each year and some of the contributors continue to work with us voluntarily. I am leading OpenPrinting as my day job, thanks to my full-time employment at Canonical, the company behind Ubuntu, right for doing that. Thanks a lot to Canonical for supporting printing on Linux and other POSIX-style operating systems this way. Of additional help for us is also general funding, for conference travel, printers and supplies for our contributors, or even our own internships, at any time in the year. For this we accept donations/funding via the Linux Foundation's LFX Croudfunding. Ubuntu Office Hours with Till Kamppeter, Aveek Basu, Divyasheel Kumar, and Pranshu Kharkwal, hosted by Monica Ayhens-Madon YouTube Video of the Ubuntu Office Hours with Till Kamppeter, Aveek Basu, Divyasheel Kumar, and Pranshu Kharkwal, hosted by Monica Ayhens-Madon Emphasis of our work at OpenPrinting is the New Architecture. 6 of our 7 GSoC contributors this year are working on it and also Michael Sweet's and my work are focused on it. Subject of the New Architecture is getting a streamlined, standards-conforming printing and scanning workflow without obsolete methods and technologies and integrating well into modern operating system and network environments. Ubuntu Desktop Team Indaba with Till Kamppeter and Michael Sweet, hosted by Heather Ellsworth and Monica Ayhens-Madon YouTube Video of the Ubuntu Desktop Team Indaba with Till Kamppeter and Michael Sweet, hosted by Heather Ellsworth and Monica Ayhens-Madon For 22 years now, since its 1.0 launch, CUPS uses principally the same architecture: PostScript was the standard job format as printers usually used with UNIX were PostScript devices. Capabilities of a printer are described by a PPD (PostScript Printer Description) file. The PPD file describes all user-settable options, resources (trays, paper sizes, resolution, quality, color, ...) in a static text file. To cover non-PostScript printers the PPD file format got extended (by Michael Sweet) to specify a filter to generate the printer’s native format. Filters use Ghostscript (or Poppler) to convert PostScript input. Print queues were manually created, with drivers (= PPDs + filters) assigned to them. We especially want to get rid of the PPD files, because ... In 1984 Adobe stopped development on PPDs (and also PostScript), so we started with an obsolete (but useful) format right away. In 2006 we abolished PostScript as print job format and replaced it by PDF. PPD files can represent user-settable options only as enumerated choice or boolean. Ugly workarounds for things like passwords or color adjustment are needed, implemented in CUPS and Foomatic. As CUPS was always following the standards of the Printer Working Group (PWG), a consortium of printer, OS, general IT, ... industry with which OpenPrinting works closely together and with Michael Sweet (author of CUPS) actively developing on the Internet Printing Protocol (IPP) for decades, we follow them even more to create an all-IPP CUPS without the legacy of PPD files and driver filters. These are exactly the established standards of driverless IPP (IPP Everywhere, AirPrint, Mopria) with print destinations advertising themselves via DNS-SD (also known as mDNS, ZeroConf, BonJour), communicating via pure IPP and using common data formats for print jobs (PDF, PWG Raster, Apple Raster, PCLm). CUPS 3.x will not support PPD files from the ground up. The CUPS Snap does not allow adding PPDs and filters as it consists of an immutable file system image in a security sandbox. Now only driverless IPP printers are supported. No manually created CUPS queues: IPP printer discovered, temporary queue automatically created (exception, CUPS sharing daemon). Filtering only for driverless standard formats: PDF, PWG Raster, Apple Raster, PCLm output, no need to add filters Current CUPS architecture Current CUPS architecture New CUPS architecture New CUPS architecture This will not only eliminate any obsolete technologies and methods, but it will also integrate much better in modern system environments, operating systems with with immutable core file system or distribution-independent, sandboxed packaging, like Snap, Flatpak, or Docker. This is due to the fact that components only interact via IP-based protocols like IPP and DNS-SD and no files or one component have to be installed in the file system of another, especially no binary executable files. So every component can be in its own sandbox and have its own immutable file system. Most modern printers, even the cheapest ones as manufacturers want to allow printing from smartphones, do driverless IPP printing, most commonly AirPrint but currently also Mopria. So they work perfectly under Linux and alike operating systems, currently and also after the transition to the New Architecture. But we will not drop or exclude legacy and specialty printers which do not do driverless IPP and therefore need a driver. There will be no printer drivers based on PPD files, and filter executables any more, but a completely new format, the Printer Applications. These are emulations of driverless IPP printers which internally convert the job data to the printer's native format and pass it on to the physical printer. This way CUPS only needs to deal with driverless IPP printers and manual creation of print queues (with drivers) is not needed any more. As modern multi-function devices do not only provide driverless IPP printing but also driverless eSCL (or WSD) network scanning. We go a similar way for scanning, creating Scanner Applications and so eliminate the need of SANE drivers which are libraries, dynamically linked by the application which scans, which is even worse for distribution-independent, sandboxed packaging. This way we can also create distribution-indpendent sandboxed packages for scanner and multi-function device drivers. This way the New Architecture also helps printer/scanner manufacturers who for some reason cannot or do not want to go driverless, can easily create and distribute drivers for their devices. CUPS is the standard print environment in Linux and other POSIX-style oprating systems for more than 20 years now.It is the daemon managing print queues with appropriate printer drivers, receiving, queueing, spooling, and printing print jobs from applications, sharing print queues on the netwok, ... With CUPS having moved from Apple to OpenPrinting, developemnt, especially of new fetures, has resumed. We do annual feature releases again and bug fix releases as needed inbetween. Michael Sweet has presented a roadmap for the further development o CUPS on the Linux Plumbers Conference 2021 (slides) and on the OpenPrinting Summit/PWG meeting 2022 (slides). Its development is supposed to start soon and it is scheduled to be released towards the end of 2022. This is the last series in the 2.x generation, still supporting the current architecture based on print queues with PPD files and printer-model-specific filters (aka drivers). The main new feature here is full support for OAuth authotization and OpenID authorization servers. There are IPP attributes to support OAuth (from slide 28 on). Especially also an interface (most probably D-Bus) bewtween cups and the a GUI tool for the user authentication is planned to be created. OAuth authentication should replace the more awkward Kerberos which requires root access. Also there are several free software implementations of OAuth support, especially also Michael Sweet's own mOAuth. The next generation of CUPS implements the New Architecture: Classic printer drivers based on PPDs and printer-model-specific filters are not supported any more. In adition, the CUPS project gets split into various smaller modules: libcups, commands, local server, sharing server. Release is scheduled for the end of 2023, meaning that until then all related software, like cups-filters, all printer drivers, print dialogs, printer setup tools, ... needs to be prepared for the New Architecture, which is subject of most of our work currently. Michael Sweet has already started the development on the new libcups3. Planned splitting of the project is as follows: libcups CUPS library Commands Command line interface: lp, lpstat, cancel, lpinfo, lpadmin, ... Local Server In case one only needs print functionality on the local machine and does not want to share out print queue to other machines, a simple user daemon (not running as root), the local server is used. Queues are automatically set up temporarily on discovered IPP printers, as current CUPS daemons already do. Manual queue creation is not supported, also no PPDs and no adding of filters. There is no web interface. The daemon is accessed through the usual domain socket and will get a new D-Bus API for GUIs connecting printing, authentication, and notifications. The daemon does listen on port 631. Profiles can be created to acces printers and servers outside the DNS-SD-discoverable local network. Sharing Server If print queues are supposed to get shared out to the network, the sharing server is used. It listens on port 631 for remote clients inquiries, and behaves as a standard IPP printer on the network. It has a web interface and can be configured similar to current (2.x) CUPS daemons. cups-filters provides filters (to convert data formats for printing) and backends (to communicate with printer hardware) for use with CUPS under non-Mac operating systems. The project originates in Apple (owner of CUPS that time) outsourcing the filters which were not used by Mac OS to OpenPrinting back in 2011. With the replacement of classic printer drivers consisting of PPD files and filter executables by Printer Applications we are also changing the architecture of cups-filters, in the new 2.x generation. The first time when I mentioned that the architecture of cups-filters needs to get changed and that for this I would start a cups-filters 2.x generation was in March and April 2020. Development started mid-2020 (2 years ago) with creating a libppd containing all PPD support functionality of libcups (in libcups3 it will get removed) for retro-fitting classic drivers and PostScript PPDs in July. The next step was turning all the individual filter executables into library functions, the filter functions, for being easily used by Printer Applications, starting in August and with this separating the cups-filter 1.x development into its own branch. These changes have been all performed already and have been made use of in the printer-driver-retro-fitting Printer Applications. To finalize cups-filters 2.x, the support for PPD files in the filter functions has been completely separated from libcupsfilters and moved into libppd, so that libcupsfilters can be installed without installing libppd and so distributions do not need to keep the PPD-file-retro-fitting library in their standard installation. Currently we are in the phase of final testing, code clean-up and separating the projects: libcupsfilters, libppd, cups-filters-legacy (the filter executabls), and cups-browsed, to allow the release of cups-filters 2.0b1, in the coming weeks. As mentioned earlier Printer Applications are the new format for printer drivers, emulations of IPP printers, to turn the all-IPP New Architecture into reality. They also can be easily put into sandboxed, distribution-independent packages like Snaps, for easy distribution of printer drivers by hardware manufacturers. We already have retro-fitted the drivers for ~10000 printer models, the drivers which are usually available in Linux distributions into 4 Printer Applications and put up those in the Snap Store, to not lose any printer support when switching to the New Architecture, but there are still a lot of things to do. Michael Sweet's PAPPL is the base for all currently available Printer Applications, the 4 retro-fitting ones of OpenPrinting and also Michael Sweet's LPrint and hp-printer-app. It provides everything which every Printer Application needs: A daemon which emulates an IPP printer A web interface to configure the printers (drivers, loaded media, default settings ... Advertising the printers via DNS-SD Receiving Apple/PWG Raster jobs and images and feeding the pixels into the actual driver Handling certificates and encryption ... This makes it much easier to create a Printer Application and one only needs to add the driver itself, what turns the jobs into the printer's native format, and what tells the outside world about the capabilities of the printer. PAPPL is nearly complete and currently Michael Sweet has added support for supply level readout and for localization of option and choice strings. PAPPL is under continuous development. pappl-retrofit is based on PAPPL and provides everything that Printer Applications which retro-fit classic CUPS drivers need: Convert PPD file collections into human-readable lists of supported printers Convert PPD options into printer IPP attributes and web interface options Manage installable accessories (like trays) and reflect the accessory configuration in the option lists Poll accessory configuration and default settings from the printer Manage list of loaded media for media-ready IPP attribute This reduces the effort of programming for creating a Printer Application to a minimum. Only a few lines of C to configure the Printer Application are needed. pappl-retrofit is nearly feature-complete and for the coming-soon 1.x release only support of the most recent PAPPL features, supply level read-out and localization will be added. Gutenprint, high-quality printer driver for many Epson and Canon inkjets, dye-sublimation photo printers, and several other printers, is already available as a retro-fitting Printer Application. As Gutenprint is under active development, we want to have a native Printer Application of it, meaning that we do not simply wrap its classic CUPS driver incarnation into a Printer Application with pappl-retrofit, but instead, make a Printer Application directly linking libgutenprint, getting rid of the restrictions and workarounds of PPD files, allowing full liberty of how to make all the options and adjustments available to the user. One must know that for some Epson inkjets there are more than 100 options in the PPD file, many of them are numeric, like color intensities, light/dark ink transitions, ... It is not urgent as for switching a distribution over into the New Architecture (for example when using the CUPS Snap, or even making the distribution all-Snap) we already have the retro-fitting Gutenprint Printer Application. Options for Epson inkjet printer in the Gutenprint Printer Application Options for Epson inkjet printer in the Gutenprint Printer Application Another printer driver which is under active development and therefore should be available as native Printer Application, maintained by its developers, is HPLIP (HP Linux Imaging and Printing). I am not yet suggesting to the HPLIP developers at HP to create a Printer Application from HPLIP as the thing blocking from creating a Printer Application is the missing scanning support in PAPPL. Many of HP's printers are multi-function devices and the classic HPLIP driver also includes a SANE driver for the scanners. For the printing part of HP's devices we have at least a retro-fitting Printer Application for the time being, even with support for HP's proprietary plugin. Installing HPLIP's proprietary plugin in the HPLIP Printer Applications Installing HPLIP's proprietary plugin in the HPLIP Printer Applications Accessibility is an important part of an operating system for everyone's daily use. This does not only mean an accessible user interface but also support for devices which serve for accessibility, like Braille embossers for written communication with blind people. Therefore we need to support them like we support usual printers, which deposit visible markings on the media surface. Our support for Braille embossers is currently provided in the cups-filters project and, to not lose the support when switching into the New Architecture we currently have Chandresh Soni creating a Braille Printer Application as a Google Summer of Code (GSoC) project, with me and upstream maintainer Samuel Thibault as mentors. I am working at Canonical in the Desktop Team, my job being leading the OpenPrinting project, and in the Desktop Team we also have a sub-team working on WSL (Windows Subsystem for Linux), a facility to run Linux applications under Windows. This brought me to the idea of running Printer Applications under WSL, to revive legacy printers which got abandoned by Microsoft and also by their manufacturers. My first public mention of this idea was during the virtual release party of Ubuntu 22.04 on the LAS 2022, in my second part praising the WSL team. The first working implementation of this idea is available now, the first HOWTO of WSL team member Carlos Nihelton, which he has worked out and written in cooperation with me. Thanks a lot to him! Creating Windows print queue to Printer Application running under WSL Creating Windows print queue pointing to Printer Application running under WSL It works, but it is still somewhat awkward, as it requires to compile the Printer Application and its dependencies (pappl-retrofit and PAPPL) from source. We will update the HOWTO as the development of WSL progresses. With WSL using systemd, supporting DNS-SD via Avahi, using AppArmor, and finally getting snapd working in it things will get easier, finally hopefully just in a Snap! Each step of development will remove steps from the HOWTO. My intention is to present the idea at the Ubuntu Summit in November, and I hope in a much easier implementation than it is currently. Most modern printers do driverless IPP and many of them are multi-function devices with built-in scanner, and these ones do not only driverless printing but also driverless scanning! We have Linux support for the underlying scanning protocols eSCL and WSD and the eSCL communication protocol is also published, but what we still do not have is PAPPL support for scanning, to easily create Scanner Applications for non-driverless scanners as we already have Printer Applications. Currently, we have the SANE backends as scanner drivers, which are dynamically linkable libraries. They must be put into a defined system directory to be found by the applications which scan and they also need to have binary compatibility with the applications. This can usually only be achieved by applications and scanner drivers being built for the host operating system distribution, for security reasons even preferably by the maintainers of the distribution. With scanner drivers packaged as Scanner Applications we have the same advantages as with Printer Applications for printing. We only have IP communication, in our case DNS-SD and the HTML-based eSCL between application and scanner driver and so we can do sandboxed, distribution-independent packaging of the applications and of scanner drivers, allowing the two components being in separate sandboxes. This way scanner manufacturers can distribute their drivers in distribution-independent packages (like Snaps) and they work with all applications, also third-party ones which come as Snaps or Flatpaks. And for multi-function devices the Printer Application can provide both printing and scanning support, which makes setting up the device much easier, just in a (single) Snap! We have already tried to add scanner support to PAPPL but contributors dropped out during the pandemic and so we are only able to complete the support in this year's GSoC. The base for the API got already being done last year by Bhavna Kosta (Slides of Linux Plumbers 2021). Then this year we have 2 contributors: Rishabh Maheshwari does the eSCL parser and Deepak Khatri does the interface to the driver for the actual scanner. Mentoring is done mainly by me but also by Deepak Patankar, who also started as a GSoC contributor for OpenPrinting some years ago and also already mentored for us. Having this working we will do: SANE scanning support in pappl-retrofit Create a Scanner Application from sane-backends and also Scanner Applications from other SANE drivers and snap (= create Snaps of) them. When snapping user applications which scan, only include sane-airscan for scanning support, as this is enough to connect with the snapped scanner drivers. Add scanning support to our retro-fitting HPLIP Printer Application Suggest HP's developers to create a native HPLIP Printer Application, which supports both printing and scanning. Unfortunately, not every printer is immediately ready for printing by just connecting it and turning it on, especially printers which need a driver or printers on a network other than the local network. Therefore we also still need a printer setup tool even in a world of driverless IPP printing. The most used printer setup tool is probably the \"Printers\" module of the GNOME Control Center. Simply because most Linux distributions use GNOME as their default desktop. The functionality of printer setup tools is usually more or less the same: In a main panel all CUPS print queues are listed and one has buttons/menus on each entry to configure the queue, default option settings, driver, ... On the main panel there is also a button to open the panel to add a new printer, which means creating a new CUPS queue. Here one chooses a discovered printer and assigns a (classic) driver to it (which is often done automatically). The New Architecture requires some changes but the UI will still look very similar afterwards. The main panel will show IPP print services instead of CUPS queues, as now all printers are driverless IPP printers for CUPS (3.x), either network printers or Printer Applications, and CUPS queues are created automatically on-demand. So the user now configures the IPP printers, via their web admin interfaces and/or IPP System Service. The IPP service entries in the printer setup tools have therefore buttons/menus to access these configuration facilities there. There will also be the \"Add Printer\" button, but on the panel for adding a printer discovered printers will only be listed if they are not driverless IPP printers and need a Printer Application. Buttons and menus allow operations to find and install the correct Printer Application and make the printer connected with it. After that the printer appears as IPP print service on the main panel. These changes are currently being worked on, in a way that the \"Printers\" module works with both the current CUPS and also in the New Architecture, simply by listing both CUPS queues and IPP services, and so showing all available printers, both with permanent CUPS queue and also those for which CUPS would create a temporary queue on-demand, and in both cases the user is directed to the correct configuration interfaces. The add-printer panel will also support both Printer Applications and classic drivers. After the switchover to the New Architecture the unavailable items will simply not get displayed. The coding is done in a nice sub-team of two GSoC contributors plus their mentors. In addition, code of the last two year's GSoCs get made use of, too. Shivam Mishra does the main panel with all ist functionality and Mohit Verma the add-printer panel. Mentoring is done by me, by Divyasheel Kumar (worked on listing IPP services last year), and upstream maintainer Marek Kasik. Several feature requests are posted on GNOME's and cups-pk-helper'a GitLab repositories and there the coding work gets discussed: GNOME #1877: Improve setting of IPP options GNOME #1878: Allow to add new printers via Printer Applications GNOME #1879: Do not show setting of drivers for IPP printers GNOME #1911: Printers: Make adminurl available for IPP printers cups-pk-helper #7: Added discovery of Printers via lpinfo, PAPPL and Printer Applications Also print dialogs need changes for the New Architecture. They first of all should not try to download the print queue's PPD files via CUPS' HTTP interface or even worse, grab them from the local file system. Second they need to support temporary CUPS queue, those queues for IPP printers which are created on-demand when polling the printer's capabilities or sending a job. The latter print dialogs should have been supported already, but several still are not. The most obvious approach would be that all print dialogs (GTK, Qt, LibreOffice, Firefox, Chromium, ...) get changed appropriately, but this requires the maintainer's, often volunteers, time, is not top-priority in the projects, ... and so takes time if done at all. Therefore we created the concept of the Common Print Dialog Backends (CPDB) to not only let all print dialogs support multiple print technologies (CUPS, print to file, cloud printing services, ...) but also move the responsibility of correct support of each print technology to the maintainers of that print technologies, for example to OpenPrinting for CUPS. This is done by the print technology support being in separate modules (backends) which are available to the print dialogs as D-Bus services. This way the backends can get updated separately and they can also be in separate sandboxed packages, allowing easy Linux support for any cloud/online printing service provider. Currently, GSoC contributor Gaurav Guleria (mentored by me and upstream manintainers Marek Kasik, Matthias Clasen, and Albert Astals Cid) is working on CPDB support for the print dialogs. He already completed the GTK dialog (Merge Request with discussion) and also did a lot of fixes and improvements on CPDB itself. Now he is working on the Qt dialog to add CPDB support also there, to make it finally cute. DNS-SD is an important concept for the printing. By the current standards, network printers, especially IPP printers advertise themselves in the local network via DNS-SD, telling about how they are accessed (IP, port, resource -> makes up URI), model name, and basic capabilities, job data formats, paper size class, duplex, scanner, fax, ... This way clients can find and use printers automatically (which is supported by CUPS). Once the client knows about the presence of an IPP printer it polls its full capabilities by a get-printer-attributes IPP request and is ready to print. Because of this, several components of CUPS and cups-filters call functions of the Avahi library, in order to ask avahi-daemon whether there are any devices in the network which provide IPP print services: The CUPS daemon to be able to create temporary print queues for IPP printers, the dnssd CUPS backend to find all kinds of network printers, cups-browsed to find IPP printers and remote CUPS queues to form clusters, the driverless utility to emulate a driver for driverless printers to set them up with classic printer setup tools, ... As the DNS-SD browsing with Avahi always follow the same scheme, getting a list of all services of a given type (browsing, very fast) and the getting detailed information of a given service (resolving, needs time) we have a lot of code duplication here. Also we have performance problems because in browsing one gets many duplicate listings as the same device can appear under several network interfaces (and one can have many: local, wired, wireless, virtual machines, ...), HTTP/HTTPS, IPv4/Ipv6 and if not identifying these duplicates one can spend a lot of time on unnecessary resolving. Sachin Thakan, mentored by me, is working on optimizing this in this year's GSoC. Linux distributions are usually composed of binary packages (RPM or DEB in most cases), for the kernel, for systemd, for CUPS, for applications, ... so that the user can easily put together their system without needing to compile anything. The problem is here that these packages are made for only one version of a distribution, for example for Ubuntu 22.04. They are also usually made by the maintainers of this distribution, not by the maintainers of the packaged application. Also there are no new versions of an application packaged for an already released distribution version. To overcome this, and get a packaging system which is distribution-independent and also to get enough security to run third-party binary code, sandboxed packaging methods were introduced. Each package comes with all its libraries and other parts it depends on in a security-encapsulated sandbox. Also what comes with the package is an immutable, manipulation-proof file system image. It also can only communicate with the host system and other packages only through well-defined channels. The most sophisticated system in terms of security and flexibility is Snap because it is very similar to smartphone app packaging. See also the Ubuntu Indaba with Mark Shuttleworth. This is also the system I have most experience with. Right when it was launched back in mid-2017 I started snapping (packaging as a Snap) CUPS. I posted several feature requests on Snap and worked together with the Snap developers to integrate the CUPS Snap in the Snap infrastructure, creating an interface for snapped applications being able to safely print without being able to mess up the system. Not only CUPS, but also ipp-usb and the 4 retro-fitting Printer Applications I have snapped and are available in the Snap Store. I am regularly updating all of these for new versions of the contained classic printer drivers and other included software. Having snapped CUPS I wondered why not packaging CUPS also in other formats, as Flatpak or AppImage. I investigated and found out the following: Flatpak is not suitable: It is especially made for desktop/GUI applications. One cannot package daemons. The packaged app cannot be run as root. The channels to communicate with the outside world are not file system mounts or AppArmor allowances as with Snap, but portals, D-Bus interfaces to common GUI dialogs as \"Open\", \"Save as ...\", and \"Print\". AppImage is not suitable, too: AppImage does nothing more than providing an immutable file system image with the packaged application and all its libraries and other dependencies. It is an executable which simply opens the file system and runs the included application. There is no security concept, the application has access to the whole system (or at least to what the invoking user has access to). There is also no support for daemons, like for example auto-starting it. Docker is an alternative: Especially on systems based on a minimal/immutable/atomic/image-based OS designed for applications being installed as Flatpaks or systems not based on systemd, not using AppArmor, Snaps cannot get installed and an alternative method to install distribution-independent packages of CUPS and Printer Applications is needed. Here Docker images (OCI-compatible containers) as official versions from OpenPrinting on DockerHub were suggested. I had some discussion with Robert McQueen and he posted on the Flatpak list and then there were further suggestions. After releasing cups-filters 2.0b1 and pappl-retrofit 1.0b1 I will look into creating the Docker images of CUPS and the Printer Applications. The part of the website for looking up (legacy, non-driverless) printers and drivers (the OpenPrinting database web app has successfully moved to a new server at Oregon State University Open Source Lab (OSUOSL). Violet Kurtz and Lance Albertson, both from OSUOSL have helped a lot on this. This is the base for being able to do further development and updates on our web app, especially the Printer Application look-up service which is needed for the printer setup tools to find the correct Printer Application to install when submitting the printer's device ID as search term. The service is especially needed as the developers of the Snap Store did not show interest on hardware-signature-based search and we also want to provide the Printer Applications in other formats in the future. Violet Kurtz is making good progress on the extension of the web app for this functionality."
+ },
+ {
+ "id": "page:databaseintro",
+ "source": "static",
+ "type": "page",
+ "title": "Printer Compatibilty Database",
+ "url": "/databaseintro",
+ "headings": [],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "page:documentation",
+ "source": "static",
+ "type": "page",
+ "title": "Documentation",
+ "url": "/documentation",
+ "headings": [],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "page:donations",
+ "source": "static",
+ "type": "page",
+ "title": "Donations",
+ "url": "/donations",
+ "headings": [],
+ "tags": [],
+ "snippet": "Thanks for showing interest in supporting OpenPrinting. There are many ways in which you can support OpenPrinting: We require hardware for testing and development purpose. If you...",
+ "content": "Thanks for showing interest in supporting OpenPrinting. There are many ways in which you can support OpenPrinting: We require hardware for testing and development purpose. If you have some spare hardware(printers, scanners, network print boxes ), please consider donating them to us. Sponsor events like Printing Summits and LF OpenPrinting meetings(Travel/accommodation for attendees, catering, ...). We are also grateful for invitations to get to free software events, congresses and fairs. If you want to support OpenPrinting in some other way(like Monetary,...), please contact Till Kamppeter. For contacting us, pleace check Contact Us page."
+ },
+ {
+ "id": "page:download",
+ "source": "static",
+ "type": "page",
+ "title": "Downloads",
+ "url": "/download",
+ "headings": [],
+ "tags": [],
+ "snippet": "{% include feature_row id=\"intro\" type=\"center\" %} {% include feature_row %}",
+ "content": "{% include feature_row id=\"intro\" type=\"center\" %} {% include feature_row %}"
+ },
+ {
+ "id": "page:downloads",
+ "source": "static",
+ "type": "page",
+ "title": "Downloads",
+ "url": "/downloads",
+ "headings": [],
+ "tags": [],
+ "snippet": "{% include feature_row id=\"intro\" type=\"center\" %} {% include feature_row %}",
+ "content": "{% include feature_row id=\"intro\" type=\"center\" %} {% include feature_row %}"
+ },
+ {
+ "id": "page:driverless",
+ "source": "static",
+ "type": "page",
+ "title": "Driverless Printing",
+ "url": "/driverless",
+ "headings": [],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "page:gsod",
+ "source": "static",
+ "type": "page",
+ "title": "GSoD - OpenPrinting",
+ "url": "/gsod",
+ "headings": [
+ "Year-Wise GSoD Project List",
+ "1. GSoD 2020",
+ "Year-Wise GSoD Students",
+ "1. GSoD 2020"
+ ],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "page:gsod2020",
+ "source": "static",
+ "type": "page",
+ "title": "GSoD 2020 Projects",
+ "url": "/gsod2020",
+ "headings": [],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "page:history",
+ "source": "static",
+ "type": "page",
+ "title": "OpenPrinting - How did this all begin?",
+ "url": "/history",
+ "headings": [
+ "System Administrator in the Physics Department",
+ "MandrakeSoft in Paris",
+ "The Linux Foundation and Canonical"
+ ],
+ "tags": [],
+ "snippet": "A brief history of OpenPrinting",
+ "content": "This is about how I got into printing with free software, and how I made it to what I am now. If you want to know what we all achieved at OpenPrinting up to now, see what we have done so far. I have studied Physics at the university, not computer science, but always had a computer and liked programming. I had my first (Commodore VC20, 3.5K of RAM) with 16 years of age. In the time from 1996-2000 I did my PhD in Theoretical Physics and from 1997 on I was also system administrator for the department. The machines were all UNIX workstations (SGI and DEC) and to get workplace computers for everyone my first task was to set up Linux PCs (SUSE in that time). This way I got in contact with the wonderful world of free software. Programming work for the system administration (not the Fortran work for the PhD itself) was mainly to make things working in our department, especially also for the less IT-savvy professors. A first task which I contributed upstream were modifications on X-CD-Roast (an early GUI for recording CDs) to make it working in multi-user environments. We had also printers, PostScript lasers with 2 trays and duplex. The LPD printing system did not support passing printer-specific options along with jobs, so the admins before me created a wild hack to control these resources. Then we also got a color laser with many more options and these options were only accessible via proprietary GUIs on the commercial UNIXes (SGI and DEC) in our LPD environment. In spring 2000 I read an article about CUPS in the German \"Linux Magazin\" written by Kurt Pfeifle. CUPS was supporting PostScript printers perfectly with its PPD concept. I tried it and one could print on all our printers with all their bells and whistles, from all machines, also the Linux ones, and on all printers, including the color laser. And clients see the server's print queues automatically. So I adopted it in the department's network. Only disadvantage was that one could control everything only via the command line. GUI print dialogs were available from Michael Sweet, the author of CUPS, but only as proprietary, paid software. So I wrote a print dialog by myself, called it the \"X Printing Panel\", XPP (so I got the father of Linux print dialogs). This way everyone could easily fully control the printers, also the not so IT-savvy people in the department. It took me only around 10 days to get this together, but in the end I wanted to make it available for everyone. So I announced it on Freshmeat, and shortly after I got feedback, an invitation from Kurt Pfeifle, the author of the CUPS article in the \"Linux Magazin\", to the LinuxTag, the biggest Linux show in Europe that time, to present my little project on the booth of his employer, the printer service company Danka (later on overtaken by Ricoh). Most distributions did not show much interest but MandrakeSoft from Paris (later Mandriva) did. They showed me already on the booth how their development workflow works, and on the social event the told me everything of the daily life in their office. And some days after the show I got an e-mail with the invitation to work for them. By the way, on that LinuxTag I also met Richard Stallman, who invented the free software concept, and he also suffered a printing problem, and that led him to that step, as I also had a problem with printing, and got what I am today. So in the beginning of July 2000 I was on the LinuxTag and on August 1 2000 I lived in Paris, not knowing any word of French. Inside MandrakeSoft we were speaking English as they hired many people from other countries and they sent us all to French classes. My first task was to switch Mandrake Linux to the CUPS printing system and I succeeded already with the first release after my employment, which came out in fall 2000. To get PPD files for all, especially non-Postscript, printers I used linuxprinting.org (the site which provided Foomatic in that time) and asked its author, Grant Taylor, for a lot of improvements on it. In 2001 I had overtaken maintainership of the project, as Grant did not have time for it any more. The server was running in his house though, till 2006. In 2001 I got invited to the HP- and IBM-hosted OSDN Printing Summit in San Jose (Report from Grant Taylor), where I met several people of the printer manufacturers and of the PWG (Printer Working Group) and with them (Tom Hastings, Michael Sweet, Ira McDonald, Claudia Alimpich, Glen Petrie and, Norm Jacobs) I founded OpenPrinting as part of the Free Standards Group (FSG). In the following years I did not only do coding and packaging to improve printing, but also a lot of community work, CUPS evangelism, especially I organized a community booth about printing on the LinuxTag every year from 2001 to 2006, gave talks and tutorials on several conferences, mainly in Germany and Brazil, ran developer meetings on conferences in France, and participated in the work of creating printing APIs via phone meetings of the OpenPrinting people. Also all distributions switched to CUPS (with Foomatic) as their standard printing environment. The other printing systems disappeared and did not get maintained any more, probably due to lack of user interest. From 2001 on MandrakeSoft was not going well, was a sinking ship which (fortunately) actually sunk only in 2015. In Fall 2005 I was running a community booth on the Linux Expo in San Francisco and there I discussed with the folks that we need a meeting to plan how to improve printing and develop it further and we concluded to organize a Printing Summit in 2006, which I started to organize. End of 2005 I was invited on a Desktop Architects Meeting of the OSDL where I also advertised my plans of a Printing Summit and also got inspired to post on the GNOME mailing list that they should improve their print dialog to properly support CUPS as this was the standard. The first answer then came from Linus Torvalds, calling the GNOME guys \"interface nazis\" and that triggered a sh*tstorm, which was also mentioned in the end-of-year news reviews of 2005. But the GNOMies created the better dialog actually some time in 2006! The Printing Summit in 2006 was a great success. It was hosted by Lanier in Atlanta and I succeeded to get nearly everyone important for printing with free software to there, people of several manufacturers, distributions, drivers, Ghostscript, GUI environments, user interface experts, Mike Sweet (author of CUPS), ... There was also IAN Murdock, one of the founders of DebIAN. He was working for the FSG and I asked him whether the FSG could host linuxprinting.org (Foomatic) as manufacturers have already uploaded PPDs there but it was still running in Grant's house and an official download place deserves the security and reliability of a data center. But shortly after the Summit it came even better: The FSG did not only want to host Foomatic but also me. They invited me to work full-time on OpenPrinting and expand OpenPrinting to cover everything about printing with free software, especially also merge in linuxprinting.org. In 2006 I also had my last booth on the LinuxTag and there I met Mark Shuttleworth, founder of Canonical and Ubuntu. He also invited me for working as printing guru of Ubuntu. So from mid-2006 on I worked mainly for OpenPrinting but also for packaging the printing stack in Ubuntu. This is my work still today, but currently fully paid by Canonical. In 2007 the FSG and the OSDL joined to be the Linux Foundation and so I was their employee. I also got fellow member of the Linux Foundation which I am till today. From then on I did everything to make printing \"just work\" in non-Mac Unix/Posix-style operating systems. I held OpenPrinting Summits every year, later in collaboration with the Printer Working Group (PWG), work with manufacturers on doing printer drivers correctly, implement PWG standards in free software, ... From 2008 on I started organizing the participation of the Linux Foundation in the Google Summer of Code and got accepted for all but one year until now. Many students worked this way for OpenPrinting and recently we got together a student community to work on development tasks, like our new web site and also on mentoring further GSoC contributors. And here is what we have all done so far."
+ },
+ {
+ "id": "page:lfmp",
+ "source": "static",
+ "type": "page",
+ "title": "LFMP - OpenPrinting",
+ "url": "/lfmp",
+ "headings": [
+ "Year-Wise LFMP Project List",
+ "1. LFMP 2020",
+ "Year-Wise LFMP Students",
+ "1. LFMP 2020"
+ ],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "page:lfmp2020",
+ "source": "static",
+ "type": "page",
+ "title": "LFMP 2020 Projects",
+ "url": "/lfmp2020",
+ "headings": [],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "page:projects",
+ "source": "static",
+ "type": "page",
+ "title": "Projects",
+ "url": "/projects",
+ "headings": [],
+ "tags": [],
+ "snippet": "OpenPrinting is reponsible for development of many opensource printing projects.",
+ "content": "OpenPrinting is reponsible for development of many opensource printing projects."
+ },
+ {
+ "id": "page:upcoming-technologies",
+ "source": "static",
+ "type": "page",
+ "title": "Upcoming Technologies in Printing from Linux",
+ "url": "/upcoming-technologies",
+ "headings": [],
+ "tags": [],
+ "snippet": "",
+ "content": ""
+ },
+ {
+ "id": "page:wsl-printer-app-compile",
+ "source": "static",
+ "type": "page",
+ "title": "Reviving an older printer with Ubuntu WSL and Printer Applications",
+ "url": "/wsl-printer-app-compile",
+ "headings": [
+ "Introduction",
+ "How to"
+ ],
+ "tags": [],
+ "snippet": "I have an old HP OfficeJet J4660 series printer for which Windows 11 doesn't offer drivers and I can only use that printer when I’m on Ubuntu. Working in the Ubuntu WSL team means...",
+ "content": "I have an old HP OfficeJet J4660 series printer for which Windows 11 doesn't offer drivers and I can only use that printer when I’m on Ubuntu. Working in the Ubuntu WSL team means I work a lot of time on Windows, thus sometimes it makes sense to be able to print some stuff, like when I need to make my copilot happy painting some complex piece of art. Unfortunately I was not able to do it. Until now. Sad painter Powered by Ubuntu WSL and Printer Applications, we can expose any printer Ubuntu has drivers for as an IPP Everywhere printer and connect it to Windows. The Printer Application emulates a driverless IPP printer, so that the printing system does not need to distinguish, it simply needs to support driverless IPP printers. The following how-to guide lists the steps required to be able to run the HPLIP Printer Application inside Ubuntu WSL and accessing the printer on Windows. That can be considered the dirty way, since WSL cannot yet support snaps. When that day comes, all complex compilation and running steps below will simply be replaced by one snap install command. Notice that WSL 2 is required. We will use Ubuntu 22.04.1 LTS for this guide. (Ubuntu 20.04 and older releases won’t work due certain packages required to be in newer versions than the ones offered by those releases). It’s necessary to point out that the following steps would simply be impossible without the amazing usbipd-win project, which offers a Windows software for sharing locally connected USB devices to other machines, including Hyper-V guests and WSL 2. We use it to make the printer visible inside Ubuntu WSL. Connect the printer to the USB port. Make sure it’s not supported on Windows by checking Settings > Bluetooth & devices > Printers & scanners. Printers & Scanners Install the usbipd-win software. The easiest way is through winget. Open Powershell and issue the following command: winget install --interactive --exact dorssel.usbipd-win An alternative way is downloading the installer from the GitHub repository releases page and executing it. It will display a regular setup wizard. Follow its steps until the end. When prompted, accept the dialog to elevate permissions. In the end restart your computer to let the system changes take effect. Setup USB IPD Reboot Windows Install the Linux counterpart inside Ubuntu WSL. Refer to the project’s wiki for further information. Check your devices. Take note of the printer’s bus ID (in this case 1-3): Attach the printer to Ubuntu WSL. Run that command as administrator, if that’s the first time. For this case