OPEN PRINTING

As the software components we develop at OpenPrinting are an essential part of the operating system infrastructure, we want to have a solid CI testing of each commit to our GitHub repositories. CUPS (“cups” repository for 2.x) has already excellent CI done by Michael Sweet, consisting of GitHub actions/workflows which automatically apply static analysers, build and execution tests on different architectures and distros, This we want to have also in the other projects on OpenPrinting. **Note: As we have several repositories where we want to add improved CI testing, we can accept more than one contributor, each working on one of our repositories.**

Creating GitHub workflows and make them triggered with commits • Scripting to run analysers, build code, run test programs • C programming to write test programs

The contributor will study at first the CI done by Michael Sweet, especially in OpenPrinting’s CUPS repository but also in the repositories of Michael’s personal GitHub, especially PAPPL, PDFio, … Michael is an excellent example here. Then they will check the repository of the OpenPrinting project they are working on and implement the same functionality there. One part is to overtake and adapt the scripting, which is probably the smaller part, the other is to add extra tests to the “make check” run which will get executed after each build test. Each added test functionality the contributor will have to test, and make sure that if the code under test is OK, the tests pass and in case of the tests failing to check whether it is their fault or a bug in the code under test (which they report).

As the software components we develop at OpenPrinting are an essential part of the operating system infrastructure, we want to have a solid CI testing of each commit to our GitHub repositories. CUPS (“cups” repository for 2.x) has already excellent CI done by Michael Sweet, consisting of GitHub actions/workflows which automatically apply static analysers, build and execution tests on different architectures and distros, This we want to have also in the other projects on OpenPrinting. **Note: As we have several repositories where we want to add improved CI testing, we can accept more than one contributor, each working on one of our repositories.**

Creating GitHub workflows and make them triggered with commits • Scripting to run analysers, build code, run test programs • C programming to write test programs

The contributor will study at first the CI done by Michael Sweet, especially in OpenPrinting’s CUPS repository but also in the repositories of Michael’s personal GitHub, especially PAPPL, PDFio, … Michael is an excellent example here. Then they will check the repository of the OpenPrinting project they are working on and implement the same functionality there. One part is to overtake and adapt the scripting, which is probably the smaller part, the other is to add extra tests to the “make check” run which will get executed after each build test. Each added test functionality the contributor will have to test, and make sure that if the code under test is OK, the tests pass and in case of the tests failing to check whether it is their fault or a bug in the code under test (which they report).

As the software components we develop at OpenPrinting are an essential part of the operating system infrastructure, we want to have a solid CI testing of each commit to our GitHub repositories. CUPS (“cups” repository for 2.x) has already excellent CI done by Michael Sweet, consisting of GitHub actions/workflows which automatically apply static analysers, build and execution tests on different architectures and distros, This we want to have also in the other projects on OpenPrinting. **Note: As we have several repositories where we want to add improved CI testing, we can accept more than one contributor, each working on one of our repositories.**

Creating GitHub workflows and make them triggered with commits • Scripting to run analysers, build code, run test programs • C programming to write test programs

The contributor will study at first the CI done by Michael Sweet, especially in OpenPrinting’s CUPS repository but also in the repositories of Michael’s personal GitHub, especially PAPPL, PDFio, … Michael is an excellent example here. Then they will check the repository of the OpenPrinting project they are working on and implement the same functionality there. One part is to overtake and adapt the scripting, which is probably the smaller part, the other is to add extra tests to the “make check” run which will get executed after each build test. Each added test functionality the contributor will have to test, and make sure that if the code under test is OK, the tests pass and in case of the tests failing to check whether it is their fault or a bug in the code under test (which they report).

As the software components we develop at OpenPrinting are an essential part of the operating system infrastructure, we want to have a solid CI testing of each commit to our GitHub repositories. CUPS (“cups” repository for 2.x) has already excellent CI done by Michael Sweet, consisting of GitHub actions/workflows which automatically apply static analysers, build and execution tests on different architectures and distros, This we want to have also in the other projects on OpenPrinting. **Note: As we have several repositories where we want to add improved CI testing, we can accept more than one contributor, each working on one of our repositories.**

Creating GitHub workflows and make them triggered with commits • Scripting to run analysers, build code, run test programs • C programming to write test programs

The contributor will study at first the CI done by Michael Sweet, especially in OpenPrinting’s CUPS repository but also in the repositories of Michael’s personal GitHub, especially PAPPL, PDFio, … Michael is an excellent example here. Then they will check the repository of the OpenPrinting project they are working on and implement the same functionality there. One part is to overtake and adapt the scripting, which is probably the smaller part, the other is to add extra tests to the “make check” run which will get executed after each build test. Each added test functionality the contributor will have to test, and make sure that if the code under test is OK, the tests pass and in case of the tests failing to check whether it is their fault or a bug in the code under test (which they report).

As the software components we develop at OpenPrinting are an essential part of the operating system infrastructure, we want to have a solid CI testing of each commit to our GitHub repositories. CUPS (“cups” repository for 2.x) has already excellent CI done by Michael Sweet, consisting of GitHub actions/workflows which automatically apply static analysers, build and execution tests on different architectures and distros, This we want to have also in the other projects on OpenPrinting. **Note: As we have several repositories where we want to add improved CI testing, we can accept more than one contributor, each working on one of our repositories.**

Creating GitHub workflows and make them triggered with commits • Scripting to run analysers, build code, run test programs • C programming to write test programs

The contributor will study at first the CI done by Michael Sweet, especially in OpenPrinting’s CUPS repository but also in the repositories of Michael’s personal GitHub, especially PAPPL, PDFio, … Michael is an excellent example here. Then they will check the repository of the OpenPrinting project they are working on and implement the same functionality there. One part is to overtake and adapt the scripting, which is probably the smaller part, the other is to add extra tests to the “make check” run which will get executed after each build test. Each added test functionality the contributor will have to test, and make sure that if the code under test is OK, the tests pass and in case of the tests failing to check whether it is their fault or a bug in the code under test (which they report).

As the software components we develop at OpenPrinting are an essential part of the operating system infrastructure, we want to have a solid CI testing of each commit to our GitHub repositories. CUPS (“cups” repository for 2.x) has already excellent CI done by Michael Sweet, consisting of GitHub actions/workflows which automatically apply static analysers, build and execution tests on different architectures and distros, This we want to have also in the other projects on OpenPrinting. **Note: As we have several repositories where we want to add improved CI testing, we can accept more than one contributor, each working on one of our repositories.**

Creating GitHub workflows and make them triggered with commits • Scripting to run analysers, build code, run test programs • C programming to write test programs

The contributor will study at first the CI done by Michael Sweet, especially in OpenPrinting’s CUPS repository but also in the repositories of Michael’s personal GitHub, especially PAPPL, PDFio, … Michael is an excellent example here. Then they will check the repository of the OpenPrinting project they are working on and implement the same functionality there. One part is to overtake and adapt the scripting, which is probably the smaller part, the other is to add extra tests to the “make check” run which will get executed after each build test. Each added test functionality the contributor will have to test, and make sure that if the code under test is OK, the tests pass and in case of the tests failing to check whether it is their fault or a bug in the code under test (which they report).

As the software components we develop at OpenPrinting are an essential part of the operating system infrastructure, we want to have a solid CI testing of each commit to our GitHub repositories. CUPS (“cups” repository for 2.x) has already excellent CI done by Michael Sweet, consisting of GitHub actions/workflows which automatically apply static analysers, build and execution tests on different architectures and distros, This we want to have also in the other projects on OpenPrinting. **Note: As we have several repositories where we want to add improved CI testing, we can accept more than one contributor, each working on one of our repositories.**

Creating GitHub workflows and make them triggered with commits • Scripting to run analysers, build code, run test programs • C programming to write test programs

The contributor will study at first the CI done by Michael Sweet, especially in OpenPrinting’s CUPS repository but also in the repositories of Michael’s personal GitHub, especially PAPPL, PDFio, … Michael is an excellent example here. Then they will check the repository of the OpenPrinting project they are working on and implement the same functionality there. One part is to overtake and adapt the scripting, which is probably the smaller part, the other is to add extra tests to the “make check” run which will get executed after each build test. Each added test functionality the contributor will have to test, and make sure that if the code under test is OK, the tests pass and in case of the tests failing to check whether it is their fault or a bug in the code under test (which they report).

The go-avahi project provides Go bindings for the Avahi/mDNS/DNS-SD stack and is used for network service discovery functionality within the OpenPrinting ecosystem. It acts as a bridge between Go applications and the underlying Avahi daemon through D-Bus. Currently, go-avahi has no fuzz testing, limited test coverage, and several input-handling paths may fail in unexpected ways for malformed or adversarial input. For this project,, fuzzing is especially important to uncover crashes, panics, and edge cases. This project aims to develop a comprehensive fuzzing setup for go-avahi, improve test coverage, and integrate the project into the OSS-Fuzz ecosystem to enable continuous, long-term fuzz testing.

Identify suitable fuzzing targets in go-avahi • Write Go fuzz tests for identified functions • Add mocks if needed to test • Prepare build scripts and configuration for OSS-Fuzz • Validate that fuzzers run in the OSS-Fuzz environment • Submit a PR to OSS-Fuzz

The contributor will begin by reviewing how fuzzing is already set up in the OpenPrinting/fuzzing repository and how other OpenPrinting projects are integrated into OSS-Fuzz. The contributor will study the structure of go-avahi, select entry points that benefit from fuzzing, and add fuzz tests using Go’s built-in fuzzing engine. They will introduce mocks if required to make fuzzing reproducible. After fuzzers work locally, the contributor will create the necessary OSS-Fuzz files and submit an integration. Throughout the project, they will review crashes, minimize test cases, and collaborate with maintainers to address issues found by the fuzzers.

The go-avahi project provides Go bindings for the Avahi/mDNS/DNS-SD stack and is used for network service discovery functionality within the OpenPrinting ecosystem. It acts as a bridge between Go applications and the underlying Avahi daemon through D-Bus. Currently, go-avahi has no fuzz testing, limited test coverage, and several input-handling paths may fail in unexpected ways for malformed or adversarial input. For this project,, fuzzing is especially important to uncover crashes, panics, and edge cases. This project aims to develop a comprehensive fuzzing setup for go-avahi, improve test coverage, and integrate the project into the OSS-Fuzz ecosystem to enable continuous, long-term fuzz testing.

Identify suitable fuzzing targets in go-avahi • Write Go fuzz tests for identified functions • Add mocks if needed to test • Prepare build scripts and configuration for OSS-Fuzz • Validate that fuzzers run in the OSS-Fuzz environment • Submit a PR to OSS-Fuzz

The contributor will begin by reviewing how fuzzing is already set up in the OpenPrinting/fuzzing repository and how other OpenPrinting projects are integrated into OSS-Fuzz. The contributor will study the structure of go-avahi, select entry points that benefit from fuzzing, and add fuzz tests using Go’s built-in fuzzing engine. They will introduce mocks if required to make fuzzing reproducible. After fuzzers work locally, the contributor will create the necessary OSS-Fuzz files and submit an integration. Throughout the project, they will review crashes, minimize test cases, and collaborate with maintainers to address issues found by the fuzzers.

Currently, the go-mfp project, aimed to implement a full-featured behaviour-accurate MFP simulator together with collection of the MFP testing/validation/troubleshooting tools, lacks the support of WS-Scan protocol. We already have eSCL, partially implemented IPP, virtual USB MFP simulation (IPP over USB and legacy 7/1/1 USB printer), but WS-Scan support is not yet completed.

Complete full-featured, specification-based WS-Scan protocol implementation • Integrate this part with the whole project • Provide a good test coverage for the newly added code

WS-Scan protocol is technically and semantically similar to the eSCL protocol, which is already implemented. The contributor will study the existing eSCL implementation and create WS-Scan implementation, using the similar architectural approach. The ability to read and understand technical specifications is strongly required, because we need the high-quality, reference-class protocol implementation, strictly based on the protocol specification, published by Microsoft.

Currently, the go-mfp project, aimed to implement a full-featured behaviour-accurate MFP simulator together with collection of the MFP testing/validation/troubleshooting tools, lacks the support of WS-Scan protocol. We already have eSCL, partially implemented IPP, virtual USB MFP simulation (IPP over USB and legacy 7/1/1 USB printer), but WS-Scan support is not yet completed.

Complete full-featured, specification-based WS-Scan protocol implementation • Integrate this part with the whole project • Provide a good test coverage for the newly added code

WS-Scan protocol is technically and semantically similar to the eSCL protocol, which is already implemented. The contributor will study the existing eSCL implementation and create WS-Scan implementation, using the similar architectural approach. The ability to read and understand technical specifications is strongly required, because we need the high-quality, reference-class protocol implementation, strictly based on the protocol specification, published by Microsoft.

Currently, the go-mfp simulator already has very basic support of the legacy USB 7/1/1 printer emulation. However, it doesn’t somehow interpret the data sent to the emulated printer and doesn’t provide any response (as 7/1/2 devices should do). The project goal is to implement the Go [io.Reader](https://pkg.go.dev/io#Reader) (for 7/1/1 devices) and Go [io.ReadWriter](https://pkg.go.dev/io#ReadWriter) that consumes raw data bytes, sent to the emulated printer and able to properly identify document format being sent (i.e., PostScript, PDF, PCL5, ESC/P, …) and based on that identification properly detect the document or page boundaries (for example, PostScript and PDF documents are terminated by the Ctrl-D character, ESC/P and PCL5 may use end-of-page character etc). Having that implemented we can add saving documents to file for further analysis and troubleshooting and document rendering for printed image evaluation. Also, the bidirectional (USB 7/1/2) printers implement a simple PJL interpreter and generate proper responses, which also needs to be implemented in the [io.ReadWriter](https://pkg.go.dev/io#ReadWriter) interface with functionality enough to make CUPS happy.

Understanding the already implemented parts of the legacy printer simulation • Understanding the relevant documents formats in details enough to be able to perform the automatic format identification and to detect page or job boundaries • Understanding PJL in details enough to be able to process commands generated by CUPS and provide a proper responses

The contributor should study how the legacy printer works, how the graphical documents are sent to the printer and how the printer recognizes that document transmission is finished. The printed documents need to be extracted from the unstructured host to printer data flow and passed separately to the upper layer, which will decide what to do with these documents (just to save to the log file, to render etc). Rendering of printed documents is out of the scope of this project, so very detailed understanding of the relevant formats is not required. Also, for the implementation of the bidirectional (USB 7/1/2) printers the contributor needs to understand the behaviour expectations, based on specifications and CUPS implementation and to write a simple simulator. The representation of the emulated printer as a virtual USB device already done in the go-mfp and out of scope of this project. At this level the contributor needs only to implement the Go [io.Reader](https://pkg.go.dev/io#Reader) and [io.ReadWriter](https://pkg.go.dev/io#ReadWriter) interfaces that can properly consume the data sent to the printer and to generate the proper response, the task of transporting this data from/to the host is out of scope of this project (and already solved at the first glance). As result of this project, the code contribution into the go-mfp is expected, with the reasonable test coverage and integration with the “big project”.

Currently, the go-mfp simulator already has very basic support of the legacy USB 7/1/1 printer emulation. However, it doesn’t somehow interpret the data sent to the emulated printer and doesn’t provide any response (as 7/1/2 devices should do). The project goal is to implement the Go [io.Reader](https://pkg.go.dev/io#Reader) (for 7/1/1 devices) and Go [io.ReadWriter](https://pkg.go.dev/io#ReadWriter) that consumes raw data bytes, sent to the emulated printer and able to properly identify document format being sent (i.e., PostScript, PDF, PCL5, ESC/P, …) and based on that identification properly detect the document or page boundaries (for example, PostScript and PDF documents are terminated by the Ctrl-D character, ESC/P and PCL5 may use end-of-page character etc). Having that implemented we can add saving documents to file for further analysis and troubleshooting and document rendering for printed image evaluation. Also, the bidirectional (USB 7/1/2) printers implement a simple PJL interpreter and generate proper responses, which also needs to be implemented in the [io.ReadWriter](https://pkg.go.dev/io#ReadWriter) interface with functionality enough to make CUPS happy.

Understanding the already implemented parts of the legacy printer simulation • Understanding the relevant documents formats in details enough to be able to perform the automatic format identification and to detect page or job boundaries • Understanding PJL in details enough to be able to process commands generated by CUPS and provide a proper responses

The contributor should study how the legacy printer works, how the graphical documents are sent to the printer and how the printer recognizes that document transmission is finished. The printed documents need to be extracted from the unstructured host to printer data flow and passed separately to the upper layer, which will decide what to do with these documents (just to save to the log file, to render etc). Rendering of printed documents is out of the scope of this project, so very detailed understanding of the relevant formats is not required. Also, for the implementation of the bidirectional (USB 7/1/2) printers the contributor needs to understand the behaviour expectations, based on specifications and CUPS implementation and to write a simple simulator. The representation of the emulated printer as a virtual USB device already done in the go-mfp and out of scope of this project. At this level the contributor needs only to implement the Go [io.Reader](https://pkg.go.dev/io#Reader) and [io.ReadWriter](https://pkg.go.dev/io#ReadWriter) interfaces that can properly consume the data sent to the printer and to generate the proper response, the task of transporting this data from/to the host is out of scope of this project (and already solved at the first glance). As result of this project, the code contribution into the go-mfp is expected, with the reasonable test coverage and integration with the “big project”.

libpdfrip is a PDF renderer in development, aiming to be the first fully open, permissively licensed PDF renderer built on top of PDFio and using Cairo as its backend. A key missing feature for real-world PDFs is **Form XObject** (/Subtype /Form) rendering. Form XObjects are reusable content blocks (logos, icons, repeated UI elements, stamps, etc.) that are referenced via the “Do” operator in content streams. Many production PDFs rely on forms to avoid duplicating vector content. Currently, libpdfrip does not support Form XObjects. This project aims to add **Form XObject rendering** support to libpdfrip, including lookup through the resource dictionary, proper graphics state handling, and recursive interpretation of form content streams, with a minimal test suite and demo tooling to validate the implementation.

Understand PDF Form XObjects in the PDF specification such as : /Subtype /Form, /BBox, /Matrix, /Resources, and content streams

The contributor will begin by setting up a local development environment for **libpdfrip**, building the library and any existing demo tools. After this, they should study the basic structure of PDF files: how pages, resources, XObjects, and content streams are organized, and how different elements are referenced and reused within a document. Next, the contributor should go through the **PDFio** documentation to understand how to access PDF metadata and structure using the library’s APIs. This includes learning how to locate pages, resource dictionaries, XObjects, and content streams through PDFio. With this foundation in place, the student can start with the implementation of the actual Form XObject rendering path: saving the current graphics state, applying the form’s transformation matrix, clipping based on /BBox, recursively interpreting the form’s content stream with the correct resource dictionary, and finally restoring the graphics state. They will ensure that the same form can be reused multiple times at different positions and scales, and add safeguards against infinite recursion when forms reference each other. This work can be submitted as a standalone module or contributed directly to the **libpdfrip** codebase. To validate the implementation, the contributor will have to create a small set of synthetic PDFs (manually or via a generator) that use Form XObjects for simple shapes and logos, and add C tests or a lightweight test harness that renders these PDFs with libpdfrip (for example, to PNG via Cairo) and checks for successful execution and basic correctness.

libpdfrip is a PDF renderer in development, aiming to be the first fully open, permissively licensed PDF renderer built on top of PDFio and using Cairo as its backend. A key missing feature for real-world PDFs is **Form XObject** (/Subtype /Form) rendering. Form XObjects are reusable content blocks (logos, icons, repeated UI elements, stamps, etc.) that are referenced via the “Do” operator in content streams. Many production PDFs rely on forms to avoid duplicating vector content. Currently, libpdfrip does not support Form XObjects. This project aims to add **Form XObject rendering** support to libpdfrip, including lookup through the resource dictionary, proper graphics state handling, and recursive interpretation of form content streams, with a minimal test suite and demo tooling to validate the implementation.

Understand PDF Form XObjects in the PDF specification such as : /Subtype /Form, /BBox, /Matrix, /Resources, and content streams

The contributor will begin by setting up a local development environment for **libpdfrip**, building the library and any existing demo tools. After this, they should study the basic structure of PDF files: how pages, resources, XObjects, and content streams are organized, and how different elements are referenced and reused within a document. Next, the contributor should go through the **PDFio** documentation to understand how to access PDF metadata and structure using the library’s APIs. This includes learning how to locate pages, resource dictionaries, XObjects, and content streams through PDFio. With this foundation in place, the student can start with the implementation of the actual Form XObject rendering path: saving the current graphics state, applying the form’s transformation matrix, clipping based on /BBox, recursively interpreting the form’s content stream with the correct resource dictionary, and finally restoring the graphics state. They will ensure that the same form can be reused multiple times at different positions and scales, and add safeguards against infinite recursion when forms reference each other. This work can be submitted as a standalone module or contributed directly to the **libpdfrip** codebase. To validate the implementation, the contributor will have to create a small set of synthetic PDFs (manually or via a generator) that use Form XObjects for simple shapes and logos, and add C tests or a lightweight test harness that renders these PDFs with libpdfrip (for example, to PNG via Cairo) and checks for successful execution and basic correctness.