From 2bfc2f4d2ddf2ca05a064832e63fc4580c4147ea Mon Sep 17 00:00:00 2001 From: Sam Shubham <68236217+sam-shubham@users.noreply.github.com> Date: Fri, 27 Feb 2026 17:42:59 +0530 Subject: [PATCH] Add GSoC 2022-2026 project pages, fix sidebar navigation, fix typos, add telegram contact and fix visblity of icons in dark mode --- _config.yml | 102 ++++++- _data/navigation.yml | 264 +++++++++++++----- ...-suitable-Printer-Applications-for-them.md | 21 ++ _gsoc2022/02-Scanning-support-in-PAPPL.md | 26 ++ _gsoc2022/03-Print-Dialogs.md | 31 ++ ...ive-Printer-Application-from-Gutenprint.md | 31 ++ ...sser-support-into-a-Printer-Application.md | 24 ++ _gsoc2022/06-cups-filters.md | 19 ++ _gsoc2022/07-cups-filters.md | 23 ++ _gsoc2022/08-cups-filters.md | 21 ++ ...utables-of-system-config-printer-into-C.md | 23 ++ ...y-attributes-to-libcupsfilters-and-CPDB.md | 21 ++ ...B-support-for-application-print-dialogs.md | 33 +++ _gsoc2023/03-Scanning-support-in-PAPPL.md | 29 ++ ...cups-browsed-into-a-Printer-Application.md | 25 ++ .../05-PAPPL-based-Printer-Applications.md | 42 +++ ...ive-Printer-Application-from-Gutenprint.md | 31 ++ ...ters-libpappl-retrofit-libppd-CPDB-etc-.md | 29 ++ _gsoc2023/08-GNOME-Control-Center.md | 21 ++ _gsoc2023/09-cups-filters.md | 21 ++ _gsoc2024/01-Desktop-integration.md | 35 +++ _gsoc2024/02-Desktop-Integration.md | 27 ++ _gsoc2024/03-Desktop-Integration.md | 25 ++ ...enPrinting-projects-in-OSS-Fuzz-testing.md | 44 +++ ...podman-of-CUPS-and-Printer-Applications.md | 28 ++ ...-manipulation-library-in-libcupsfilters.md | 25 ++ ...cups-browsed-into-a-Printer-Application.md | 31 ++ ...sser-support-into-a-Printer-Application.md | 24 ++ ...ograms-for-libpappl-retrofit-and-libppd.md | 29 ++ _gsoc2024/10-cups-filters.md | 21 ++ _gsoc2025/01-Qt-Print-Dialog.md | 19 ++ _gsoc2025/02-GTK-Print-Dialog.md | 19 ++ _gsoc2025/03-KDE-Print-Manager-vs-CUPS-3-x.md | 19 ++ ...the-new-pyCUPS-to-system-config-printer.md | 23 ++ ...nd-PDFio-to-be-a-PDF-renderer-displayer.md | 21 ++ ...-fuzz-testing-for-OpenPrinting-projects.md | 36 +++ ...-and-Python-based-OpenPrinting-projects.md | 30 ++ ...stem-Fuzz-Testing-of-Printing-Protocols.md | 26 ++ ...rity-Auditing-for-OpenPrinting-Projects.md | 21 ++ ...ulti-function-printers-printer-scanner-.md | 30 ++ ...or-testing-of-print-scan-job-processing.md | 27 ++ ...CUPS-and-Printer-Applications-to-Zephyr.md | 23 ++ _gsoc2025/13-Rust-bindings-for-libcups2-3.md | 15 + ...-Error-response-pop-up-support-for-CPDB.md | 23 ++ ...ograms-for-libpappl-retrofit-and-libppd.md | 27 ++ _gsoc2025/16-cups-filters.md | 19 ++ .../01-system-config-printer-vs-CUPS-3-x.md | 23 ++ _gsoc2026/02-COSMIC-Desktop.md | 29 ++ _gsoc2026/03-KDE-Print-Manager.md | 13 + ...Compatibility-and-Recommendation-Portal.md | 29 ++ ...Compatibility-and-Recommendation-Portal.md | 29 ++ ...ss-Generation-for-OpenPrinting-Projects.md | 44 +++ ...rsing-Features-in-OpenPrinting-Projects.md | 43 +++ _gsoc2026/08-Fuzz-Test-go-cpython.md | 27 ++ ...nd-PDFio-to-be-a-PDF-renderer-displayer.md | 13 + ...Porting-OpenPrinting-Software-to-Zephyr.md | 17 ++ ...ld-a-Full-Print-System-Testing-Pipeline.md | 36 +++ ...-of-the-IANA-IPP-Registrations-Database.md | 82 ++++++ ...aging-for-CUPS-and-Printer-Applications.md | 36 +++ ...ograms-for-libpappl-retrofit-and-libppd.md | 27 ++ _gsoc2026/15-cups-filters.md | 19 ++ _includes/nav_list | 2 +- _pages/gsoc.md | 18 +- _pages/gsoc2022.md | 59 ++++ _pages/gsoc2023.md | 59 ++++ _pages/gsoc2024.md | 59 ++++ _pages/gsoc2025.md | 59 ++++ _pages/gsoc2026.md | 59 ++++ _pages/projects.md | 2 +- ...02-13-OpenPrinting News - February 2022.md | 2 +- assets/css/custom.css | 23 +- 71 files changed, 2230 insertions(+), 83 deletions(-) create mode 100644 _gsoc2022/01-GUI-for-discovering-non-driverless-printers-and-finding-suitable-Printer-Applications-for-them.md create mode 100644 _gsoc2022/02-Scanning-support-in-PAPPL.md create mode 100644 _gsoc2022/03-Print-Dialogs.md create mode 100644 _gsoc2022/04-Make-a-native-Printer-Application-from-Gutenprint.md create mode 100644 _gsoc2022/05-Converting-Braille-embosser-support-into-a-Printer-Application.md create mode 100644 _gsoc2022/06-cups-filters.md create mode 100644 _gsoc2022/07-cups-filters.md create mode 100644 _gsoc2022/08-cups-filters.md create mode 100644 _gsoc2022/09-Turn-the-scp-dbus-service-methods-GetBestDrivers-and-MissingExecutables-of-system-config-printer-into-C.md create mode 100644 _gsoc2023/01-Adding-support-for-new-IPP-Everywhere-2-x-functionality-attributes-to-libcupsfilters-and-CPDB.md create mode 100644 _gsoc2023/02-CPDB-support-for-application-print-dialogs.md create mode 100644 _gsoc2023/03-Scanning-support-in-PAPPL.md create mode 100644 _gsoc2023/04-Turn-cups-browsed-into-a-Printer-Application.md create mode 100644 _gsoc2023/05-PAPPL-based-Printer-Applications.md create mode 100644 _gsoc2023/06-Make-a-native-Printer-Application-from-Gutenprint.md create mode 100644 _gsoc2023/07-CI-Testing-programs-for-libcupsfilters-libpappl-retrofit-libppd-CPDB-etc-.md create mode 100644 _gsoc2023/08-GNOME-Control-Center.md create mode 100644 _gsoc2023/09-cups-filters.md create mode 100644 _gsoc2024/01-Desktop-integration.md create mode 100644 _gsoc2024/02-Desktop-Integration.md create mode 100644 _gsoc2024/03-Desktop-Integration.md create mode 100644 _gsoc2024/04-Integrating-C-based-OpenPrinting-projects-in-OSS-Fuzz-testing.md create mode 100644 _gsoc2024/05-Official-OCI-containers-Docker-ROCKs-podman-of-CUPS-and-Printer-Applications.md create mode 100644 _gsoc2024/06-Replace-QPDF-by-PDFio-as-PDF-manipulation-library-in-libcupsfilters.md create mode 100644 _gsoc2024/07-Turn-cups-browsed-into-a-Printer-Application.md create mode 100644 _gsoc2024/08-Converting-Braille-embosser-support-into-a-Printer-Application.md create mode 100644 _gsoc2024/09-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md create mode 100644 _gsoc2024/10-cups-filters.md create mode 100644 _gsoc2025/01-Qt-Print-Dialog.md create mode 100644 _gsoc2025/02-GTK-Print-Dialog.md create mode 100644 _gsoc2025/03-KDE-Print-Manager-vs-CUPS-3-x.md create mode 100644 _gsoc2025/04-Port-pyCUPS-to-CUPS-3-x-API-apply-the-new-pyCUPS-to-system-config-printer.md create mode 100644 _gsoc2025/05-Extend-PDFio-to-be-a-PDF-renderer-displayer.md create mode 100644 _gsoc2025/06-Utilizing-OSS-Fuzz-Gen-to-improve-fuzz-testing-for-OpenPrinting-projects.md create mode 100644 _gsoc2025/07-Integrating-OSS-Fuzz-for-Go-based-and-Python-based-OpenPrinting-projects.md create mode 100644 _gsoc2025/08-System-Fuzz-Testing-of-Printing-Protocols.md create mode 100644 _gsoc2025/09-Security-Auditing-for-OpenPrinting-Projects.md create mode 100644 _gsoc2025/10-Behavior-accurate-simulation-of-multi-function-printers-printer-scanner-.md create mode 100644 _gsoc2025/11-Image-output-evaluation-for-testing-of-print-scan-job-processing.md create mode 100644 _gsoc2025/12-Port-CUPS-and-Printer-Applications-to-Zephyr.md create mode 100644 _gsoc2025/13-Rust-bindings-for-libcups2-3.md create mode 100644 _gsoc2025/14-Error-response-pop-up-support-for-CPDB.md create mode 100644 _gsoc2025/15-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md create mode 100644 _gsoc2025/16-cups-filters.md create mode 100644 _gsoc2026/01-system-config-printer-vs-CUPS-3-x.md create mode 100644 _gsoc2026/02-COSMIC-Desktop.md create mode 100644 _gsoc2026/03-KDE-Print-Manager.md create mode 100644 _gsoc2026/04-AI-Driven-Printer-Compatibility-and-Recommendation-Portal.md create mode 100644 _gsoc2026/05-AI-Driven-Printer-Compatibility-and-Recommendation-Portal.md create mode 100644 _gsoc2026/06-Automated-and-LLM-Assisted-Fuzz-Harness-Generation-for-OpenPrinting-Projects.md create mode 100644 _gsoc2026/07-System-Level-Fuzzing-for-Parsing-Features-in-OpenPrinting-Projects.md create mode 100644 _gsoc2026/08-Fuzz-Test-go-cpython.md create mode 100644 _gsoc2026/09-Extend-PDFio-to-be-a-PDF-renderer-displayer.md create mode 100644 _gsoc2026/10-Porting-OpenPrinting-Software-to-Zephyr.md create mode 100644 _gsoc2026/11-Build-a-Full-Print-System-Testing-Pipeline.md create mode 100644 _gsoc2026/12-Validation-of-the-IANA-IPP-Registrations-Database.md create mode 100644 _gsoc2026/13-Cloud-Native-Packaging-for-CUPS-and-Printer-Applications.md create mode 100644 _gsoc2026/14-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md create mode 100644 _gsoc2026/15-cups-filters.md create mode 100644 _pages/gsoc2022.md create mode 100644 _pages/gsoc2023.md create mode 100644 _pages/gsoc2024.md create mode 100644 _pages/gsoc2025.md create mode 100644 _pages/gsoc2026.md diff --git a/_config.yml b/_config.yml index 8240a6e4..d0ab9370 100644 --- a/_config.yml +++ b/_config.yml @@ -113,9 +113,9 @@ author: - label: "Mastodon" icon: "fab fa-fw fa-mastodon" url: "https://ubuntu.social/tags/OpenPrinting" - - label: "LinkedIn" - icon: "fab fa-fw fa-linkedin" - url: "https://www.linkedin.com/company/openprinting/posts/" + - label: "Telegram" + icon: "fab fa-fw fa-telegram" + url: "https://t.me/+RizBbjXz4uU2ZWM1" # Site Footer footer: @@ -129,9 +129,9 @@ footer: - label: "LinkedIn" icon: "fab fa-fw fa-linkedin" url: "https://www.linkedin.com/company/openprinting/posts/" - - label: "Code of Conduct" - icon: "fas fa-file-contract" - url: "/codeofconduct/" + - label: "Telegram" + icon: "fab fa-fw fa-telegram" + url: "https://t.me/+RizBbjXz4uU2ZWM1" # Reading Files include: @@ -251,6 +251,21 @@ collections: documentation: output: true permalink: /:collection/:path/ + gsoc2022: + output: true + permalink: /:collection/:path/ + gsoc2023: + output: true + permalink: /:collection/:path/ + gsoc2024: + output: true + permalink: /:collection/:path/ + gsoc2025: + output: true + permalink: /:collection/:path/ + gsoc2026: + output: true + permalink: /:collection/:path/ # Defaults @@ -357,6 +372,81 @@ defaults: nav: "gsod20" # comments: true + + # _gsoc2022 + - scope: + path: "" + type: gsoc2022 + values: + layout: single + author_profile: false + share: false + excerpt: "" + toc: true + toc_label: "On This Page" + sidebar: + nav: "gsoc22" + # comments: true + + # _gsoc2023 + - scope: + path: "" + type: gsoc2023 + values: + layout: single + author_profile: false + share: false + excerpt: "" + toc: true + toc_label: "On This Page" + sidebar: + nav: "gsoc23" + # comments: true + + # _gsoc2024 + - scope: + path: "" + type: gsoc2024 + values: + layout: single + author_profile: false + share: false + excerpt: "" + toc: true + toc_label: "On This Page" + sidebar: + nav: "gsoc24" + # comments: true + + # _gsoc2025 + - scope: + path: "" + type: gsoc2025 + values: + layout: single + author_profile: false + share: false + excerpt: "" + toc: true + toc_label: "On This Page" + sidebar: + nav: "gsoc25" + # comments: true + + # _gsoc2026 + - scope: + path: "" + type: gsoc2026 + values: + layout: single + author_profile: false + share: false + excerpt: "" + toc: true + toc_label: "On This Page" + sidebar: + nav: "gsoc26" + # comments: true #_driverless - scope: path: "" diff --git a/_data/navigation.yml b/_data/navigation.yml index 77ae3f00..6ae275c8 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -12,7 +12,7 @@ # See the License for the specific language governing permissions and # limitations under the License. -# main links links +# main links main: - title: "About Us" url: /about-us/ @@ -33,39 +33,191 @@ main: - title: "Printer Drivers" url: "https://openprinting.org/drivers" - title: "Legacy Printers under Windows" - url: "/wsl-printer-app" + url: /wsl-printer-app/ - title: "Contact Us" url: /contact/ - title: "Donations" url: /donations/ +# ===================== +# GSoC Sidebar Navs +# ===================== + +gsoc26: + - title: "GSoC 2026" + children: + - title: "GSoC 2026 Homepage" + url: /gsoc2026/ + - title: "system-config-printer vs. CUPS 3.x" + url: /gsoc2026/01-system-config-printer-vs-CUPS-3-x/ + - title: "COSMIC Desktop: Printer setup tool and print dialog" + url: /gsoc2026/02-COSMIC-Desktop/ + - title: "KDE Print Manager: Completing CUPS 3.x support and Printer Application integration" + url: /gsoc2026/03-KDE-Print-Manager/ + - title: "AI-Driven Printer Compatibility and Recommendation Portal: Printer Data Intelligence & ML Pipeline" + url: /gsoc2026/04-AI-Driven-Printer-Compatibility-and-Recommendation-Portal/ + - title: "AI-Driven Printer Compatibility and Recommendation Portal: Intelligent Printer Discovery & Recommendation Web Interface" + url: /gsoc2026/05-AI-Driven-Printer-Compatibility-and-Recommendation-Portal/ + - title: "Automated and LLM-Assisted Fuzz Harness Generation for OpenPrinting Projects" + url: /gsoc2026/06-Automated-and-LLM-Assisted-Fuzz-Harness-Generation-for-OpenPrinting-Projects/ + - title: "System-Level Fuzzing for Parsing Features in OpenPrinting Projects" + url: /gsoc2026/07-System-Level-Fuzzing-for-Parsing-Features-in-OpenPrinting-Projects/ + - title: "Fuzz/Test go-cpython" + url: /gsoc2026/08-Fuzz-Test-go-cpython/ + - title: "Extend PDFio to be a PDF renderer/displayer" + url: /gsoc2026/09-Extend-PDFio-to-be-a-PDF-renderer-displayer/ + - title: "Porting OpenPrinting Software to Zephyr" + url: /gsoc2026/10-Porting-OpenPrinting-Software-to-Zephyr/ + - title: "Build a Full Print System Testing Pipeline" + url: /gsoc2026/11-Build-a-Full-Print-System-Testing-Pipeline/ + - title: "Validation of the IANA IPP Registrations Database" + url: /gsoc2026/12-Validation-of-the-IANA-IPP-Registrations-Database/ + - title: "Cloud-Native Packaging for CUPS and Printer Applications" + url: /gsoc2026/13-Cloud-Native-Packaging-for-CUPS-and-Printer-Applications/ + - title: "CI Testing programs for libpappl-retrofit and libppd" + url: /gsoc2026/14-CI-Testing-programs-for-libpappl-retrofit-and-libppd/ + - title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" + url: /gsoc2026/15-cups-filters/ + +gsoc25: + - title: "GSoC 2025" + children: + - title: "GSoC 2025 Homepage" + url: /gsoc2025/ + - title: "Qt Print Dialog: Modernize the user interface" + url: /gsoc2025/01-Qt-Print-Dialog/ + - title: "GTK Print Dialog: Modern dialog with built-in preview in main view" + url: /gsoc2025/02-GTK-Print-Dialog/ + - title: "KDE Print Manager vs. CUPS 3.x" + url: /gsoc2025/03-KDE-Print-Manager-vs-CUPS-3-x/ + - title: "Port pyCUPS to CUPS 3.x API + apply the new pyCUPS to system-config-printer" + url: /gsoc2025/04-Port-pyCUPS-to-CUPS-3-x-API-apply-the-new-pyCUPS-to-system-config-printer/ + - title: "Extend PDFio to be a PDF renderer/displayer" + url: /gsoc2025/05-Extend-PDFio-to-be-a-PDF-renderer-displayer/ + - title: "Utilizing OSS-Fuzz-Gen to improve fuzz testing for OpenPrinting projects" + url: /gsoc2025/06-Utilizing-OSS-Fuzz-Gen-to-improve-fuzz-testing-for-OpenPrinting-projects/ + - title: "Integrating OSS-Fuzz for Go-based and Python-based OpenPrinting projects" + url: /gsoc2025/07-Integrating-OSS-Fuzz-for-Go-based-and-Python-based-OpenPrinting-projects/ + - title: "System/Fuzz Testing of Printing Protocols" + url: /gsoc2025/08-System-Fuzz-Testing-of-Printing-Protocols/ + - title: "Security Auditing for OpenPrinting Projects" + url: /gsoc2025/09-Security-Auditing-for-OpenPrinting-Projects/ + - title: "Behavior-accurate simulation of multi-function printers (printer + scanner)" + url: /gsoc2025/10-Behavior-accurate-simulation-of-multi-function-printers-printer-scanner-/ + - title: "Image output evaluation for testing of print/scan job processing" + url: /gsoc2025/11-Image-output-evaluation-for-testing-of-print-scan-job-processing/ + - title: "Port CUPS and Printer Applications to Zephyr" + url: /gsoc2025/12-Port-CUPS-and-Printer-Applications-to-Zephyr/ + - title: "Rust bindings for libcups2/3" + url: /gsoc2025/13-Rust-bindings-for-libcups2-3/ + - title: "Error response pop-up support for CPDB" + url: /gsoc2025/14-Error-response-pop-up-support-for-CPDB/ + - title: "CI Testing programs for libpappl-retrofit and libppd" + url: /gsoc2025/15-CI-Testing-programs-for-libpappl-retrofit-and-libppd/ + - title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" + url: /gsoc2025/16-cups-filters/ + +gsoc24: + - title: "GSoC 2024" + children: + - title: "GSoC 2024 Homepage" + url: /gsoc2024/ + - title: "Desktop integration: CPDB support for print dialogs of Mozilla (Thunderbird/Firefox) and LibreOffice" + url: /gsoc2024/01-Desktop-integration/ + - title: "Desktop Integration: Update system-config-printer for the New Architecture of printing" + url: /gsoc2024/02-Desktop-Integration/ + - title: "Desktop Integration: User interfaces for using OAuth2 with printers and scanners" + url: /gsoc2024/03-Desktop-Integration/ + - title: "Integrating C-based OpenPrinting projects in OSS-Fuzz testing" + url: /gsoc2024/04-Integrating-C-based-OpenPrinting-projects-in-OSS-Fuzz-testing/ + - title: "Official OCI containers of CUPS and Printer Applications" + url: /gsoc2024/05-Official-OCI-containers-Docker-ROCKs-podman-of-CUPS-and-Printer-Applications/ + - title: "Replace QPDF by PDFio as PDF manipulation library in libcupsfilters" + url: /gsoc2024/06-Replace-QPDF-by-PDFio-as-PDF-manipulation-library-in-libcupsfilters/ + - title: "Turn cups-browsed into a Printer Application" + url: /gsoc2024/07-Turn-cups-browsed-into-a-Printer-Application/ + - title: "Converting Braille embosser support into a Printer Application" + url: /gsoc2024/08-Converting-Braille-embosser-support-into-a-Printer-Application/ + - title: "CI Testing programs for libpappl-retrofit and libppd" + url: /gsoc2024/09-CI-Testing-programs-for-libpappl-retrofit-and-libppd/ + - title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" + url: /gsoc2024/10-cups-filters/ + +gsoc23: + - title: "GSoC 2023" + children: + - title: "GSoC 2023 Homepage" + url: /gsoc2023/ + - title: "Adding support for new IPP Everywhere 2.x functionality/attributes to libcupsfilters and CPDB" + url: /gsoc2023/01-Adding-support-for-new-IPP-Everywhere-2-x-functionality-attributes-to-libcupsfilters-and-CPDB/ + - title: "CPDB support for application print dialogs: Firefox, Chromium, LibreOffice, etc." + url: /gsoc2023/02-CPDB-support-for-application-print-dialogs/ + - title: "Scanning support in PAPPL" + url: /gsoc2023/03-Scanning-support-in-PAPPL/ + - title: "Turn cups-browsed into a Printer Application" + url: /gsoc2023/04-Turn-cups-browsed-into-a-Printer-Application/ + - title: "PAPPL-based Printer Applications: Option setting presets via web interface" + url: /gsoc2023/05-PAPPL-based-Printer-Applications/ + - title: "Make a native Printer Application from Gutenprint" + url: /gsoc2023/06-Make-a-native-Printer-Application-from-Gutenprint/ + - title: "CI Testing programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, etc." + url: /gsoc2023/07-CI-Testing-programs-for-libcupsfilters-libpappl-retrofit-libppd-CPDB-etc-/ + - title: "GNOME Control Center: List and handle IPP print services for the New Architecture" + url: /gsoc2023/08-GNOME-Control-Center/ + - title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" + url: /gsoc2023/09-cups-filters/ + +gsoc22: + - title: "GSoC 2022" + children: + - title: "GSoC 2022 Homepage" + url: /gsoc2022/ + - title: "GUI for discovering non-driverless printers and finding suitable Printer Applications for them" + url: /gsoc2022/01-GUI-for-discovering-non-driverless-printers-and-finding-suitable-Printer-Applications-for-them/ + - title: "Scanning support in PAPPL" + url: /gsoc2022/02-Scanning-support-in-PAPPL/ + - title: "Print Dialogs: Make them use the Common Print Dialog Backends (CPDB)" + url: /gsoc2022/03-Print-Dialogs/ + - title: "Make a native Printer Application from Gutenprint" + url: /gsoc2022/04-Make-a-native-Printer-Application-from-Gutenprint/ + - title: "Converting Braille embosser support into a Printer Application" + url: /gsoc2022/05-Converting-Braille-embosser-support-into-a-Printer-Application/ + - title: "cups-filters: In filter functions call Ghostscript via libgs and not as external executable" + url: /gsoc2022/06-cups-filters/ + - title: "cups-filters: Add Avahi calls for discovering and resolving driverless IPP printers to API" + url: /gsoc2022/07-cups-filters/ + - title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" + url: /gsoc2022/08-cups-filters/ + - title: "Turn the scp-dbus-service methods GetBestDrivers and MissingExecutables of system-config-printer into C" + url: /gsoc2022/09-Turn-the-scp-dbus-service-methods-GetBestDrivers-and-MissingExecutables-of-system-config-printer-into-C/ + gsoc21: - - title: "GSOC 2021" + - title: "GSoC 2021" children: - - title: "GSOC 2021 Homepage" + - title: "GSoC 2021 Homepage" url: /gsoc2021/ - - title: "Make All Filter Functions Work Well Even Without PPD Files." + - title: "Make All Filter Functions Work Well Even Without PPD Files" url: /gsoc2021/01-Filter_withour-PPD/ - title: "GUI for listing and managing available IPP services" - url: gsoc2021/02-GUI-for-IPP/ + url: /gsoc2021/02-GUI-for-IPP/ - title: "Firmware and other file handling in PAPPL" - url: gsoc2021/03-File-Handling-in-PAPPL/ + url: /gsoc2021/03-File-Handling-in-PAPPL/ - title: "Create a single universal CUPS filter to replace the chain of individual filters" url: /gsoc2021/04-Single-universal-filter/ - title: "CUPS Filters: Converting Filters to Filter Functions" - url: /gsoc2021/05-Filters-to-Filter// + url: /gsoc2021/05-Filters-to-Filter/ gsoc20: - - title: "GSOC 2020" + - title: "GSoC 2020" children: - - title: "GSOC 2020 Homepage" + - title: "GSoC 2020 Homepage" url: /gsoc2020/ - - title: "Linux GUI application (can be part of GNOME printer tool) to admin MF devices using IPP System Service." + - title: "Linux GUI application to admin MF devices using IPP System Service" url: /gsoc2020/01-Linux-GUI-Application/ - title: "Common Print Dialog Qt implementation" - url: gsoc2020/02-common-print-dialog/ + url: /gsoc2020/02-common-print-dialog/ - title: "IPP scan (or virtual MF device) server (Scanner Application)" - url: gsoc2020/03-ipp-scan-application/ + url: /gsoc2020/03-ipp-scan-application/ - title: "SANE module for IPP driverless scanning" url: /gsoc2020/04-sane-module/ - title: "General Printer SDK" @@ -82,7 +234,7 @@ gsoc20: url: /gsoc2020/10-gutenprint-printer-application/ - title: "Support for IPP Fax Out" url: /gsoc2020/11-ipp-fax-out/ - - title: "Turn the scp-dbus-service methods - GetBestDrivers and MissingExecutables - of system-config-printer into C" + - title: "Turn the scp-dbus-service methods of system-config-printer into C" url: /gsoc2020/12-scp-dbus-service-into-c/ - title: "Extract Raster data from PDFs for direct printing" url: /gsoc2020/13-extract-raster-from-pdf/ @@ -96,11 +248,11 @@ gsoc20: url: /gsoc2020/17-get-cairo-code-upstream/ gsoc19: - - title: "GSOC 2019" + - title: "GSoC 2019" children: - - title: "GSOC 2019 HomePage" + - title: "GSoC 2019 Homepage" url: /gsoc2019/ - - title: "Generic Framework to turn legacy drivers consisting of CUPS filters and PPDs into Printer Applications" + - title: "Generic Framework to turn legacy drivers into Printer Applications" url: /gsoc2019/01-legacy-drivers-to-printer-applications/ - title: "IPP scan (or virtual MF device) server (Scanner Application)" url: /gsoc2019/02-ipp-scan-server/ @@ -110,11 +262,11 @@ gsoc19: url: /gsoc2019/04-ipp-test-tool-for-ipp-system-service/ - title: "IPP - ipptool test suite for IPP Errata Updates" url: /gsoc2019/05-ipp-test-tool-for-ipp-errata-updates/ - - title: "Linux GUI application (can be part of GNOME printer tool) to admin MF devices using IPP System Service." + - title: "Linux GUI application to admin MF devices using IPP System Service" url: /gsoc2019/06-linux-gui-application/ - - title: "Improve the pdftoraster filter to not need copying Poppler source code or using unstable APIs" + - title: "Improve the pdftoraster filter" url: /gsoc2019/07-pdftoraster-filter/ - - title: "Foomatic Generating CUPS PPD generator (/usr/share/cups/drv/*.drv files) from Foomatic data" + - title: "Foomatic Generating CUPS PPD generator from Foomatic data" url: /gsoc2019/08-foomatic-generating-cups-ppd-generator/ - title: "Add printer output backends to MuPDF" url: /gsoc2019/09-add-printer-output-backends-to-mupdf/ @@ -129,6 +281,34 @@ gsoc19: - title: "Get the cairo color management code upstream" url: /gsoc2019/14-cairo-color-management-code/ +# ===================== +# Other Program Sidebar Navs +# ===================== + +lfmp20: + - title: "LFMP 2020" + children: + - title: "LFMP 2020 Homepage" + url: /lfmp2020/ + - title: "Wrapping proprietary printer drivers into a Printer Application" + url: /lfmp2020/01-Wrapping-proprietary-printer-drivers-into-a-Printer-Application/ + - title: "Support for IPP Fax Out" + url: /lfmp2020/02-Support-IPP-Fax-Out/ + - title: "IPP scan (or virtual MF device) server (Scanner Application)" + url: /lfmp2020/03-ipp-scan-application/ + +gsod20: + - title: "GSoD 2020" + children: + - title: "GSoD 2020 Homepage" + url: /gsod2020/ + - title: "Tutorial and Design Guidelines for Printer/Scanner drivers in Printer Applications" + url: /gsod2020/01-Tutorial-Printer-Applications/ + +# ===================== +# Driverless Sidebar Nav +# ===================== + driverless: - title: "Driverless Printing" children: @@ -138,47 +318,3 @@ driverless: url: /driverless/01-standards-and-their-pdls/ - title: "Workflow of Driverless Printing" url: /driverless/02-workflow/ -# sidebar navigation list sample -# sidebar-sample: -# - title: "Parent Page A" -# children: -# - title: "Child Page A1" -# url: /child-page-a1/ -# - title: "Child Page A2" -# url: /child-page-a2/ -# - title: "Child Page A3" -# url: /child-page-a3/ -# - title: "Child Page A4" -# url: /child-page-a4/ -# - title: "Parent Page B" -# children: -# - title: "Child Page B1" -# url: /child-page-b1/ -# - title: "Child Page B2" -# url: /child-page-b2/ -# - title: "Child Page B3" -# url: /child-page-b3/ -# - title: "Child Page B4" -# url: /child-page-b4/ -# - title: "Child Page B5" -# url: /child-page-b5/ -# - title: "Parent Page C" -# children: -# - title: "Child Page C1" -# url: /child-page-c1/ -# - title: "Child Page C2" -# url: /child-page-c2/ -# - title: "Child Page C3" -# url: /child-page-c3/ -# - title: "Child Page C4" -# url: /child-page-c4/ -# - title: "Child Page C5" -# url: /child-page-c5/ -# - title: "Parent Page D" -# children: -# - title: "Child Page D1" -# url: /child-page-d1/ -# - title: "Child Page D2" -# url: /child-page-d2/ -# - title: "Child Page D3 (External)" -# url: https://your-domain.com diff --git a/_gsoc2022/01-GUI-for-discovering-non-driverless-printers-and-finding-suitable-Printer-Applications-for-them.md b/_gsoc2022/01-GUI-for-discovering-non-driverless-printers-and-finding-suitable-Printer-Applications-for-them.md new file mode 100644 index 00000000..b76720a3 --- /dev/null +++ b/_gsoc2022/01-GUI-for-discovering-non-driverless-printers-and-finding-suitable-Printer-Applications-for-them.md @@ -0,0 +1,21 @@ +--- +title: "GUI for discovering non-driverless printers and finding suitable Printer Applications for them" +--- + +### Introduction + +1 contributor full-size (350 hours). + +Modern printers usually are driverless IPP printers, and those get discovered and set up fully automatically with CUPS, no Printer Application is required for them, so it is easy for users to get up and running with them. + +Printers which do not do driverless IPP are either legacy printers, the many older printers which got developed before driverless IPP printing existed, and specialty printers. These need Printer Applications. As there will be several different Printer Applications and each one supporting another set of printers it is not trivial for the user to discover available non-IPP-driverless printers and find out which is the Printer Application to use and whether it is already installed. + +So we need some guide for the user. The idea is a GUI tool which lists available, non-IPP-driverless printers, local (USB) and network devices. If the user selects one of them, all installed Printer Applications which support this printer are shown, and for each a button to open the Printer Application's web interface and also a quick auto-add-this-printer button. In addition to the list of suitable Printer Applications there should also be a button which does a fuzzy search for the printer make and model on the Snap Store/the OpenPrinting web site to find Printer Applications which are not installed on the local system. There is already a concept to implement an appropriate [search index on OpenPrinting](https://openprinting.github.io/OpenPrinting-News-November-2021/#printer-querying-on-the-openprinting-web-server) which will be used by this GUI. + +The contributor's task is to implement such a tool in GTK, ideally as a module for the GNOME Control Center. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), GNOME/GTK developers, TBD +### Desired knowledge + `C/C++`, GTK, DNS-SD/Avahi, CUPS/IPP +### Code License + GPL-2+ and LGPL-2+ diff --git a/_gsoc2022/02-Scanning-support-in-PAPPL.md b/_gsoc2022/02-Scanning-support-in-PAPPL.md new file mode 100644 index 00000000..df8d2db6 --- /dev/null +++ b/_gsoc2022/02-Scanning-support-in-PAPPL.md @@ -0,0 +1,26 @@ +--- +title: "Scanning support in PAPPL" +--- + +### Introduction + +1 contributor full-size (350 hours). + +In the Google Summer of Code 2021, Bhavna Kosta has started the work on [Scanning support in PAPPL](https://github.com/Bhavna2020/GSoC-2021) so that [PAPPL](https://github.com/michaelrsweet/pappl/) not only can be used for creating Printer Applications (emulation of a driverless IPP printer) but also for creating Scanner Applications (emulation of a driverless IPP/eSCL scanner), or even an emulation of a driverless IPP multi-function device. + +She has created the [needed data structures and API functions](https://github.com/michaelrsweet/pappl/tree/scanning) needed to extend PAPPL for supporting scanners. + +Next steps to complete the support are the following: + + * IPP Scan interface: Extend the IPP server of PAPPL to understand IPP Scan requests and respond to them appropriately, so that the application emulates an IPP Scan device + * eSCL Scan interface: Add an eSCL interface to make the application emulate an eSCL scanner. eSCL is the most common communication protocol for driverless scanning, also used by AirPrint ([Code example](https://github.com/SimulPiscator/AirSane)) + * Create a test scanner driver emulating a scanner withour needing actual scanner hardware + * Unit tests for both IPP Scan and eSCL interfaces + +The contributor's task to implement the above-mentioned components to complete the framework needed by all Scanner Application. With this done, only code for the particular group of scanners to support (scanner driver) needs to be added to PAPPL. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Jai Luthra (luthrajaiji at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), Alexander Pevzner (pzz at apevzner dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2022/03-Print-Dialogs.md b/_gsoc2022/03-Print-Dialogs.md new file mode 100644 index 00000000..3680009f --- /dev/null +++ b/_gsoc2022/03-Print-Dialogs.md @@ -0,0 +1,31 @@ +--- +title: "Print Dialogs: Make them use the Common Print Dialog Backends (CPDB)" +--- + +### Introduction + +1 contributors full-size (350 hours). + +Most print jobs are sent via the print dialog of a desktop application, like evince, Chrome, LibreOffice, DarkTable, … Print dialogs are usually, like “Open …” or “Save as …” dialogs, provided by the GUI toolkits, in most cases GTK or Qt, sometimes applications come also with their own creations, like LibreOffice or Chrome. + +Problem here is usually not the design of the dialog itself, most are actually easy to use, but the way how they connect to CUPS (and also to other print technologies) and how well this connection code is maintained and kept up-to-date. + +GUI toolkit projects are large projects, often with long release cycles and all with a certain inertia, and there are things which many people are eager to work on, and others, like print dialogs, which have to be there but no one is really motivated to push their development forward and do the needed maintenance work. + +An important part of the maintenance of a GUI toolkit is that it interfaces well and correctly with the underlying operating system, graphics, sound, storage, …, and printing! The OS is under continuous development, things are changing all the time, components get replaced by others, printing is CUPS for 22 years, but within CUPS we have also changes, and they need to be taken care of in the print dialogs. + +Several years back, CUPS started to create temporary queues for driverless IPP network printers (or remote CUPS printers, which are emulations of IPP printers), which are only physically available when they are accessed (capabilities are polled or job printed). Print dialogs used an old API which did not support this, the temporary queues did not appear in the dialog, a helper daemon, cups-browsed had to convert the temporary queues into physical queues as a workaround. The correct solution had been to change the print dialogs to a newer CUPS API which supports these queues, but no one at the GUI toolkit projects has felt responsible and taken the time for this update for many years. Only recently this got fixed. + +This made me introducing the Common Print Dialog Backends (CPDB) back in 2017, a de-coupling of the print technology (CUPS, print-to-file, that time also Google Cloud Print) from the GUI. The GUI projects have to adopt the CPDB support only once and then OpenPrinting (or any upcoming cloud printing projects) takes care of the CPDB backend for the print technologies to be up-to-date with any changes. This way print technology projects can react quickly and are not dependent any more on the GUI toolkit’s inertia. + +As far as I know the GTK, Qt, and LibreOffice print dialogs support temporary print queues now (but only recently, there are many old dialog versions around), but now we are at the next challenge as we have to assure that the print dialogs use CUPS APIs which do not handle PPDs on the dialog side, so that if the system switched to PPD-less CUPS 3.x that the dialog continues to work. If we get the dialogs using CPDB, these changes happen (if actually needed) only in the CUPS CPDB backend, not in each print dialog individually. + +The contributor's task is to get CPDB into the print dialogs upstream, the UI of them does not need to be changed. Dialogs to be treated are GTK, Qt, (LibreOffice has already CPDB support AFAIR), Chrome, and perhaps others. Also important are backports, as there are many apps based on old toolkit versions around in the distributions (Firefox? Thunderbird?). + +For the CPDB integration we do not need UI design work. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), GNOME/GTK developers, Qt developers, TBD +### Desired knowledge + `C/C++`, GTK or Qt, DNS-SD/Avahi, CUPS/IPP +### Code License + GPL-2+ and LGPL-2+, Apache 2.0 diff --git a/_gsoc2022/04-Make-a-native-Printer-Application-from-Gutenprint.md b/_gsoc2022/04-Make-a-native-Printer-Application-from-Gutenprint.md new file mode 100644 index 00000000..c6bc3455 --- /dev/null +++ b/_gsoc2022/04-Make-a-native-Printer-Application-from-Gutenprint.md @@ -0,0 +1,31 @@ +--- +title: "Make a native Printer Application from Gutenprint" +--- + +### Introduction + +1 contributor full-size (350 hours). + +[Gutenprint](http://gimp-print.sourceforge.net/) is a high-quality printer driver for a wide range of inkjets, especially Epson and Canon, dye-sublimation printers and even monochrome PCL laser printers. It does not only cover many printers to give them support under Linux and free software operating systems at all, but also is optimized for highest possible print quality, so that at least on some printers and with the right settings you can even get better print quality than with the original (Windows/Mac) drivers. + +Gutenprint is usually used as classic CUPS driver with a CUPS filter and a PPD file generator. As, as mentioned above, CUPS will not support PPD files any more from version 3.x on and when using the CUPS Snap one cannot install PPD-based drivers already now. + +So a Printer Application of Gutenprint is needed. There [is already one](https://github.com/OpenPrinting/gutenprint-printer-app/), but it is a retro-fit of the classic CUPS driver. The Printer Application simply calls the PPD generator and the filter at the right places to do its job. + +As Gutenprint contains all its printer support and printer capability info in libgutenprint or in files which are read by libgutenprint, the PPD generator and the filter only containing calls of functions in libgutenprint, it should be easy to create a [PAPPL-based](https://github.com/michaelrsweet/pappl/), native Printer Application for Gutenprint. + +Here on an incoming get-printer-attributes IPP request we call the same functions which the PPD generator calls, but instead of translating the responses into a PPD file we translate it into the IPP answer for the get-printer-attributes request. And when we have a job to print, we call the library functions which the filter calls, but directly. + +This does not only save us from resource-consuming calls of external executables but we are also no harnessed by the PPD file syntax and so have more flexibility in the UI representations of the (often more than 100) printer-specific options. Also, generally we should completely do away with the PPDs. Retro-fitting is only an ugly interim solution or for drivers which are not actively maintained anymore and for printers we do not have at hand and so cannot test the drivers. + +The contributor's task is thus: + + * Create a PAPPL-based Printer Application using the libgutenprint library and PAPPL + * Make sure all options and parameters of the Gutenprint driver are accessible from the Printer Application's web admin interface. + * Package the Printer Application as a Snap +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gutenprint developers TBD +### Desired knowledge + `C`, PAPPL, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2022/05-Converting-Braille-embosser-support-into-a-Printer-Application.md b/_gsoc2022/05-Converting-Braille-embosser-support-into-a-Printer-Application.md new file mode 100644 index 00000000..724a0ce3 --- /dev/null +++ b/_gsoc2022/05-Converting-Braille-embosser-support-into-a-Printer-Application.md @@ -0,0 +1,24 @@ +--- +title: "Converting Braille embosser support into a Printer Application" +--- + +### Introduction + +1 contributor full-size (350 hours). + +cups-filters currently supports Braille embossers through a series of PPD files and shell scripts that convert documents into a textual layout, convert the text into Braille dots, and convert the Braille dots to braille embosser-specific formats. + +For long-term support and wide availability, this needs to be converted to the newer CUPS infrastructure, Printer Applications. + +The contributor's task is thus: + + * Converting these shell scripts into filter functions in libcupsfilters + * Creating a Printer Application that exposes Braille embossers configuration to users + +The contributor does not need to own any specific hardware, a comparison can be made between the output of the existing shell-script-based implementation and the output of the converted implementation. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Samuel Thibault, Braille expert (samuel dot thibault at ens-lyon dot org) +### Desired knowledge + `C/C++`, Shell, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2022/06-cups-filters.md b/_gsoc2022/06-cups-filters.md new file mode 100644 index 00000000..8cb12680 --- /dev/null +++ b/_gsoc2022/06-cups-filters.md @@ -0,0 +1,19 @@ +--- +title: "cups-filters: In filter functions call Ghostscript via libgs and not as external executable" +--- + +### Introduction + +1 contributor half-size (175 hrs) + +cups-filters has always provided the filters which CUPS needs to convert job data from the input format (PDF in most cases) into the printer's native language. For use in Printer Applications the filters got converted from standalone executables to library functions, reducing the number of calls of separate executables and so saving resources. + +The filter functions themselves also often call external executables, and this we can also try to avoid. For example the ghostscript() filter function calls Ghostscript and Ghostscript also has a library, libgs, which allows Ghostscript to be called as library function. + +The contributor's task here is to convert the ghostscript() filter function to call Ghostscript via libgs. Here it is also important to make everything working in a multi-threading environment as Printer Applications can process jobs in parallel. Ghostscript has a special GS_THREADSAFE build mode for that. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2022/07-cups-filters.md b/_gsoc2022/07-cups-filters.md new file mode 100644 index 00000000..d92e6abc --- /dev/null +++ b/_gsoc2022/07-cups-filters.md @@ -0,0 +1,23 @@ +--- +title: "cups-filters: Add Avahi calls for discovering and resolving driverless IPP printers to API and optimize the processes" +--- + +### Introduction + +1 contributor half-size (175 hrs) + +The cups-browsed daemon and the "driverless" utility discover DNS-SD-advertised IPP printers in the network, for the former to automatically create queues and the latter to list the printers for printer setup tools and auto-generate PPD files for them. + +DNS-SD/Avahi discovery goes in two steps: First there is the service discovery itself which is very fast, then each discovered service needs to get resolved to get the complete DNS-SD record, this is a rather slow process. A complete DNS-SD discovery run (only on IPP-relevant service types) including resolving all discovered services can take a long time, especially in large networks. + +cups-browsed resolves each service which gets discovered, and many of them are duplicate, for example IPP and IPPS, IPv4 and IPv6, and several different network interfaces, as Ethernet, Wi-Fi, and imterfaces for virtual machines. Here one could sort and filter before resolving, for example start resolving only if the discovery run has completed, then resolve only the needed ones. + +The "driverless" utility calls "ippfind" to do the DNS-SD discovery and resolving, here further optimization would be possible if the utility directly deals with Avahi and then saves unneeded resolving steps. + +The contributor's task is here to add a convenience API for Avahi discovery and resolving calls to libcupsfilters. For example create library functions avahiResolveService(), avahiBrowseResolve(), avahiBrowseOnly() in new files cupsfilters/avahi.[ch], using code of cups/http-support.c and tools/ippfind.c from CUPS. In a next step these functions should be used in cups-browsed and in the "driverless" utility to optimize their performance. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2022/08-cups-filters.md b/_gsoc2022/08-cups-filters.md new file mode 100644 index 00000000..6135ef9b --- /dev/null +++ b/_gsoc2022/08-cups-filters.md @@ -0,0 +1,21 @@ +--- +title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" +--- + +### Introduction + +1 contributor half-size (175 hrs) + +Scanning with IPP Scan gives the user the possibility to request the scanned image in PDF format. If the IPP Scan server is a Scanner Application, a filter function from cups-filters would convert the the raster image coming from the scanner into PDF. + +Now such PDF files are simply raster images in a PDF frame, not high-level graphics with text and fonts, as PDFs produced by office applications are. Especially one cannot search text in a PDF coming from a scanning process. + +Ghostscript has a new "pdfocr8" device with which Ghostscript takes raster graphics PDFs (or PostScript files) as input, applies OCR (Optical Character Recognition) to the raster image, and creates a PDF which contains the raster image to visually show the scan but adds data about the contained text and where it is located, so that you can find text with the search facility of a PDF viewer. + +Here the contributor's task is to write a filter function (or extend the ghostscript() filter function) to make the "pdfocr8" output device of Ghostscript being used so that a searchable PDF is obtained. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), Alexander Pevzner (pzz at apevzner dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2022/09-Turn-the-scp-dbus-service-methods-GetBestDrivers-and-MissingExecutables-of-system-config-printer-into-C.md b/_gsoc2022/09-Turn-the-scp-dbus-service-methods-GetBestDrivers-and-MissingExecutables-of-system-config-printer-into-C.md new file mode 100644 index 00000000..e0159937 --- /dev/null +++ b/_gsoc2022/09-Turn-the-scp-dbus-service-methods-GetBestDrivers-and-MissingExecutables-of-system-config-printer-into-C.md @@ -0,0 +1,23 @@ +--- +title: "Turn the scp-dbus-service methods GetBestDrivers and MissingExecutables of system-config-printer into C" +--- + +### Introduction + +1 contributor full-size (350 hrs) + +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 contributor'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/_gsoc2023/01-Adding-support-for-new-IPP-Everywhere-2-x-functionality-attributes-to-libcupsfilters-and-CPDB.md b/_gsoc2023/01-Adding-support-for-new-IPP-Everywhere-2-x-functionality-attributes-to-libcupsfilters-and-CPDB.md new file mode 100644 index 00000000..c404c96d --- /dev/null +++ b/_gsoc2023/01-Adding-support-for-new-IPP-Everywhere-2-x-functionality-attributes-to-libcupsfilters-and-CPDB.md @@ -0,0 +1,21 @@ +--- +title: "Adding support for new IPP Everywhere 2.x functionality/attributes to libcupsfilters and CPDB" +--- + +### Introduction + +1-2 contributors full-size (350 hours). + +Driverless IPP printing is implemented with four, very similar standards, IPP Everywhere, AirPrint, Mopria, and Wi-Fi Direct Print. Most [printers](https://openprinting.github.io/printers/) qualify to be driverless as the support [Apple's Airprint](https://support.apple.com/en-us/HT201311), the standard which got widely used first, to allow printing from iPhones and other iOS devices, but IPP Everywhere from the Printer Working Group is the first free and open standard. + +IPP Everywhere is under continuous development. The current version printers are certified on is 1.1, but 2.0 is close to its release. It adds new attributes to cover the most recent printers. + +The software provided on OpenPrinting is all based on IPP Everywhere 1.x and to make use of printer features covered by the new version of the standard it needs to get updated. + +The contributor's task is to add the new features according to the new specifications and to update everything to conform with [IPP Everywhere 2.0](https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve20-20221107.pdf), [IPP Driver Replacement Extensions v2.0](https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippnodriver20-20221027.pdf), and [IPP Job Extensions v2.1](https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobext21-20221212.pdf). Especially the libcupsfilters and CPDB must "understand" the new attributes and choices, libcupsfilters needs to implement the new attribute's functionality, and CPDB to carry through the new attributes to the print dialogs. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Ira McDonald (blueroofmusic at gmail dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2023/02-CPDB-support-for-application-print-dialogs.md b/_gsoc2023/02-CPDB-support-for-application-print-dialogs.md new file mode 100644 index 00000000..8a79a2bf --- /dev/null +++ b/_gsoc2023/02-CPDB-support-for-application-print-dialogs.md @@ -0,0 +1,33 @@ +--- +title: "CPDB support for application print dialogs: Firefox, Chromium, LibreOffice, etc." +--- + +### Introduction + +1 contributor full-size (350 hours). + +Most print jobs are sent via the print dialog of a desktop application, like evince, Chrome, LibreOffice, DarkTable, … Print dialogs are usually, like “Open …” or “Save as …” dialogs, provided by the GUI toolkits, in most cases GTK or Qt, sometimes applications come also with their own creations, like LibreOffice or Chromium. + +Problem here is usually not the design of the dialog itself, most are actually easy to use, but the way how they connect to CUPS (and also to other print technologies) and how well this connection code is maintained and kept up-to-date. + +GUI toolkit projects are large projects, often with long release cycles and all with a certain inertia, and there are things which many people are eager to work on, and others, like print dialogs, which have to be there but no one is really motivated to push their development forward and do the needed maintenance work. + +An important part of the maintenance of a GUI toolkit is that it interfaces well and correctly with the underlying operating system, graphics, sound, storage, …, and printing! The OS is under continuous development, things are changing all the time, components get replaced by others, printing is CUPS for 23 years, but within CUPS we have also changes, and they need to be taken care of in the print dialogs. + +Several years back, CUPS started to create temporary queues for driverless IPP network printers (or remote CUPS printers, which are emulations of IPP printers), which are only physically available when they are accessed (capabilities are polled or job printed). Print dialogs used an old API which did not support this, the temporary queues did not appear in the dialog, a helper daemon, cups-browsed had to convert the temporary queues into physical queues as a workaround. The correct solution had been to change the print dialogs to a newer CUPS API which supports these queues, but no one at the GUI toolkit projects has felt responsible and taken the time for this update for many years. Only recently this got fixed. + +This made me introducing the Common Print Dialog Backends (CPDB) back in 2017, a de-coupling of the print technology (CUPS, print-to-file, that time also Google Cloud Print) from the GUI. The GUI projects have to adopt the CPDB support only once and then OpenPrinting (or any upcoming cloud printing projects) takes care of the CPDB backend for the print technologies to be up-to-date with any changes. This way print technology projects can react quickly and are not dependent any more on the GUI toolkit’s inertia. + +The print dialogs of the major GUI toolkits, GTK, Qt, got CPDB support added in GSoC 2022, but several applications come with their own creation of a print dialog. AFAIK these are Firefox/Thunderbird (Mozilla), Chromium/Chrome (Google), and LibreOffice. Also these dialogs need to get CPDB support to make CPDB universal. + +Then we are especially prepared for the switch to CUPS 3.x which does not support PPD files any more, as the CUPS backend of CPDB is already using only CUPS APIs not handling PPD files. And we are also prepared for IPP infrastructure/cloud printing for which we also want to create a CPDB backend (see below). + +The contributor's task is to get CPDB into the print dialogs upstream, the UI of them does not need to be changed. Dialogs to be treated are Mozilla for Firefox and Thunderbird, Chromium/Chrome, LibreOffice, and any other application-specific dialog. For LibreOffice there was already worked on CPDB support back in 2017, but in the meantime things have changed and the dialog needs to get updated, especially for the new features of CPDB 2.x (human-readable strings/translations, option groups, ...). + +For the CPDB integration we do not need UI design work. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Firefox/Thunderbird/Mozilla developers, Chrome developers, LibreOffice developers, TBD +### Desired knowledge + `C/C++`, GTK or Qt, DNS-SD/Avahi, CUPS/IPP +### Code License + MIT, GPL-2+ and LGPL-2+ diff --git a/_gsoc2023/03-Scanning-support-in-PAPPL.md b/_gsoc2023/03-Scanning-support-in-PAPPL.md new file mode 100644 index 00000000..ab1801b1 --- /dev/null +++ b/_gsoc2023/03-Scanning-support-in-PAPPL.md @@ -0,0 +1,29 @@ +--- +title: "Scanning support in PAPPL" +--- + +### Introduction + +1 contributor full-size (350 hours). + +In the Google Summer of Code 2021, Bhavna Kosta has started the work on [Scanning support in PAPPL](https://github.com/Bhavna2020/GSoC-2021) (Talk on OpenPrinting micro-conference 2021: [Slides](https://linuxplumbersconf.org/event/11/contributions/1029/attachments/785/1474/Scanning%20in%20PAPPL.pdf), [Video](https://youtu.be/5KogjLb1Hb4?t=15600)) so that [PAPPL](https://github.com/michaelrsweet/pappl/) not only can be used for creating Printer Applications (emulation of a driverless IPP printer) but also for creating Scanner Applications (emulation of a driverless eSCL scanner), or even an emulation of a driverless IPP multi-function device. + +She has created the [needed data structures and API functions](https://github.com/michaelrsweet/pappl/tree/scanning) needed to extend PAPPL for supporting scanners. + +After that, in the Google Summer of Code 2022, Rishabh Maheshwari has then [implemented an eSCL parser](https://gist.github.com/Rishabh-792/b1a2960b7e0e3d2bd3a5f4db3d260fc0) so that Scanner Applications emulate eSCL scanners, the standard protocol which the hardware industry uses for driverless scanning. + +Next steps to complete the support are the following: + + * Implementation of the PAPPL internal functionality, integration of the eSCL interpreter code, response to the eSCL inquires, interface for callback functions with the actual scanner driver code, ... + * Create a test scanner driver emulating a scanner without needing actual scanner hardware, for example serving out static images from a directory. + * A retro-fit SANE interface to be added to the [pappl-retrofit](https://github.com/OpenPrinting/pappl-retrofit/) project (similar to [AirSANE](https://github.com/SimulPiscator/AirSane)), so that all already existing scanner drivers could be converted to Scanner Applications and this way scanning for clients distributed in sandboxed packages (like Snap) or on all-Snap OS distributions is assured. + * Unit tests + * Documentation + +The contributor's task to implement the above-mentioned components to complete the framework needed by all Scanner Applications. With this done, only code for the particular group of scanners to support (scanner driver) needs to be added to PAPPL. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Rishabh Maheshwari (rishphalod7 at gmail dot com), Deepak Patankar (patankardeepak04 at gmail dot com) +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2023/04-Turn-cups-browsed-into-a-Printer-Application.md b/_gsoc2023/04-Turn-cups-browsed-into-a-Printer-Application.md new file mode 100644 index 00000000..f6f50e55 --- /dev/null +++ b/_gsoc2023/04-Turn-cups-browsed-into-a-Printer-Application.md @@ -0,0 +1,25 @@ +--- +title: "Turn cups-browsed into a Printer Application" +--- + +### Introduction + +1 contributor full-size (350 hours). + +[cups-browsed](https://openprinting.github.io/achievements/#cups-browsed) is a helper daemon for CUPS to automatically set up network printers. In the beginning it was to overcome that when CUPS from 1.6.x on used DNS-SD instead of its own browsing/broadcasting, it did not auto-setup client queues any more. + +With the time it got lots of more functionality: Legacy CUPS browsing/broadcasting for interoperability with CUPS 1.5.x and older (often in long-term support enterprise distros), clustering, manually and automatically, also for clusters of printers of completely different types, user has one "universal" print queue and by their option settings job goes to the correct printer. Also filtering lists of many printers is supported, and everything can be configured/fine-tuned by the user or admin. + +With CUPS already having its temporary queue functionality for network printers without need of explicit manual setup, and the Common Print Dialog Backends getting into the print dialogs and talking to CUPS with modern interfaces, we do not need automatic queue creation for network printers any more, but the other functionality of cups-browsed is still very useful. + +So we do not want to discontinue cups-browsed, but take it into the New Architecture of printing, giving it the appropriate modern interface. Currently cups-browsed discovers printers via DNS-SD, and then creates (or not creates) local print queues pointing to them according to the rules in its configuration file. But currently it creates classic CUPS queues, with PPD files generated according to the printer's IPP attributes. What we need is make it working with CUPS 3.x, which drops PPD files and classic printer drivers. + +For this we want tom turn it into a Printer Application, the new printer driver format, emulating a driverless IPP printer. This way CUPS can access the printers created by cups-browsed and create temporary queues for them on-demand. Internally we define with configuration file what these queues should do: Clusters, retro-fit to old CUPS, ... + +The contributor's task is to implement this transition, using PAPPL for all standard elements of a Printer Application, like daemon, IPP parser, web admin interface, ... They will make cups-browsed create a queue in the Printer Application if appropriate destination printers get discovered, and remove it when these printers disappear (turned off, user leaves network, ...). CUPS will simply pick up on the emulated IPP printers then. And there will be a web interface to be created, for the configuration of the clusters, filter rules, .... one does not need to edit cups-browsed.conf manually any more. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Deepak Patankar (patankardeepak04 at gmail dot com), TBD +### Desired knowledge + `C`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2023/05-PAPPL-based-Printer-Applications.md b/_gsoc2023/05-PAPPL-based-Printer-Applications.md new file mode 100644 index 00000000..e9a40fa6 --- /dev/null +++ b/_gsoc2023/05-PAPPL-based-Printer-Applications.md @@ -0,0 +1,42 @@ +--- +title: "PAPPL-based Printer Applications: Option setting presets via web interface" +--- + +### Introduction + +1 contributor full-size (350 hours). + +Generally, Printer Applications as emulation of driverless IPP printers only support standard IPP job attributes as user-settable options: media size/type/source, duplex, printer-resolution, print-quality, print-content-optimize, ... but some drivers, like for example Gutenprint or also PostScript printers, have many options to fine-tune the printout and those cannot get individually mapped to IPP options so that the user can control them in a print dialog. Also many print dialogs, especially of phones, are limited to standard IPP attributes. + +So what we want to add is to have a preset functionality in PAPPL. On an extra web interface page you can create and edit any number of named presets. + +On this page you can create, copy, edit, and delete presets. + +You see a list of the existing presets, each with buttons for copy, edit, and delete. At the top you see the create button. + +If you click on the create button, you will get on the page for editing a preset. + +This page contains a field for the preset's name at the top, being empty if you are creating a new preset. You enter the desired name, only with a valid name you can save your preset. + +Under that you see the same options as on the "Printing Defaults" page, both the IPP standard attributes and the vendor options, but in the choices for each option is an extra one "Do not set" to not include this setting in the preset. This is chosen by default in a newly created preset. The rest of the choices are the ones which there are also under "Printing Defaults" but with the choice which is the current default under "Printing Defaults" having " (current default)" added, to ease the orientation for the user. To define the preset, the user chooses the settings for the desired attributes/options and leaves the attributes/options they do not to include in the template on "Do not set". If the user edits the name of the preset, it gets renamed. Then the user clicks on "Save" to save the preset. This brings them back to the list view, with the new preset in the list. + +The user can for example create a "photo" preset choosing photo paper, 4x6 size, and high print quality, or a "draft" preset choosing recycled paper and draft print quality. With Gutenprint they could fine-tune a lot of knobs for each paper type, photo style, ... and quickly get back to all their preferred settings by choosing the right template. + +The user-defined presets are made available to the client (print dialog, or better CUPS backend of the Common Print Dialog Backends, CPDB) by the "job-presets-supported" entry in the answer to the "get-printer-attributes" IPP request and so we get an option to select a preset in the print dialogs and the client (print dialog, CPDB backend) adds the settings described in the preset to the job. + +This, I think, is the best way to cope with printer drivers which have extended settings not mappable to standard IPP attributes, especially for complex drivers like Gutenprint, but also for the retro-fitting Printer Applications as the PPD files (treated by pappl-retrofit) always have non-standard options which end up as vendor options in a PAPPL-based Printer Application, not mapped to standard IPP options. + +This project should be implemented in [PAPPL](https://github.com/michaelrsweet/pappl/) and not in [pappl-retrofit](https://github.com/OpenPrinting/pappl-retrofit/), as the problem occurs for both native (developed from scratch) and retro-fitting Printer Applications (retro-fitting a classic CUPS driver with PPD files into a Printer Application). One can easily see it when one takes the (retro-fitting) [Gutenprint Printer Application](https://github.com/OpenPrinting/gutenprint-printer-app). See also the screenshot of the "Printing Defaults" page in the [Snap Store listing](https://snapcraft.io/gutenprint-printer-app). And this will not change when we turn Gutenprint into a native Printer Application (see below). + +This was already considered in the discussion during earlier work on the Gutenprint Printer Application. + +For the user experience with Gutenprint this preset feature would be even more important than the switchover to a native Printer Application. + + * [IPP Driver Replacement Extensions v2.0](https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippnodriver20-20221027.pdf) + * [Description of "job-presets" attribute](https://ftp.pwg.org/pub/pwg/ipp/registrations/reg-ipppreset-20171214.odt) +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), TBD +### Desired knowledge + `C`, PAPPL, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2023/06-Make-a-native-Printer-Application-from-Gutenprint.md b/_gsoc2023/06-Make-a-native-Printer-Application-from-Gutenprint.md new file mode 100644 index 00000000..c6bc3455 --- /dev/null +++ b/_gsoc2023/06-Make-a-native-Printer-Application-from-Gutenprint.md @@ -0,0 +1,31 @@ +--- +title: "Make a native Printer Application from Gutenprint" +--- + +### Introduction + +1 contributor full-size (350 hours). + +[Gutenprint](http://gimp-print.sourceforge.net/) is a high-quality printer driver for a wide range of inkjets, especially Epson and Canon, dye-sublimation printers and even monochrome PCL laser printers. It does not only cover many printers to give them support under Linux and free software operating systems at all, but also is optimized for highest possible print quality, so that at least on some printers and with the right settings you can even get better print quality than with the original (Windows/Mac) drivers. + +Gutenprint is usually used as classic CUPS driver with a CUPS filter and a PPD file generator. As, as mentioned above, CUPS will not support PPD files any more from version 3.x on and when using the CUPS Snap one cannot install PPD-based drivers already now. + +So a Printer Application of Gutenprint is needed. There [is already one](https://github.com/OpenPrinting/gutenprint-printer-app/), but it is a retro-fit of the classic CUPS driver. The Printer Application simply calls the PPD generator and the filter at the right places to do its job. + +As Gutenprint contains all its printer support and printer capability info in libgutenprint or in files which are read by libgutenprint, the PPD generator and the filter only containing calls of functions in libgutenprint, it should be easy to create a [PAPPL-based](https://github.com/michaelrsweet/pappl/), native Printer Application for Gutenprint. + +Here on an incoming get-printer-attributes IPP request we call the same functions which the PPD generator calls, but instead of translating the responses into a PPD file we translate it into the IPP answer for the get-printer-attributes request. And when we have a job to print, we call the library functions which the filter calls, but directly. + +This does not only save us from resource-consuming calls of external executables but we are also no harnessed by the PPD file syntax and so have more flexibility in the UI representations of the (often more than 100) printer-specific options. Also, generally we should completely do away with the PPDs. Retro-fitting is only an ugly interim solution or for drivers which are not actively maintained anymore and for printers we do not have at hand and so cannot test the drivers. + +The contributor's task is thus: + + * Create a PAPPL-based Printer Application using the libgutenprint library and PAPPL + * Make sure all options and parameters of the Gutenprint driver are accessible from the Printer Application's web admin interface. + * Package the Printer Application as a Snap +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gutenprint developers TBD +### Desired knowledge + `C`, PAPPL, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2023/07-CI-Testing-programs-for-libcupsfilters-libpappl-retrofit-libppd-CPDB-etc-.md b/_gsoc2023/07-CI-Testing-programs-for-libcupsfilters-libpappl-retrofit-libppd-CPDB-etc-.md new file mode 100644 index 00000000..c846592b --- /dev/null +++ b/_gsoc2023/07-CI-Testing-programs-for-libcupsfilters-libpappl-retrofit-libppd-CPDB-etc-.md @@ -0,0 +1,29 @@ +--- +title: "CI Testing programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, etc." +--- + +### Introduction + +1 contributor full-size (350 hours). + +To protect a free software project worked on by several contributors against regressions caused by a committed change, one needs frequent, automated testing of the code, base, ideally triggered by every commit into the repository. This is called Continuous Integration (CI). + +What is triggered on each commit is usually some static analysis of the code using common, specialized tools and also build and execution tests, usually doing `./configure; make; make test` on different system platforms. + +This naturally requires test scripts/programs which are compiled and run by the `make test` step. For CUPS for example the daemon is started (on an unprivileged port so that it does not need root), queues created and listed, jobs sent, the logs checked whether everything went OK, ... For Ghostscript a large collection of input files (gathered from bug reports) is processed and converted into raster formats. + +The contributor's task here is to write test programs for the different OpenPrinting projects so that `make test` does something useful, being efficient to catch regressions. They should exercise important functionality of the software with different parameters and analyse logs and output files to check whether the program did the expected work. + +Test programs are also needed for the so-called 'autopkgtest' tests which are added to Debian packages and executed whenever the package is uploaded to Debian or Ubuntu. + +In addition, instruction files and shell scripts are needed to build the software on different platforms/environments, run tests, create GitHub Actions (for the automatic triggering on each commit ...). + +This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: ([Summary](https://openprinting.github.io/OpenPrinting-News-September-2022/#openprinting-micro-conference-on-the-linux-plumbers-2022), [Slides](https://lpc.events/event/16/contributions/1161/attachments/942/1851/lpc-printing-ci-2022.pdf), [Video](https://www.youtube.com/watch?v=c--Uki7cvGE)) + +Here you can see what we already have in terms of CI, and what is missing ... +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), TBD +### Desired knowledge + C, Shell, PAPPL, CUPS, CI +### Code License + Apache 2.0, MIT diff --git a/_gsoc2023/08-GNOME-Control-Center.md b/_gsoc2023/08-GNOME-Control-Center.md new file mode 100644 index 00000000..d9fb6b34 --- /dev/null +++ b/_gsoc2023/08-GNOME-Control-Center.md @@ -0,0 +1,21 @@ +--- +title: "GNOME Control Center: List and handle IPP print services for the New Architecture" +--- + +### Introduction + +1 contributor full-size (350 hours). + +Modern printers usually are driverless IPP printers, and those get discovered fully automatically by CUPS, no CUPS queue needs to get explicitly created. Same for remote CUPS printers and also Printer Applications (new format for drivers for non-driverless specialty and legacy printers). They get all discovered as IPP print services. + +This means that a printer setup tool does not need to display CUPS queues any more, but instead, IPP print services, each of them being a possible destination for print jobs. + +And listings of IPP print services have different requirements: One server can have more than one individual print services and these should get listed together. This could be a print queue and a fax out queue of the same multi-function printer, or two physical legacy printers supported by one Printer Application. Also the user interaction coupled to each listing is different. We do not need to configure PPD option settings, but instead, we need access to the IPP service's web administration interface and also to an IPP System Service configuration panel by a simple mouse click. + +Several parts of this got already coded in previous GSoCs, but we need to get everything smoothly integrated in the "Printers" part of the GNOME Control Center, and this is the contributors task here. They will work together with the upstream maintainer of the "Printers" module, Marek Kasik and also with the UI/UX design teams of GNOME and of Canonical. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Mare Kasik (mkasik at redhat dot com), further GNOME/GTK developers TBD +### Desired knowledge + `C/C++`, GTK, DNS-SD/Avahi, CUPS/IPP +### Code License + GPL-2+ and LGPL-2+ diff --git a/_gsoc2023/09-cups-filters.md b/_gsoc2023/09-cups-filters.md new file mode 100644 index 00000000..2f22a9bb --- /dev/null +++ b/_gsoc2023/09-cups-filters.md @@ -0,0 +1,21 @@ +--- +title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" +--- + +### Introduction + +1 contributor half-size (175 hrs) + +Scanning with IPP Scan gives the user the possibility to request the scanned image in PDF format. If the IPP Scan server is a Scanner Application, a filter function from cups-filters would convert the the raster image coming from the scanner into PDF. + +Now such PDF files are simply raster images in a PDF frame, not high-level graphics with text and fonts, as PDFs produced by office applications are. Especially one cannot search text in a PDF coming from a scanning process. + +Ghostscript has a new "pdfocr8" device with which Ghostscript takes raster graphics PDFs (or PostScript files) as input, applies OCR (Optical Character Recognition) to the raster image, and creates a PDF which contains the raster image to visually show the scan but adds data about the contained text and where it is located, so that you can find text with the search facility of a PDF viewer. + +Here the contributor's task is to write a filter function (or extend the ghostscript() filter function) to make the "pdfocr8" output device of Ghostscript being used so that a searchable PDF is obtained. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2024/01-Desktop-integration.md b/_gsoc2024/01-Desktop-integration.md new file mode 100644 index 00000000..e262dffc --- /dev/null +++ b/_gsoc2024/01-Desktop-integration.md @@ -0,0 +1,35 @@ +--- +title: "Desktop integration: CPDB support for print dialogs of Mozilla (Thunderbird/Firefox) and LibreOffice" +--- + +### Introduction + +1-2 contributors full-size (350 hours), Level of difficulty: Hard + +Most print jobs are sent via the print dialog of a desktop application, like evince, Chrome, LibreOffice, DarkTable, … Print dialogs are usually, like “Open …” or “Save as …” dialogs, provided by the GUI toolkits, in most cases GTK or Qt, sometimes applications come also with their own creations, like LibreOffice or Firefox. + +Problem here is usually not the design of the dialog itself, most are actually easy to use, but the way how they connect to CUPS (and also to other print technologies) and how well this connection code is maintained and kept up-to-date. + +GUI toolkit projects are large projects, often with long release cycles and all with a certain inertia, and there are things which many people are eager to work on, and others, like print dialogs, which have to be there but no one is really motivated to push their development forward and do the needed maintenance work. + +An important part of the maintenance of a GUI toolkit is that it interfaces well and correctly with the underlying operating system, graphics, sound, storage, …, and printing! The OS is under continuous development, things are changing all the time, components get replaced by others, printing is CUPS for 23 years, but within CUPS we have also changes, and they need to be taken care of in the print dialogs. + +Several years back, CUPS started to create temporary queues for driverless IPP network printers (or remote CUPS printers, which are emulations of IPP printers), which are only physically available when they are accessed (capabilities are polled or job printed). Print dialogs used an old API which did not support this, the temporary queues did not appear in the dialog, a helper daemon, cups-browsed had to convert the temporary queues into physical queues as a workaround. The correct solution had been to change the print dialogs to a newer CUPS API which supports these queues, but no one at the GUI toolkit projects has felt responsible and taken the time for this update for many years. Only recently this got fixed. + +This made me introducing the Common Print Dialog Backends (CPDB) back in 2017, a de-coupling of the print technology (CUPS, print-to-file, that time also Google Cloud Print) from the GUI. The GUI projects have to adopt the CPDB support only once and then OpenPrinting (or any upcoming cloud printing projects) takes care of the CPDB backend for the print technologies to be up-to-date with any changes. This way print technology projects can react quickly and are not dependent any more on the GUI toolkit’s inertia. + +The print dialogs of the major GUI toolkits, GTK, Qt, got CPDB support added in GSoC 2022, but several applications come with their own creation of a print dialog. AFAIK these are Firefox/Thunderbird (Mozilla), Chromium/Chrome (Google), and LibreOffice. Also these dialogs need to get CPDB support to make CPDB universal. + +Then we are especially prepared for the switch to CUPS 3.x which does not support PPD files any more, as the CUPS backend of CPDB is already using only CUPS APIs not handling PPD files. And we are also prepared for IPP infrastructure/cloud printing for which we also want to create a CPDB backend (see below). + +The contributor's task is to get CPDB into the print dialogs upstream, the UI of them does not need to be changed. Dialogs to be treated are Mozilla for Firefox and Thunderbird, and also LibreOffice, and any other application-specific dialog if we have missed it by now. For LibreOffice there was already worked on CPDB support back in 2017, but in the meantime things have changed and the dialog needs to get updated, especially for the new features of CPDB 2.x (human-readable strings/translations, option groups, ...). + +CPDB support for the print dialog of the Chromium Browser is already done by Kushagra Sharma in GSoC [2023](https://github.com/kushagra20251/GSoC/). + +For the CPDB integration we do not need UI design work. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Firefox/Thunderbird/Mozilla developers, LibreOffice developers, TBD +### Desired knowledge + `C/C++`, GTK or Qt, DNS-SD/Avahi, CUPS/IPP +### Code License + MIT, GPL-2+ and LGPL-2+ diff --git a/_gsoc2024/02-Desktop-Integration.md b/_gsoc2024/02-Desktop-Integration.md new file mode 100644 index 00000000..26c00f35 --- /dev/null +++ b/_gsoc2024/02-Desktop-Integration.md @@ -0,0 +1,27 @@ +--- +title: "Desktop Integration: Update system-config-printer for the New Architecture of printing" +--- + +### Introduction + +1 contributor full-size (350 hours), Level of difficulty: Intermediate + +Originally, we already had discontinued the development of system-config-printer and put it into maintenance mode, only fixing bugs and collecting UI translations. + +But system-config-printer s still used a lot. There are practically only 3 printer setup tools around: The "Printers" module of GNOME Control Center, the printer manager of KDE Settings, and system-config-printer. There are many more desktop environments than just GNOME and KDE, and distributions using many of those use system-config-printer as their printer setup tool. + +For switching distributions into the New Architecture, meaning from CUPS 2.x to CUPS 3.x, the printer setup tool needs to get appropriately adapted, to list IPP print destinations with appropriate configuration options, especially access to their web admin interfaces, and assign Printer Applications to non-driverless printers. + +One could also think about dropping the concept of printer setup tools altogether as modern, driverless printers are simply there, but it is not very intuitive for a user to have to find a Printer Application and install it to make a non-driverless printer working and that for driverless printers and Printer Applications there are web admin interfaces and how to access them. + +So to assure continued coverage of all desktops we need to revive development of system-config-printer and make it supporting the New Architecture, but as with GNOME Control Center and KDE Settings we also need to keep the old functionality, to allow a switchover to the new CUPS at any time and already while still using CUPS 2.x, have a better support for driverless printers. + +And this is the contributor's task in this project. + +Note that system-config-printer is written in Python. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD +### Desired knowledge + Python, C, CUPS +### Code License + GPL-2+ (GPL 2 or any later version) diff --git a/_gsoc2024/03-Desktop-Integration.md b/_gsoc2024/03-Desktop-Integration.md new file mode 100644 index 00000000..ac156456 --- /dev/null +++ b/_gsoc2024/03-Desktop-Integration.md @@ -0,0 +1,25 @@ +--- +title: "Desktop Integration: User interfaces for using OAuth2 with printers and scanners" +--- + +### Introduction + +1 contributor full-size (350 hours), Level of difficulty: Hard + +From version 2.5.x on CUPS uses OAuth2 ([Open Authorization](https://en.wikipedia.org/wiki/OAuth)) for authorization purposes and drops the formerly used Kerberos with the CUPS 3.x generation. See latest state-of-the-art presentation from Michael Sweet: [slides](https://events.canonical.com/event/35/contributions/285/attachments/66/111/oos-cups-september-2023.pdf), [video](https://www.youtube.com/watch?v=vzu0FIyDfOo), slide 11). + +Authorization in printing is needed to once protect the data of confidential jobs, and second, to protect printer resources, like toner or paper. + +OAuth2, standard for authorization for internet services ("Log in with Google") is also used as authorization standard for IPP (Internet Printing Protocol) printing. + +As described in a talk on the OpenPrinting microconference on Linux Plumbers 2022 ([slides](https://lpc.events/event/16/contributions/1165/attachments/1093/2097/LPC2022_OAuth2_for_IPP.pdf), [video](https://www.youtube.com/watch?v=8UjrKos6LuY)) when accessing an IPP printer requiring authorization, it returns the URL to request the authorization from the authorization server in the response to the get-printer-attributes IPP request. Now the print client (print dialog, printer setup tool) has to open the URL in a browser so that the user can log in, create an account, or whatever the authorization server needs to identify the user. On success the server returns a URL with authorization code with which the client can get the access code to the printer. + +This works for all kinds of IPP print destinations which require authorization, not only physical network printers but also print servers and IPP-based cloud printing services. + +The contributor's task is to add the functionality to open the authorization server URLs and to supply the access code to the printer to the desktop printing workflow. This can be implemented in print dialogs or perhaps even made independent of concrete print dialogs by the [CPDB backend for CUPS](https://github.com/OpenPrinting/cpdb-backend-cups) triggering a D-Bus service for opening the URL (perhaps desktops always have such a thing?). Investigating what the best solution is for this task is part of the project. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), TBD +### Desired knowledge + `C/C++`, GTK or Qt, DNS-SD/Avahi, CUPS/IPP +### Code License + Apache 2.0, MIT, GPL-2+ and LGPL-2+ diff --git a/_gsoc2024/04-Integrating-C-based-OpenPrinting-projects-in-OSS-Fuzz-testing.md b/_gsoc2024/04-Integrating-C-based-OpenPrinting-projects-in-OSS-Fuzz-testing.md new file mode 100644 index 00000000..7e55af50 --- /dev/null +++ b/_gsoc2024/04-Integrating-C-based-OpenPrinting-projects-in-OSS-Fuzz-testing.md @@ -0,0 +1,44 @@ +--- +title: "Integrating C-based OpenPrinting projects in OSS-Fuzz testing" +--- + +### Introduction + +1 contributor full-size (350 hours), Level of difficulty: Intermediate + +[OSS-Fuzz](https://google.github.io/oss-fuzz) is a project aimed at finding vulnerabilities in open-source projects that are critical to the Internet infrastructure. It is powered by Google and was initiated in response to [Heartbleed](https://heartbleed.com), an OpenSSL vulnerability that could have been discovered with classic vulnerability discovery techniques. The codebases integrated into OSS-Fuzz are run multiple times with randomly crafted inputs in an approach called fuzzing. + +Most of OpenPrinting's code is written in C, which is susceptible to memory corruption bugs. OpenPrinting's projects do not use fuzzing, with a single exception: CUPS has a [custom fuzzer](https://github.com/OpenPrinting/cups/blob/master/cups/fuzzipp.c) run when testing the build, for a fixed number of iterations. + +Due to the compatibility of C projects with OSS-Fuzz, we would like to abandon the existing fuzzer and integrate the following C-based OpenPrinting projects into OSS-Fuzz (projects in priority order): + + * CUPS + * libcups + * cups-local + * cups-sharing + * libcupsfilters + * cups-filters + * cups-browsed + * PAPPL + * cpdb-libs + * cpdb-backend-cups + * libppd + * pappl-retrofit + +The purpose is to use the Google Summer of Code timeframe to create a mature OSS-Fuzz integration that maximises the number of fuzzed projects and fuzzing efficiency, as measured by coverage and execution speed. + +The contributor should work on: + + * Coordinating with OpenPrinting which projects have highest priority and also which functionality of them, to get the best from the limited GSoC time + * Creating Docker-based build environments + * Writing libFuzzer fuzz targets + * Creating a corpus of data + * Understanding and implementing the [OSS-Fuzz best practices](https://google.github.io/oss-fuzz/advanced-topics/ideal-integration/) + * Coordinating with the OpenPrinting developers to patch the vulnerabilities found by OSS-Fuzz + * Analysing the found vulnerabilities and interpreting their details to deduce vulnerability classes that can be mitigated in bulk. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me). +### Desired knowledge + C, fuzzing +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2024/05-Official-OCI-containers-Docker-ROCKs-podman-of-CUPS-and-Printer-Applications.md b/_gsoc2024/05-Official-OCI-containers-Docker-ROCKs-podman-of-CUPS-and-Printer-Applications.md new file mode 100644 index 00000000..6b57dc55 --- /dev/null +++ b/_gsoc2024/05-Official-OCI-containers-Docker-ROCKs-podman-of-CUPS-and-Printer-Applications.md @@ -0,0 +1,28 @@ +--- +title: "Official OCI containers (Docker, ROCKs, podman, ...) of CUPS and Printer Applications" +--- + +### Introduction + +1 contributor full-size (350 hours), Level of difficulty: Intermediate + +[Immutable desktop operating system distributions](https://ubuntu.com/blog/ubuntu-core-an-immutable-linux-desktop) are currently one of the most talked about subjects in free software. There is barely passing a week where one does not hear about any new distribution of this kind. + +Immutable distributions are made up of a read-only (immutable) core file system and applications are installed also as immutable container images. This gives more ease of use, reliability, and security, as the file systems cannot be modified and messed up, but instead, only replaced and updated as a whole, and also each application is in its own security capsule not being able to access any of the other applications or the system. This practice is commonplace on smartphones and got overtaken to PCs. + +On most immutable distributions, one installs desktop applications in the [Flatpak](https://flatpak.org/) format. This gives a huge choice of apps, but Flatpak cannot be used for GUI-less system applications and daemons. The solution for adding this type of software is the use of an alternative container format. And here [OCI containers](https://opencontainers.org/) are the solution. The container images can be downloaded from app-store-alike services like the [Docker Hub](https://hub.docker.com/) and be installed an run via [Docker](https://www.docker.com/), [podman](https://podman.io/) or similar. + +If you have a look at the Docker Hub you will find several container images for CUPS, but none of them is the official one, none of them comes from OpenPrinting. This makes the choice difficult, to find the most suitable one and also not get hit by a malicious one. So an official OCI container of CUPS is the first thing we need, to be able to have always the latest release of CUPS, directly from its developers. + +Another point is how to add printer and scanner drivers to immutable distributions. For this we also need containers of Printer and Scanner Applications. + +The contributor's task is to create these containers and infrastructure and scripting to ease their maintenance, like for example update automation when for one or another of their components a new upstream version is released, or for automated test building and testing. + +There are tools for creating such images, for example [rockcraft](https://discourse.ubuntu.com/c/rocks/) which uses build instruction files similar to Snap (see this [workshop](https://events.canonical.com/event/31/contributions/228/): [slides](https://events.canonical.com/event/31/contributions/228/attachments/132/209/%5Bslidedeck%5D%20Container%20craftsmanship_%20from%20a%20Pebble%20to%20a%20ROCK.pdf), [video](https://www.youtube.com/watch?v=BDXZxp3aFBY)) and so we can use our [CUPS Snap](https://github.com/OpenPrinting/cups-snap/) as base, but we will not require the contributor to use a special, given tool. +### Mentors +Till Kamppeter, Project Leader OpenPrinting (till at linux dot com) + +### Desired knowledge + Shell, Python, packaging, immutable OS distributions, GIT +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2024/06-Replace-QPDF-by-PDFio-as-PDF-manipulation-library-in-libcupsfilters.md b/_gsoc2024/06-Replace-QPDF-by-PDFio-as-PDF-manipulation-library-in-libcupsfilters.md new file mode 100644 index 00000000..42c0ce70 --- /dev/null +++ b/_gsoc2024/06-Replace-QPDF-by-PDFio-as-PDF-manipulation-library-in-libcupsfilters.md @@ -0,0 +1,25 @@ +--- +title: "Replace QPDF by PDFio as PDF manipulation library in libcupsfilters" +--- + +### Introduction + +1 contributor full-size (350 hours), Level of difficulty: Hard + +Like [CUPS](https://openprinting.github.io/cups/), [libcupsfilters](https://github.com/OpenPrinting/libcupsfilters) is principally written in regular C and not in `C++`. We want to avoid `C++` as it has often problems with binary compatibility and the mechanism with which the Debian/Ubuntu build services auto-detect dependencies between Debian packages get very awkward with `C++`. + +But libcupsfilters still depends on one library which is written in `C++`, [QPDF](https://github.com/qpdf/qpdf/), a library for manipulating PDF files: Scaling up and down, moving around on the page, rotating, combining several source pages on one destination page, turning filled PDF forms into straight PDF, ... QPDF is used by the filter functions cfFilterPDFToPDF(), cfFilterBannerToPDF(), cfFilterGSToRaster(), and cfFilterRasterToPDF(). + +Michael Sweet, author of CUPS, has some years ago started the [PDFio](https://www.msweet.org/pdfio/) project. This is a PDF handling and manipulation library, as QPDF is, but it is fully written in standard, regular C, not in `C++`. + +Therefore we want to replace the use of QPDF by PDFio and this is what this GSoC project is about. + +But for such a switchover we must take into account that QPDF is a complex and sophisticated project with a lot of features (it got even new features by two GSoC projects of OpenPrinting) while PDFio is a young project run as one of the many small projects by Michael Sweet and we must be very careful to see whether it does not miss any important feature. Especially we must look after correct printing of filled-in PDF forms and PDF annotations. + +So part of the project will be investigation of suitability and perhaps also work with Mike to get needed features added. And after the switchover thorough testing is needed to avoid any regressions after this impactful change. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Ira McDonald (blueroofmusic at gmail dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2024/07-Turn-cups-browsed-into-a-Printer-Application.md b/_gsoc2024/07-Turn-cups-browsed-into-a-Printer-Application.md new file mode 100644 index 00000000..287b1c8c --- /dev/null +++ b/_gsoc2024/07-Turn-cups-browsed-into-a-Printer-Application.md @@ -0,0 +1,31 @@ +--- +title: "Turn cups-browsed into a Printer Application" +--- + +### Introduction + +1 contributor full-size (350 hours), Level of difficulty: Hard + +[Gutenprint](http://gimp-print.sourceforge.net/) is a high-quality printer driver for a wide range of inkjets, especially Epson and Canon, dye-sublimation printers and even monochrome PCL laser printers. It does not only cover many printers to give them support under Linux and free software operating systems at all, but also is optimized for highest possible print quality, so that at least on some printers and with the right settings you can even get better print quality than with the original (Windows/Mac) drivers. + +Gutenprint is usually used as classic CUPS driver with a CUPS filter and a PPD file generator. As, as mentioned above, CUPS will not support PPD files any more from version 3.x on and when using the CUPS Snap one cannot install PPD-based drivers already now. + +So a Printer Application of Gutenprint is needed. There [is already one](https://github.com/OpenPrinting/gutenprint-printer-app/), but it is a retro-fit of the classic CUPS driver. The Printer Application simply calls the PPD generator and the filter at the right places to do its job. + +As Gutenprint contains all its printer support and printer capability info in libgutenprint or in files which are read by libgutenprint, the PPD generator and the filter only containing calls of functions in libgutenprint, it should be easy to create a [PAPPL-based](https://github.com/michaelrsweet/pappl/), native Printer Application for Gutenprint. + +Here on an incoming get-printer-attributes IPP request we call the same functions which the PPD generator calls, but instead of translating the responses into a PPD file we translate it into the IPP answer for the get-printer-attributes request. And when we have a job to print, we call the library functions which the filter calls, but directly. + +This does not only save us from resource-consuming calls of external executables but we are also no harnessed by the PPD file syntax and so have more flexibility in the UI representations of the (often more than 100) printer-specific options. Also, generally we should completely do away with the PPDs. Retro-fitting is only an ugly interim solution or for drivers which are not actively maintained anymore and for printers we do not have at hand and so cannot test the drivers. + +The contributor's task is thus: + + * Create a PAPPL-based Printer Application using the libgutenprint library and PAPPL + * Make sure all options and parameters of the Gutenprint driver are accessible from the Printer Application's web admin interface. + * Package the Printer Application as a Snap +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gutenprint developers TBD +### Desired knowledge + `C`, PAPPL, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2024/08-Converting-Braille-embosser-support-into-a-Printer-Application.md b/_gsoc2024/08-Converting-Braille-embosser-support-into-a-Printer-Application.md new file mode 100644 index 00000000..bdf51eb9 --- /dev/null +++ b/_gsoc2024/08-Converting-Braille-embosser-support-into-a-Printer-Application.md @@ -0,0 +1,24 @@ +--- +title: "Converting Braille embosser support into a Printer Application" +--- + +### Introduction + +1 contributor full-size (350 hours), Level of difficulty: Hard + +cups-filters currently supports Braille embossers through a series of PPD files and shell scripts that convert documents into a textual layout, convert the text into Braille dots, and convert the Braille dots to braille embosser-specific formats. + +For long-term support and wide availability, this needs to be converted to the newer CUPS infrastructure, Printer Applications. + +The contributor's task is thus: + + * Converting these shell scripts into filter functions in libcupsfilters + * Creating a Printer Application that exposes Braille embossers configuration to users + +The contributor does not need to own any specific hardware, a comparison can be made between the output of the existing shell-script-based implementation and the output of the converted implementation. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Samuel Thibault, Braille expert (samuel dot thibault at ens-lyon dot org) +### Desired knowledge + `C/C++`, Shell, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2024/09-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md b/_gsoc2024/09-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md new file mode 100644 index 00000000..19a8c141 --- /dev/null +++ b/_gsoc2024/09-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md @@ -0,0 +1,29 @@ +--- +title: "CI Testing programs for libpappl-retrofit and libppd" +--- + +### Introduction + +1 contributor full-size (350 hours), Level of difficulty: Intermediate + +To protect a free software project worked on by several contributors against regressions caused by a committed change, one needs frequent, automated testing of the code, base, ideally triggered by every commit into the repository. This is called Continuous Integration (CI). + +What is triggered on each commit is usually some static analysis of the code using common, specialized tools and also build and execution tests, usually doing `./configure; make; make test` on different system platforms. + +This naturally requires test scripts/programs which are compiled and run by the `make test` step. For CUPS for example the daemon is started (on an unprivileged port so that it does not need root), queues created and listed, jobs sent, the logs checked whether everything went OK, ... For Ghostscript a large collection of input files (gathered from bug reports) is processed and converted into raster formats. + +The contributor's task here is to write test programs for the OpenPrinting projects libppd and pappl-retrofit so that `make test` does something useful, being efficient to catch regressions. They should exercise important functionality of the software with different parameters and analyse logs and output files to check whether the program did the expected work. + +Test programs are also needed for the so-called 'autopkgtest' tests which are added to Debian packages and executed whenever the package is uploaded to Debian or Ubuntu. + +In addition, instruction files and shell scripts are needed to build the software on different platforms/environments, run tests, create GitHub Actions (for the automatic triggering on each commit ...). + +This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: ([Summary](https://openprinting.github.io/OpenPrinting-News-September-2022/#openprinting-micro-conference-on-the-linux-plumbers-2022), [Slides](https://lpc.events/event/16/contributions/1161/attachments/942/1851/lpc-printing-ci-2022.pdf), [Video](https://www.youtube.com/watch?v=c--Uki7cvGE)) + +Here you can see what we already have in terms of CI, and what is missing ... +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), TBD +### Desired knowledge + C, Shell, PAPPL, CUPS, CI +### Code License + Apache 2.0 diff --git a/_gsoc2024/10-cups-filters.md b/_gsoc2024/10-cups-filters.md new file mode 100644 index 00000000..829f6485 --- /dev/null +++ b/_gsoc2024/10-cups-filters.md @@ -0,0 +1,21 @@ +--- +title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" +--- + +### Introduction + +1 contributor half-size (175 hrs), Level of difficulty: Intermediate + +Scanning with IPP Scan gives the user the possibility to request the scanned image in PDF format. If the IPP Scan server is a Scanner Application, a filter function from cups-filters would convert the the raster image coming from the scanner into PDF. + +Now such PDF files are simply raster images in a PDF frame, not high-level graphics with text and fonts, as PDFs produced by office applications are. Especially one cannot search text in a PDF coming from a scanning process. + +Ghostscript has a new "pdfocr8" device with which Ghostscript takes raster graphics PDFs (or PostScript files) as input, applies OCR (Optical Character Recognition) to the raster image, and creates a PDF which contains the raster image to visually show the scan but adds data about the contained text and where it is located, so that you can find text with the search facility of a PDF viewer. + +Here the contributor's task is to write a filter function (or extend the ghostscript() filter function) to make the "pdfocr8" output device of Ghostscript being used so that a searchable PDF is obtained. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2025/01-Qt-Print-Dialog.md b/_gsoc2025/01-Qt-Print-Dialog.md new file mode 100644 index 00000000..32162580 --- /dev/null +++ b/_gsoc2025/01-Qt-Print-Dialog.md @@ -0,0 +1,19 @@ +--- +title: "Qt Print Dialog: Modernize the user interface" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Hard + +The print dialog of [Qt](https://contribute.qt-project.org/), which is also the print dialog used by KDE applications has still the user interface of 20 years ago, when I told the Qt and KDE developers that a CUPS-supporting print dialog is needed and they made this print dialog in response. + +Now, after the internals of the dialog being up-to-date (Support for the [Common Print Dialog Backends](https://openprinting.github.io/achievements/#common-print-dialog-backends) added in [GSoC 2022](https://github.com/TinyTrebuchet/gsoc22/)) we need to make the user interface of the Qt print dialog cute. + +The modernization should at least be a UI similar to the one of the GTK print dioalog. This should not require any extensions of the API between the print dialog and the applications and so the new dialog can replace the old one without modifications on existing applications needed. + +Optionally, depending on the time left, a dialog with built-in preview (Like in LibreOffice, Chromium, Firefox, Thunderbird) could be created. This requires more UI design work and most probably also additions to the API. The migration of a simple application (like text editor or document viewer) to the new print dialog would demo it and make the developers of other applications switch over. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Qt developers, TBD +### Desired knowledge + `C/C++`, Qt, UI Design +### Code License + LGPL-3 and GPL-2 diff --git a/_gsoc2025/02-GTK-Print-Dialog.md b/_gsoc2025/02-GTK-Print-Dialog.md new file mode 100644 index 00000000..3cd4f4bf --- /dev/null +++ b/_gsoc2025/02-GTK-Print-Dialog.md @@ -0,0 +1,19 @@ +--- +title: "GTK Print Dialog: Modern dialog with built-in preview in main view" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Hard + +Are you using LibreOffice, Firefox, Thunderbird, or Chromium with their nice, modern preview-centric print dialogs and got somewhat disappointed with GNOME apps like the Text Editor, Evince, or similar because of their more conventional [GTK](https://gitlab.gnome.org/GNOME/gtk) print dialog? Note that GTK's dialog has also a preview, but it is awkward to use, one has to click a button to get a preview, but there is no button to return to the main dialog to do adjustments. + +Then you should make an end to this problem, by modernizing the user interface (UI) of GTK's print dialog! + +Investigate the workflow of the modern preview-centric print dialogs and also have a look into their code (the mentioned apps are all open source). Also have a look into the code base of GTK's print dialog. Then design a similar UI, with embedded preview for the print dialog and implement it in GTK. + +Try to conserve the API between the application and the print dialog, so that the new print dialog can just replace old one in all applications. If this is not possible, try to keep the API additions a minimum, and for applications which are not (yet) adapted to the new print dialog, try to make as much as possible working in your print dialog (and as last resort display the old dialog). +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), GTK/GNOME developers, TBD +### Desired knowledge + C, GTK/GNOME, UI Design +### Code License + LGPL-2 or later and LGPL-2.1 or later diff --git a/_gsoc2025/03-KDE-Print-Manager-vs-CUPS-3-x.md b/_gsoc2025/03-KDE-Print-Manager-vs-CUPS-3-x.md new file mode 100644 index 00000000..7af10616 --- /dev/null +++ b/_gsoc2025/03-KDE-Print-Manager-vs-CUPS-3-x.md @@ -0,0 +1,19 @@ +--- +title: "KDE Print Manager vs. CUPS 3.x" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Hard + +As we have made the "Printers" module of the GNOME Control Center supporting CUPS 3.x in several GSoC projects we need to do the same for the [KDE Print Manger](https://invent.kde.org/plasma/print-manager/). And this is what this project is about. + +For the local server of CUPS 3.x the main view does not need to display CUPS queues as defined in `/etc/cups/printers.conf` with PPD files any more but instead, it has to display IPP print destinations (driverless network and IPP-over-USB printers, Printer Applications, shared remote CUPS queues) as on all these we can print, without a CUPS queue needing to be created, as CUPS creates a temporary one when needed. The destinations have to be grouped, when they come from the same device, server, or Printer Application, and the IPP destinations are configured by their admin web interfaces, so we have to add buttons to open these interfaces. + +The "Add Printer" dialog will continue to exist, but to list non-driverless (legacy or specialty) printers and assign Printer Applications instead of PPD files to them. + +Actually we will only add the new functionality and not remove the old one, meaning displaying both IPP destinations and classic CUPS queues, and in the "Add Printer" part allow for assigning both PPD files and Printer Applications (latter preferred), so that once the new Print Manager in place we can make a smooth transition from CUPS 2.x to CUPS 3.x at any time, and also, CUPS 2.x already supports IPP print destinations without permanent CUPS queue, so also for CUPS 2.x users modern, driverless printers will just appear and they do not try to unecessarily create queues for them. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Mike Noe (noeerover at gmail dot com), KDE developers, TBD +### Desired knowledge + `C/C++`, KDE/Qt, UI Design +### Code License + GPL 2.0 or later and LGPL 2.0 or later diff --git a/_gsoc2025/04-Port-pyCUPS-to-CUPS-3-x-API-apply-the-new-pyCUPS-to-system-config-printer.md b/_gsoc2025/04-Port-pyCUPS-to-CUPS-3-x-API-apply-the-new-pyCUPS-to-system-config-printer.md new file mode 100644 index 00000000..b91fb7a3 --- /dev/null +++ b/_gsoc2025/04-Port-pyCUPS-to-CUPS-3-x-API-apply-the-new-pyCUPS-to-system-config-printer.md @@ -0,0 +1,23 @@ +--- +title: "Port pyCUPS to CUPS 3.x API + apply the new pyCUPS to system-config-printer" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Intermediate + +Most software with print functionality or print administration functionality uses the CUPS library (libcups, [2.x](https://github.com/OpenPrinting/cups/), [3.x](https://github.com/OpenPrinting/libcups/)) to communicate with CUPS. This is easy when the software is written in C or `C++` as the library is written in C. + +If the software is written in other languages, we need some connection between the library and the client code, the so-called bindings. For Python we have bindings for libcups, [pyCUPS](https://github.com/OpenPrinting/pycups). This works well with libcups 2.x already for years. [system-config-printer](https://github.com/OpenPrinting/system-config-printer) is principal user of pyCUPS. + +What we need now is to extend pyCUPS for the use with [libcups 3.x](https://github.com/OpenPrinting/libcups/) of the new [CUPS 3.x](https://openprinting.github.io/cups/cups3.html), so that pyCUPS will live on and continue to allow writing software which interacts with CUPS in Python. + +The contributor's task is to go through the APIs of libcups3 and compare them with libcups2 to see what has to be added. If there is a way to automate the creation of Python bindings, it can be used and old (libcups2) and new (libcups3) has to be merged, so that pyCUPS can be used for any version of libcups. + +It should be also taken into account that libcups2 of CUPS 2.5.x got some functions of libcups3 backported. + +system-config-printer was already updated for CUPS 3.x in [last year's GSoC](https://github.com/TheJayas/GSoC-2024-Final-Report). Here we want system-config-printer use the new pyCUPS now, for optimization and minimization of code duplication. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Zdenek Dohnal, Printing Maintainer at Red Hat (zdohnal at redhat dot com), TBD +### Desired knowledge + Python, C, CUPS +### Code License + GPL-2+ (GPL 2 or any later version) diff --git a/_gsoc2025/05-Extend-PDFio-to-be-a-PDF-renderer-displayer.md b/_gsoc2025/05-Extend-PDFio-to-be-a-PDF-renderer-displayer.md new file mode 100644 index 00000000..f80935ec --- /dev/null +++ b/_gsoc2025/05-Extend-PDFio-to-be-a-PDF-renderer-displayer.md @@ -0,0 +1,21 @@ +--- +title: "Extend PDFio to be a PDF renderer/displayer" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Hard + +Like [CUPS](https://openprinting.github.io/cups/), [libcupsfilters](https://github.com/OpenPrinting/libcupsfilters) is principally written in regular C and not in `C++`. We want to avoid `C++` as it has often problems with binary compatibility and the mechanism with which the Debian/Ubuntu build services auto-detect dependencies between Debian packages get very awkward with `C++`. + +In libcupsfilters we now succeeded to eliminate use of `C++`, by replacing the use of the `C++` library [QPDF](https://github.com/qpdf/qpdf/) for PDF manipulation by Michael Sweet's [PDFio](https://www.msweet.org/pdfio/) and also by not using libpoppler any more but using Poppler's command line utilities instead. This was done as a [GSoC project last year](https://medium.com/@uddhavphatak/gsoc-2024-final-report-the-refactor-report-a46756e9d6ce). + +As the call of Poppler via command line utilities and Ghostscript having a license which makes it unsuitable in vertain cases, we are looking into a PDF rasterizer which is written in straight C and has a more friendly (permissive) license. PDFio is written in C and has the same license as CUPS and libcupsfilters themselves, but it is only a PDF manipulation library, not a renderer. + +But as PDFio is able to do the "dirty work" of PDF file reading, especially navigating through the file's object structure we can make use of it to create a PDF renderer, ideally to extend the PDFio library to provide this functionality or to create the renderer library using PDFio. + +This renderer should be aimed for printing, it should be principally called from libcupsfilters, or from Printer Applications, so the goal of this project is to get in this direction and not design a fancy GUI document viewer, but a simple screen display facility would be helpful for development and debugging. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Ira McDonald (blueroofmusic at gmail dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2025/06-Utilizing-OSS-Fuzz-Gen-to-improve-fuzz-testing-for-OpenPrinting-projects.md b/_gsoc2025/06-Utilizing-OSS-Fuzz-Gen-to-improve-fuzz-testing-for-OpenPrinting-projects.md new file mode 100644 index 00000000..4ea028b3 --- /dev/null +++ b/_gsoc2025/06-Utilizing-OSS-Fuzz-Gen-to-improve-fuzz-testing-for-OpenPrinting-projects.md @@ -0,0 +1,36 @@ +--- +title: "Utilizing OSS-Fuzz-Gen to improve fuzz testing for OpenPrinting projects" +--- +### Introduction +**Security- and AI-related project** + +1 contributor full-size (350 hours), Level of difficulty: Hard + +Recent vulnerabilities (including [CVE-2024-47175, CVE-2024-47176, CVE-2024-47177](https://openprinting.github.io/OpenPrinting-News-Flash-cups-browsed-Remote-Code-Execution-vulnerability/)) reported in OpenPrinting projects have underscored the critical need for robust security measures. Given that most of the projects of OpenPrinting are developed in `C/C++`, which are prone to memory violation bugs. To address these challenges, OpenPrinting has engaged with Google's [OSS-Fuzz](https://github.com/google/oss-fuzz/), a service designed to support open-source communities by providing large-scale fuzz testing and bug reporting, and maintains the fuzz harnesses in the separate [OpenPrinting fuzzing](https://github.com/OpenPrinting/fuzzing) repository. + +**Current Integration with OSS-Fuzz:** OpenPrinting has successfully integrated **three** key projects into the OSS-Fuzz workflow, with **two** additional projects currently in progress. Although the integration has already yielded significant results, which have reported **21** critical fixed bugs leading to more than **5,000** lines of code fixes, it remains insufficient. The [testing coverage](https://introspector.oss-fuzz.com/project-profile?project=cups) for critical components is still lacking, and the severity of potential issues within OpenPrinting projects demands further action. + +For now, OpenPrinting has integrated projects into the OSS-Fuzz workflow: + * [cups](https://github.com/OpenPrinting/cups) + * [libcups (of CUPS 3.x)](https://github.com/OpenPrinting/libcups) + * [cups-filters](https://github.com/OpenPrinting/cups-filters) + +The following projects are under construction: + * [libcupsfilters](https://github.com/OpenPrinting/libcupsfilters) + * [cups-browsed](https://github.com/OpenPrinting/cups-browsed) + +With Google's introduction of [OSS-Fuzz-Gen](https://github.com/google/oss-fuzz-gen), which leverages Large Language Models (LLMs) to enhance fuzz testing for open-source software, it has demonstrated exceptional potential in facilitating the integration of high-quality fuzz testing ([Google Blog](https://testing.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html)). Therefore, we aim to utilize the OSS-Fuzz-Gen framework to further improve the existing quality of OSS-Fuzz harnesses + +**Project Goals for GSoC 2025:** The primary objective for this Google Summer of Code project is to refine and expand our existing fuzz testing harnesses. Specifically: + * **Enhancing Existing Harnesses:** Improve the quality of dictionaries, configurations, and seed data for current integrations, adhering to OSS-Fuzz best practices. + * **Expanding Harness Integration:** Utilize OSS-Fuzz-Gen to develop and implement additional harnesses, targeting high-value, difficult-to-reach code sections with the support of LLMs. + +**Contributor Responsibilities:** + * Master OSS-Fuzz best practices to provide high-quality seeds and corpus for existing integrations. Employ OSS-Fuzz-Gen to create and integrate new harnesses, adopting diverse strategies to enhance code coverage. + * Collaborate with OpenPrinting developers to identify and patch vulnerabilities uncovered through fuzz testing. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me). +### Desired knowledge + C, Python, fuzz-testing +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2025/07-Integrating-OSS-Fuzz-for-Go-based-and-Python-based-OpenPrinting-projects.md b/_gsoc2025/07-Integrating-OSS-Fuzz-for-Go-based-and-Python-based-OpenPrinting-projects.md new file mode 100644 index 00000000..b95aed12 --- /dev/null +++ b/_gsoc2025/07-Integrating-OSS-Fuzz-for-Go-based-and-Python-based-OpenPrinting-projects.md @@ -0,0 +1,30 @@ +--- +title: "Integrating OSS-Fuzz for Go-based and Python-based OpenPrinting projects" +--- +### Introduction +**Security-related project** + +1 contributor medium-size (175 hours), Level of difficulty: Intermediate + +OpenPrinting hosts many polyglot projects, which are developed not limited to languages of `C/C++`. We also host software written in languages like Python and Golang, which function as crucial printing APIs and often interface with `C/C++` libraries to deliver comprehensive printing services. The integration of multiple programming languages into our ecosystem underscores the necessity for a broad and inclusive testing approach. Given the diversity of development environments, it is crucial to extend the testing for these projects, specifically for integration of [OSS-Fuzz](https://github.com/google/oss-fuzz). + +To this end, we plan to extend the capabilities of the existing OSS-Fuzz frameworks to include projects developed in languages other than `C/C++`. This initiative will target Python and Golang projects, ensuring that our fuzz testing encompasses the full spectrum of development environments within OpenPrinting. + +**Project Goals for GSoC 2025:** The primary objective for this Google Summer of Code project is to integrate the polyglot projects in OpenPrinting into OSS-Fuzz framework and refine existing unit tests for these projects. The targeting projects include: + * **Golang** + * [ipp-usb](https://github.com/OpenPrinting/ipp-usb) + * [goipp](https://github.com/OpenPrinting/goipp) + * **Python** + * [pycups](https://github.com/OpenPrinting/pycups) + * [pyppd](https://github.com/OpenPrinting/pyppd) + +**Contributor Responsibilities:** + * **Evaluate and Improve Testing Approaches:** The contributor needs to understand existing testing strategies within the project and evaluate their effectiveness. Where there are gaps, particularly in areas that are under-tested, the contributor should develop and improve tests to cover these functionalities. + * **Integrate Projects into OSS-Fuzz Workflow:** The contributor should also integrate these projects into OSS-Fuzz framework, following previous integrations for `C/C++` projects in OpenPrinting [fuzzing](https://github.com/OpenPrinting/fuzzing) repository with appropriate fuzzing corpus. + * **Triage and Report Vulnerabilities:** The contributor should work closely with developers from OpenPrinting to identify and report any vulnerabilities that are discovered through the testing process. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me). +### Desired knowledge + Python, Go, fuzz-testing +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2025/08-System-Fuzz-Testing-of-Printing-Protocols.md b/_gsoc2025/08-System-Fuzz-Testing-of-Printing-Protocols.md new file mode 100644 index 00000000..9b07f1fc --- /dev/null +++ b/_gsoc2025/08-System-Fuzz-Testing-of-Printing-Protocols.md @@ -0,0 +1,26 @@ +--- +title: "System/Fuzz Testing of Printing Protocols" +--- +### Introduction +**Security-related project** + +1 contributor full-size (350 hours), Level of difficulty: Hard + +As OpenPrinting advances driverless printing services, the corresponding standardized printing protocols, such as the Internet Printing Protocol (IPP), have become more and more important. The protocol is fundamental to achieving generalized printing services and thus requires rigorous security testing to prevent vulnerabilities. + +Effective testing of printing protocols and Domain-specific languages (DSL) like IPP and PostScript demands precise input pairs and well-regulated testing environments/contexts. Given the complexity and technical specifications of these protocols, creating universal testing suites that can be applied across various platforms and languages is essential. Such suites will support the consistent functionality and specification adherence necessary for secure and efficient printing operations. + +**Project Goals for GSoC 2025:** The primary objective for this Google Summer of Code project is to develop comprehensive testing suites designed for the printing protocols used in OpenPrinting projects (e.g., IPP). Specifically, the suites encompass: (1) unit tests and differential tests for IPP, detailing test inputs and expected outputs within the appropriate printing contexts, and (2) fuzzing enhanced by a custom validator to verify the correctness of outputs against the specifications. These suites will incorporate unified testing drivers and oracles (validated test input and output pairs) to ensure accurate and reliable results. + +**Contributors are expected to achieve:** + * Thoroughly understand and summarize the key aspects of printing protocols used in OpenPrinting, such as IPP and PostScript. + * Develop tailored testing strategies for these protocols, referencing standards such as [RFC 8011](https://datatracker.ietf.org/doc/html/rfc8011), and [OpenPrinting's 17 IPP specifications](https://openprinting.github.io/cups/doc/spec-ipp.html) + * Implement high-quality unit tests, differential tests, and fuzzing drivers along with protocol-tailed testing oracles within OpenPrinting projects. Contributors will also be responsible for identifying any discrepancies or bugs, reporting them, and coordinating with developers to facilitate necessary fixes. + +*The outputs of this project will not only serve as a valuable reference for generalizing testing across all OpenPrinting projects but also the documented progress can also lead to potential academic contributions, such as technical reports or research papers.* +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me). +### Desired knowledge + `C/C++`, security/testing +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2025/09-Security-Auditing-for-OpenPrinting-Projects.md b/_gsoc2025/09-Security-Auditing-for-OpenPrinting-Projects.md new file mode 100644 index 00000000..3777b151 --- /dev/null +++ b/_gsoc2025/09-Security-Auditing-for-OpenPrinting-Projects.md @@ -0,0 +1,21 @@ +--- +title: "Security Auditing for OpenPrinting Projects" +--- +### Introduction +**Security-related project** + +1 contributor full-size (350 hours), Level of difficulty: Intermediate + +OpenPrinting projects play a critical role in the printing infrastructure of countless systems, making their security paramount. Inspired by security auditing reports from other open source communities (CNCF: [Security Audit for Karmada](https://www.cncf.io/blog/2025/01/16/announcing-the-results-of-the-karmada-security-audit/), [Security Audit for Kubernetes](https://www.cncf.io/blog/2023/04/19/new-kubernetes-security-audit-complete-and-open-sourced/) and [Security Audit for OpenSSF](https://openssf.org/blog/2023/02/01/independent-security-audit-impact-report/)), we believe a comprehensive security auditing report could significantly enhance the robustness and reliability of these projects. This initiative will leverage advanced software analysis methods to conduct thorough security audits. + +The audit process includes scoring OpenPrinting projects using OpenSSF’s Security Scorecard and examining the projects and their dependencies with respect to testing status, which encompasses adherence to continuous integration (CI) test best practices and test coverage assessments. Furthermore, dynamic testing should also be considered, for example, end-to-end fuzzing techniques such as [AFLplusplus](https://github.com/AFLplusplus/AFLplusplus), which assists in the successful detection of [CVE-2024-47076](https://www.cve.org/CVERecord?id=CVE-2024-47076). Static analysis tools including [cppcheck](https://github.com/danmar/cppcheck) and [flawfinder](https://github.com/david-a-wheeler/flawfinder), [Valgrind](https://valgrind.org/) can be employed for checking the implementation flaws. The overall security audit should include dynamic software analysis methodologies to cover more extensive aspects of OpenPrinting projects. + +**Project Goals for GSoC 2025:** The primary objective of this Google Summer of Code project is to complete a systematic security audit report for OpenPrinting. This comprehensive process includes maximizing the scores provided by the [OpenSSF Security Scorecard](https://scorecard.dev) and scanning dependencies using existing SADT tools. In addition to static analysis, incorporating dynamic testing methodologies will provide an exhaustive overview of security across the entire network of projects. The project aims to identify and mitigate potential vulnerabilities effectively, ensuring that a robust defense mechanism is in place to protect the integrity of the OpenPrinting infrastructure. + +**Contributors are expected to:** Use or implement dynamic testing/auditing tools for analyzing OpenPrinting projects, which includes examining OpenSSF Scorecard of OpenPrinting projects and preparing detailed security auditing reports outlining discovered vulnerabilities. The contributor should also coordinate with security experts to address these issues effectively. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me). +### Desired knowledge + `C/C++`, code auditing +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2025/10-Behavior-accurate-simulation-of-multi-function-printers-printer-scanner-.md b/_gsoc2025/10-Behavior-accurate-simulation-of-multi-function-printers-printer-scanner-.md new file mode 100644 index 00000000..7c72a90e --- /dev/null +++ b/_gsoc2025/10-Behavior-accurate-simulation-of-multi-function-printers-printer-scanner-.md @@ -0,0 +1,30 @@ +--- +title: "Behavior-accurate simulation of multi-function printers (printer + scanner)" +--- +### Introduction +1-3 contributors full-size (350 hours), Level of difficulty: Hard + +Although driverless printing and scanning are governed by standards and specifications, real hardware implementations often have unique details that can deviate from these specifications, impacting the accuracy of our printing and scanning implementations. + +We currently have the "ippeveprinter" tool, which implements an "abstract" IPP 2.x printer. However, we lack a behavior-accurate simulation of real printers and do not have any simulation for eSCL/WSD scanners. + +The goal is to create a behavior-accurate simulator for multi-function printers (MFPs) that supports at least IPP 2.x for printing, eSCL and WSD for scanning, and DNS-SD and WS-Discovery for device discovery. We aim to build a growing collection of models representing various specific devices. + +This simulator will consist of a core simulation engine that provides reference implementations of the aforementioned protocols, along with a customization engine that allows for the expression of implementation details specific to individual devices without the need to reimplement common functionalities repeatedly. + +One of our key objectives is to make the process of creating MFP models semi-automated. For instance, printer attributes and scanner capabilities can be automatically obtained, while accurately simulating behavioral features may require manual testing and analysis to identify these details, along with scripting to express them in the simulator. We anticipate that actual device behavior will not deviate significantly from the "ideal" model implemented by the simulation core, allowing models to remain relatively straightforward. Ideally, the model creation process should be simple enough for mid-level technical personnel and qualified users to undertake independently. + +This initiative opens up several new avenues: + * Remote debugging of printing/scanning issues without needing to connect to the device or engage extensively with the device owner + * The ability to test software changes without physical access to the relevant hardware + * Full-stack automated testing of printing and scanning against simulated hardware + +Initially, our collection of models will be small and may contain inaccuracies. However, as we expand our model collection, we will be able to automatically detect most regression cases during the development of the entire printing and scanning stack. + +The implementation of the simulation core has already started, what we need from the contributor(s) is to develop the initial collection of the printer models. During this phase, we will evaluate and refine the overall concept, establishing and assessing the methodology for creating MFP models. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD +### Desired knowledge + Familiarity with relevant protocols (IPP, eSCL, WSD, DNS-SD), knowledge of the Linux printing and scanning stack, programming in C, and proficiency in Python or JavaScript (for scripting MFP models). +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2025/11-Image-output-evaluation-for-testing-of-print-scan-job-processing.md b/_gsoc2025/11-Image-output-evaluation-for-testing-of-print-scan-job-processing.md new file mode 100644 index 00000000..7e6205b4 --- /dev/null +++ b/_gsoc2025/11-Image-output-evaluation-for-testing-of-print-scan-job-processing.md @@ -0,0 +1,27 @@ +--- +title: "Image output evaluation for testing of print/scan job processing" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Hard + +We do a lot of testing for quality assurance and security of our software, especially also tests of the data processing when printing and scanning. For now our only criteria to consider a test failed is a processing error, a crash, an infinite loop, or the output being empty. We do not verify whether the content of the output is actually what we have expected. + +Evaluating the correctness of the content of the output is not easy, as we cannot compare it pixel by pixel, we rather need to determine whether a human being would see the content which they have sent to the printer. This means to recognize text, structures, colors, but with a certain tolerance. + +There is free software work at GNOME for the CI testing of their GUI, which requires to analyse graphical screen content to evaluate whether the response of GUI apps to given user input is as expected, and this should be fully automated. This is the [openQA](https://gitlab.gnome.org/GNOME/openqa-tests) project. + +To compare graphical content they use the free software computer vision library [OpenCV](https://opencv.org/) and also the universal file comparison tool [diffoscope](https://diffoscope.org/) is used to check output. + +With this we could for example take a PDF file, rasterize it in high quality, then "print" it/send it through a filter chain and afterwards compare the images. We can also OCR raster output to check whether the complete text of the input (plain text or PDF file) is conserved in the output, not having anything cut off at the borders and no glyphs missing or replaced by squares/placeholders for missing glyphs. + +See also [my report from the GUADEC 2024](https://openprinting.github.io/OpenPrinting-News-July-2024/#guadec-2024-in-denver), the section "Workshop: openQA testing for your GNOME app, module or service". + +Tests which benefit from this are not only our CI testing in libcupsfilters, but also 2 of our other projects on this list: + * Behavior-accurate simulation of multi-function printers + * Fuzz-based testing of printing protocols +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD +### Desired knowledge + C, Go, image processing and evaluation, computer vision, OCR +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2025/12-Port-CUPS-and-Printer-Applications-to-Zephyr.md b/_gsoc2025/12-Port-CUPS-and-Printer-Applications-to-Zephyr.md new file mode 100644 index 00000000..281745bf --- /dev/null +++ b/_gsoc2025/12-Port-CUPS-and-Printer-Applications-to-Zephyr.md @@ -0,0 +1,23 @@ +--- +title: "Port CUPS and Printer Applications to Zephyr" +--- +### Introduction +Probably many of you have already thought about that one can take an SBC, install Linux and [CUPS](https://openprinting.github.io/cups) or a Printer Application on it, and connect this to an old printer which is still mechanically perfect but needs a driver which is not available any more for some operating systems. Suddenly the printer turns into a modern, driverless IPP printer which can be used with any operating system. + +But it is a little awkward having a little box dangling behind the printer which also occupies a power outlet. Also one can perhaps also make use of much cheaper SBC. + +Imagine you could buy a tiny board for a few dollars and put it somewhere inside the printer and grab its power from the printer's power supply. + +Such tiny boards are often not powerful enough to run Linux, but there is also the much more lightweight [Zephyr](https://www.zephyrproject.org/) operating system. This is a system for IoT applications on low-footprint hardware. + +And this scenario does not only serve for cheap DIY solutions to save old printers, it also can be a base for cost-effective printer firmware development. + +This project is about investigating whether one could run the components of the free software printing stack, as [CUPS](https://openprinting.github.io/cups), [PAPPL](https://github.com/michaelrsweet/pappl/), [libcupsfilters](https://github.com/OpenPrinting/libcupsfilters), ... under the Zephyr operating system, and actually let this tiny print server execute printer drivers and print on legacy printers. Also the handling of print data and the need of resources here needs to be investigated. Can we hold several pages? Can we use [Ghostscript](https://ghostscript.com/)? Or do we have to stream raster print data from the client to the printer? + +Most desirable is to do this with PAPPL (Printer APPlication Library), as it is designed to emulate a driverless IPP printer in software, including the so-called "Gadget" mode to appear as an IPP-over-USB device when connecting the power supply USB port of the SBC with the client computer's USB. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Iuliana Prodan (iuliana dot prodan at nxp dot com), Zephyr developers TBD +### Desired knowledge + C, Zephyr, USB, network +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2025/13-Rust-bindings-for-libcups2-3.md b/_gsoc2025/13-Rust-bindings-for-libcups2-3.md new file mode 100644 index 00000000..83533edc --- /dev/null +++ b/_gsoc2025/13-Rust-bindings-for-libcups2-3.md @@ -0,0 +1,15 @@ +--- +title: "Rust bindings for libcups2/3" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Hard + +Most software with print functionality or print administration functionality uses the CUPS library (libcups, [2.x](https://github.com/OpenPrinting/cups/), [3.x](https://github.com/OpenPrinting/libcups/)) to communicate with CUPS. This is easy when the software is written in C or `C++` as the library is written in C. If the software is written in other languages, we need some connection between the library and the client code, the so-called bindings. + +A programming language which gets more and more used nowadays is Rust, due to its memory-safety, eliminating the number-one source of crashes and vulnerabilities. Unfortunately, we do not have Rust bindings for libcups. And getting them is subject of this project. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD +### Desired knowledge + Python, C, CUPS +### Code License + GPL-2+ (GPL 2 or any later version) diff --git a/_gsoc2025/14-Error-response-pop-up-support-for-CPDB.md b/_gsoc2025/14-Error-response-pop-up-support-for-CPDB.md new file mode 100644 index 00000000..9a265286 --- /dev/null +++ b/_gsoc2025/14-Error-response-pop-up-support-for-CPDB.md @@ -0,0 +1,23 @@ +--- +title: "Error response pop-up support for CPDB" +--- +### Introduction +1 contributor medium-size (175 hours), Level of difficulty: Intermediate + +It often happens that a print job, sent to a network printer or to a remote CUPS queue does not get printed and [a "cups-pki-invalid" error will get logged](https://github.com/OpenPrinting/cups/issues/1072). This is due to the fact that the locally saved certificate does not match the printer (any more). + +To prevent man-in-the-middle attacks between a client and a network IPP printer with encrypted connection, the first time when a new network printer is accessed, the printer's certificate is loaded from the printer and saved locally. On subsequent accesses the printer's certificate is compared to the locally saved one and on mismatch the error is logged and the printing does not happen. + +often this happens without an attack, just on a change of the printer configuration or a printer firmware update. Then the user screams on internet platforms, when they are lucky finds information about this problem and how to remove the old certificate to make the CUPS replace it by the current one and the printer print again. + +To solve this nasty problem, we came to the conclusion to [pop up a dialog which allows to remove the certificate file ("Reset certificte") by clicking a button.](https://github.com/OpenPrinting/cups/issues/1072#issuecomment-2537216779). + +The contributor's task here is to create such a dialog and make it pop up in the right situation. The pop-up should also be used for other common error scenarios which could be solved by a simple dialog. + +The communication between the pop-up and CUPS should be done by the [Common Print Dialog Backends (CPDB)](https://github.com/OpenPrinting/cpdb-libs), extending the D-Bus interface and implementing the error handling in the CPDB CUPS backend. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Kushagra Sharma (b20251 at students dot iitmandi dot ac dot in), TBD +### Desired knowledge + `C/C++`, GTK or Qt, DNS-SD/Avahi, CUPS/IPP +### Code License + MIT, GPL-2+ and LGPL-2+ diff --git a/_gsoc2025/15-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md b/_gsoc2025/15-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md new file mode 100644 index 00000000..a0c567b5 --- /dev/null +++ b/_gsoc2025/15-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md @@ -0,0 +1,27 @@ +--- +title: "CI Testing programs for libpappl-retrofit and libppd" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Intermediate + +To protect a free software project worked on by several contributors against regressions caused by a committed change, one needs frequent, automated testing of the code, base, ideally triggered by every commit into the repository. This is called Continuous Integration (CI). + +What is triggered on each commit is usually some static analysis of the code using common, specialized tools and also build and execution tests, usually doing `./configure; make; make test` on different system platforms. + +This naturally requires test scripts/programs which are compiled and run by the `make test` step. For CUPS for example the daemon is started (on an unprivileged port so that it does not need root), queues created and listed, jobs sent, the logs checked whether everything went OK, ... For Ghostscript a large collection of input files (gathered from bug reports) is processed and converted into raster formats. + +The contributor's task here is to write test programs for the OpenPrinting projects libppd and pappl-retrofit so that `make test` does something useful, being efficient to catch regressions. They should exercise important functionality of the software with different parameters and analyse logs and output files to check whether the program did the expected work. + +Test programs are also needed for the so-called 'autopkgtest' tests which are added to Debian packages and executed whenever the package is uploaded to Debian or Ubuntu. + +In addition, instruction files and shell scripts are needed to build the software on different platforms/environments, run tests, create GitHub Actions (for the automatic triggering on each commit ...). + +This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: ([Summary](https://openprinting.github.io/OpenPrinting-News-September-2022/#openprinting-micro-conference-on-the-linux-plumbers-2022), [Slides](https://lpc.events/event/16/contributions/1161/attachments/942/1851/lpc-printing-ci-2022.pdf), [Video](https://www.youtube.com/watch?v=c--Uki7cvGE)) + +Here you can see what we already have in terms of CI, and what is missing ... +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), TBD +### Desired knowledge + C, Shell, PAPPL, CUPS, CI +### Code License + Apache 2.0 diff --git a/_gsoc2025/16-cups-filters.md b/_gsoc2025/16-cups-filters.md new file mode 100644 index 00000000..fe1b47cf --- /dev/null +++ b/_gsoc2025/16-cups-filters.md @@ -0,0 +1,19 @@ +--- +title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" +--- +### Introduction +1 contributor medium-size (175 hrs), Level of difficulty: Intermediate + +Scanning with IPP Scan gives the user the possibility to request the scanned image in PDF format. If the IPP Scan server is a Scanner Application, a filter function from cups-filters would convert the the raster image coming from the scanner into PDF. + +Now such PDF files are simply raster images in a PDF frame, not high-level graphics with text and fonts, as PDFs produced by office applications are. Especially one cannot search text in a PDF coming from a scanning process. + +Ghostscript has a new "pdfocr8" device with which Ghostscript takes raster graphics PDFs (or PostScript files) as input, applies OCR (Optical Character Recognition) to the raster image, and creates a PDF which contains the raster image to visually show the scan but adds data about the contained text and where it is located, so that you can find text with the search facility of a PDF viewer. + +Here the contributor's task is to write a filter function (or extend the ghostscript() filter function) to make the "pdfocr8" output device of Ghostscript being used so that a searchable PDF is obtained. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD +### Desired knowledge + `C/C++`, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2026/01-system-config-printer-vs-CUPS-3-x.md b/_gsoc2026/01-system-config-printer-vs-CUPS-3-x.md new file mode 100644 index 00000000..01447ce7 --- /dev/null +++ b/_gsoc2026/01-system-config-printer-vs-CUPS-3-x.md @@ -0,0 +1,23 @@ +--- +title: "system-config-printer vs. CUPS 3.x" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Hard + +As we have made the "Printers" module of the GNOME Control Center and the KDE Print Manager supporting CUPS 3.x in several GSoC projects we need to do the same for the [system-config-printer](https://github.com/OpenPrinting/system-config-printer). And this is what this project is about. + +For the local server of CUPS 3.x the main view does not need to display CUPS queues as defined in `/etc/cups/printers.conf` with PPD files any more but instead, it has to display IPP print destinations (driverless network and IPP-over-USB printers, Printer Applications, shared remote CUPS queues) as on all these we can print, without a CUPS queue needing to be created, because CUPS creates a temporary one when needed. The destinations have to be grouped, when they come from the same device, server, or Printer Application, and the IPP destinations are configured by their admin web interfaces, so we have to add buttons to open these interfaces. + +The "Add Printer" dialog will continue to exist, but to list non-driverless (legacy or specialty) printers and assign Printer Applications instead of PPD files to them. + +Actually we will only add the new functionality and not remove the old one, meaning displaying both IPP destinations and classic CUPS queues, and in the "Add Printer" part allow for assigning both PPD files and Printer Applications (latter preferred), so that once the new Print Manager in place we can make a smooth transition from CUPS 2.x to CUPS 3.x at any time, and also, CUPS 2.x already supports IPP print destinations without permanent CUPS queue, so also for CUPS 2.x users modern, driverless printers will just appear and they do not try to unnecessarily create queues for them. + +As system-config-printer is written in Python, we will use the new Python bindings for [libcups3](https://github.com/OpenPrinting/libcups), as [Soumyadeep Ghosh has created them in GSoC 2025](https://soumyadghosh.github.io/website/interns/gsoc-2025/gsoc-final-submission). + +There was already some work on system-config-printer to bring it towards CUPS 3.x in [GSoC 2024](https://github.com/TheJayas/GSoC-2024-Final-Report). This work could perhaps give some inspirations, but here we want system-config-printer use the new pyCUPS now, for optimization and minimization of code duplication. +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), Soumyadeep Ghosh, creator of the Python bindings for libcups3 (soumyadeepghosh2004 at zohomail dot in), Zdenek Dohnal, Printing Maintainer at Red Hat (zdohnal at redhat dot com), TBD +### Desired knowledge + Python, C, CUPS +### Code License + GPL-2+ (GPL 2 or any later version) diff --git a/_gsoc2026/02-COSMIC-Desktop.md b/_gsoc2026/02-COSMIC-Desktop.md new file mode 100644 index 00000000..bf733d9b --- /dev/null +++ b/_gsoc2026/02-COSMIC-Desktop.md @@ -0,0 +1,29 @@ +--- +title: "COSMIC Desktop: Printer setup tool and print dialog" +--- +### Introduction +2 (perhaps 3) contributors full-size (350 hours), Level of difficulty: Hard + +[COSMIC](https://system76.com/cosmic) is a desktop environment completely written in Rust. Rust is memory-safe and with this we expect much more stability and robustness, and less potential security vulnerabilities. + +COSMIC as the standard desktop of the [Pop!_OS](https://pop.system76.com/) operating system which comes on [System 76](https://system76.com/) laptops. It is meant as a complete, feature-rich desktop, like KDE and GNOME are. and its development is happening really quickly (but one needs to take into account that it gets the momentum of a hardware vendor). + +As COSMIC seems to want to be the third "big player" with KDE and GNOME, it will also need solid printing support, and for this OpenPrinting is working together with the COSMIC developers at System 76. + +First, we need a printer setup tool. as in GNOME and KDE it will most probably be embedded in the settings application, as one of its modules. It will need to support CUPS 3.x right from the beginning, as it does not take long any more to the first stable release of the new CUPS. This means, that we need to show IPP print destinations in the main view, grouped by the hardware device they come from, and with buttons to open the device's web admin interfaces. The "Add printer" part has to find non-driverless (legacy or specialty) printers and associate Printer Applications to them. + +Second, we need a print dialog, to be used by desktop applications written in Rust, using libcosmic and also for the print dialog to be popped up by the desktop when an app prints through the XDG Desktop Portal. This dialog should use the Common Print Dialog Backends (CPDB), so that it does not need to be changed on future changes in CUPS or when some cloud printing service gets available. + +One contributor will work on the print dialog and another on the printer setup tool. For the latter we can also have 2 contributors, one of the main view and the other on the "Add Printer" part. + +The contributors will be guided by developers and designers from System 76 to get the correct, streamlined GUI for COSMIC and by mentors from OpenPrinting for the CUPS and CPDB end. + +The whole software is to be written in Rust, to integrate in COSMIC which is by itself written in Rust. + +Rust bindings for the needed OpenPrinting libraries are already in place, written in last year's GSoC: [libcups](https://github.com/Gmin2/cups-rs), [cpdb-libs](https://github.com/TitikshaBansal/cpdb-rs) +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), Michael Murphy, COSMIC developer at System 76 (michael at mmurphy dot dev), Mintu Gogoi, creator of the Rust bindings for libcups (mintugogoi567 at gmail dot com), Titiksha Bansal, creator of the Rust bindings for cpdb-libs (titikshabansal0209 at gmail dot com), COSMIC developers TBD +### Desired knowledge + Rust, CUPS, desktop programming +### Code License + GPL-3+ (GPL 3 or any later version) diff --git a/_gsoc2026/03-KDE-Print-Manager.md b/_gsoc2026/03-KDE-Print-Manager.md new file mode 100644 index 00000000..9ef78bff --- /dev/null +++ b/_gsoc2026/03-KDE-Print-Manager.md @@ -0,0 +1,13 @@ +--- +title: "KDE Print Manager: Completing CUPS 3.x support and Printer Application integration" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Hard + +This project focuses on finishing the remaining CUPS 3.x–related work for KDE printer manager by refining IPP print destination handling, improving grouping and presentation of driverless printers, and completing integration of Printer Applications. The “Add Printer” workflow will be extended to prefer Printer Applications while still supporting legacy PPD-based printers where required. The project will also improve UI consistency for mixed environments with classic CUPS queues and IPP destinations. Finally, missing automated tests related to CUPS 3.x, IPP destinations, and Printer Applications will be added and integrated into CI to ensure long-term stability. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Mike Noe (noeerover at gmail dot com), KDE developers, TBD +### Desired knowledge + C/C++, KDE/Qt, UI Design +### Code License + GPL 2.0 or later and LGPL 2.0 or later diff --git a/_gsoc2026/04-AI-Driven-Printer-Compatibility-and-Recommendation-Portal.md b/_gsoc2026/04-AI-Driven-Printer-Compatibility-and-Recommendation-Portal.md new file mode 100644 index 00000000..bef41658 --- /dev/null +++ b/_gsoc2026/04-AI-Driven-Printer-Compatibility-and-Recommendation-Portal.md @@ -0,0 +1,29 @@ +--- +title: "AI-Driven Printer Compatibility and Recommendation Portal: Printer Data Intelligence & ML Pipeline" +--- +### Introduction +**AI/ML-related project** + +1 contributor, large-size (350 hours), Level of difficulty: Hard + +OpenPrinting maintains large and continuously evolving datasets such as the [Foomatic printer database](https://www.openprinting.org/printers/) and [driverless printer support](https://openprinting.github.io/printers/) lists. While these datasets are rich in information, they are currently consumed as static listings, requiring users to manually reason about printer compatibility, feature equivalence, and suitable alternatives. As the number of supported printers continues to grow, this approach becomes increasingly difficult to maintain and use effectively. + +The objective of this project is to design and implement an **offline, reproducible machine-learning pipeline** that transforms OpenPrinting’s printer metadata into structured, actionable intelligence suitable for downstream web applications. + +The contributor will build a robust data ingestion and normalization layer that extracts and unifies printer attributes such as manufacturer, model family, supported protocols (IPP Everywhere, AirPrint, USB, etc.), color capability, duplex support, scanning features, and known limitations. Using this processed dataset, the contributor will implement machine-learning techniques—such as vectorization, similarity scoring, clustering, or lightweight embedding models—to identify relationships between printers and generate compatibility and equivalence recommendations. + +All model training and inference will be performed **offline**, and the outputs will be exported as static, versioned artifacts (e.g., JSON). These artifacts will be designed for direct consumption by static web pages, eliminating the need for server-side infrastructure. The contributor will also automate the entire pipeline using GitHub Actions so that the data and recommendations are periodically refreshed as printer metadata changes. + +Expected Outcomes & Deliverables + * A unified and normalized printer metadata dataset derived from OpenPrinting sources + * A fully documented offline ML pipeline for printer similarity and compatibility analysis + * Static, versioned recommendation artifacts suitable for static-site consumption + * Automated GitHub Actions workflows for scheduled data refresh and retraining + * Developer documentation describing data formats, retraining procedures, and extensibility +### Mentors + Rudra Pratap Singh (rudransh dot iitm at gmail dot com) +Till Kamppeter, organization lead OpenPrinting (till at linux dot com) + +Desired Knowledge: Python, Data Engineering (pandas, numpy), ML fundamentals, GitHub Actions. +### Code License + Apache 2.0 diff --git a/_gsoc2026/05-AI-Driven-Printer-Compatibility-and-Recommendation-Portal.md b/_gsoc2026/05-AI-Driven-Printer-Compatibility-and-Recommendation-Portal.md new file mode 100644 index 00000000..f76f7b26 --- /dev/null +++ b/_gsoc2026/05-AI-Driven-Printer-Compatibility-and-Recommendation-Portal.md @@ -0,0 +1,29 @@ +--- +title: "AI-Driven Printer Compatibility and Recommendation Portal: Intelligent Printer Discovery & Recommendation Web Interface" +--- +### Introduction +**AI/ML-related project** + +1 contributor, large-size (350 hours), Level of difficulty: Intermediate–Hard + +Although OpenPrinting hosts authoritative printer compatibility data, users currently interact with it through static tables and listings. This makes discovering compatible printers or identifying suitable alternatives unnecessarily difficult, especially for non-expert users or first-time Linux adopters. + +The objective of this project is to design and implement a **feature-rich, client-side recommendation interface** on `openprinting.github.io` that enables intuitive exploration of printer compatibility data and ML-generated recommendations. + +The contributor will build a modern, accessible web interface that consumes the static ML artifacts generated by Track A. The interface will allow users to search printers by name, filter by functional requirements (e.g., color, duplex, scanning), and explore recommended alternatives or equivalent models. The system should also present transparent explanations for recommendations, helping users understand why a printer is suggested. + +All functionality must operate entirely in the browser using JavaScript and static assets, without relying on backend services. As a large project, this track includes advanced UX work, data visualization, performance optimization for large datasets, and optional enhancements such as client-side free-text queries using lightweight browser ML runtimes. + +Expected Outcomes & Deliverables + * A comprehensive printer discovery and recommendation interface integrated into `openprinting.github.io` + * Client-side logic for ranking, filtering, and visualizing recommendations + * Accessible, responsive UI design suitable for a wide range of users + * Performance optimizations for large static datasets + * Documentation for maintainers and contributors on extending the interface +### Mentors + Rudra Pratap Singh (rudransh dot iitm at gmail dot com) +Till Kamppeter, organization lead OpenPrinting (till at linux dot com) + +Desired Knowledge: JavaScript, ReactJS/NextJS, static site development (GitHub Pages), data visualization, UX design principles. +### Code License + Apache 2.0 diff --git a/_gsoc2026/06-Automated-and-LLM-Assisted-Fuzz-Harness-Generation-for-OpenPrinting-Projects.md b/_gsoc2026/06-Automated-and-LLM-Assisted-Fuzz-Harness-Generation-for-OpenPrinting-Projects.md new file mode 100644 index 00000000..59b57945 --- /dev/null +++ b/_gsoc2026/06-Automated-and-LLM-Assisted-Fuzz-Harness-Generation-for-OpenPrinting-Projects.md @@ -0,0 +1,44 @@ +--- +title: "Automated and LLM-Assisted Fuzz Harness Generation for OpenPrinting Projects" +--- +### Introduction +**Security- and AI-related project** + +1 contributor, large-size (350 hours), Level of difficulty: Hard + +**Background** + +OpenPrinting maintains a set of widely deployed printing-related open-source projects, most of which are written in C/C++ and therefore prone to memory safety vulnerabilities. Recent CVEs in OpenPrinting components highlight the need for systematic, scalable, and automated fuzz testing to improve software security and robustness. + +OpenPrinting has actively collaborated with Google OSS-Fuzz, integrating multiple core projects (cups, libcups, cups-filters, libcupsfilters, cups-browsed) and fixing dozens of critical bugs. However, due to the size and complexity of the ecosystem, manual fuzz harness development does not scale, and coverage remains insufficient for many critical code paths. + +Building on last year’s GSoC work, OpenPrinting now has an experimental LLM-assisted fuzz harness generation framework, light-fuzz-gen (), which demonstrates the feasibility of automatically generating and refining fuzz harnesses for complex C/C++ codebases. + +Despite existing OSS-Fuzz integrations, OpenPrinting still faces several challenges: + * Fuzz harness creation remains labor-intensive and expert-driven + * Many code paths are hard to reach with traditional manually written harnesses + * Existing fuzz setups lack automation for continuous harness generation, refinement, and coverage feedback + * Scaling fuzz testing to more OpenPrinting projects is difficult without stronger automation + +To address these challenges, OpenPrinting aims to further develop and apply automated, LLM-assisted fuzz testing techniques to systematically improve fuzz coverage and bug discovery across its ecosystem. For this year's GSoC, the primary goal of this project is to advance automated fuzz testing for OpenPrinting projects by extending light-fuzz-gen and related techniques. + +Specific objectives include: + + * Extending light-fuzz-gen + * Improve the robustness and generality of the existing framework + * Support more complex C/C++ APIs and project layouts + * Enhance prompt strategies and harness templates for better coverage + * Automated Fuzz Harness Generation + * Automatically generate new fuzz harnesses for additional OpenPrinting projects + * Target high-risk, security-sensitive, and previously under-tested components + * Reduce manual effort in harness creation + * Coverage-Guided Improvement + * Integrate coverage feedback to iteratively refine generated harnesses + * Compare coverage and bug-finding effectiveness with existing manual harnesses + * Bug Discovery and Fixing +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), Zixuan Liu (pushinliu at gmail dot com) + +Desired Knowledge: C/C++ programming, software testing (fuzzing), optional experience with AFL++, libFuzzer, or similar tools, familiarity with containerization (Docker), interest in software security and systems programming +### Code License + Apache 2.0, MIT (depending on the OpenPrinting project) diff --git a/_gsoc2026/07-System-Level-Fuzzing-for-Parsing-Features-in-OpenPrinting-Projects.md b/_gsoc2026/07-System-Level-Fuzzing-for-Parsing-Features-in-OpenPrinting-Projects.md new file mode 100644 index 00000000..f866c6d8 --- /dev/null +++ b/_gsoc2026/07-System-Level-Fuzzing-for-Parsing-Features-in-OpenPrinting-Projects.md @@ -0,0 +1,43 @@ +--- +title: "System-Level Fuzzing for Parsing Features in OpenPrinting Projects" +--- +### Introduction +**Security-related project** + +1 contributor, large-size (350 hours), Level of difficulty: Hard + +**Description** + +OpenPrinting projects such as cups-filters and libcupsfilters contain extensive and complex media parsing code, responsible for handling diverse input formats (e.g., PDF, raster, images). While these components are critical for system stability and security, existing fuzzers currently exercise only a small subset of their functionality, leaving many parsing paths untested. Detailed issue can be referred here: . + +This project proposes building a system-level fuzzing infrastructure that feeds raw media files directly into cups-filters tools or filter pipelines, instead of relying solely on narrow, function-level fuzz harnesses. Using modern coverage-guided fuzzers such as AFL++, the project aims to significantly expand code coverage, uncover new crashes and vulnerabilities, and improve the overall robustness of OpenPrinting’s media processing stack. + +**Project Goals** + +The primary goal of this project is to design, implement, and maintain a system fuzzing setup for OpenPrinting projects, with a strong focus on media parsing paths. + +Specific objectives include: + + * System Fuzzing Infrastructure + * Create a dedicated system fuzzing repository or branch for OpenPrinting projects + * Enable fuzzing of cups-filters tools and pipelines using raw media files as input + * Ensure reproducible and automated builds (e.g., container-based workflows) + * Seed Corpus Design + * Collect and curate high-quality seed inputs, including: + * Valid media files + * Regression inputs from past crashes and CVEs + * Structure corpora to maximize reachable parsing paths + * Coverage Expansion + * Use coverage-guided fuzzing to exercise parsing logic that is currently untested + * Analyze and document coverage improvements compared to existing fuzzers + * Bug Discovery and Fixing + +**Expected Outcomes** + +By the end of the project, the contributor is expected to deliver: (1) A maintained system fuzzing setup for OpenPrinting projects, which should improve coverage of media parsing code (2) Newly discovered and responsibly fixed bugs (3) A reusable framework for future system-level fuzzing efforts in OpenPrinting. +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate, Singapore Management University (jiongchiyu at gmail dot com), Günther Noack (gnoack at google dot com) + +Desired Knowledge: C/C++ programming, software testing (fuzzing), optional experience with AFL++, libFuzzer, or similar tools, familiarity with containerization (Docker), interest in software security and systems programming +### Code License + Apache 2.0, MIT (depending on the OpenPrinting project) diff --git a/_gsoc2026/08-Fuzz-Test-go-cpython.md b/_gsoc2026/08-Fuzz-Test-go-cpython.md new file mode 100644 index 00000000..94e21769 --- /dev/null +++ b/_gsoc2026/08-Fuzz-Test-go-cpython.md @@ -0,0 +1,27 @@ +--- +title: "Fuzz/Test go-cpython" +--- +### Introduction +**Security-related project** + +1 contributor, large-size (350 hours), Level of difficulty: Intermediate + +The [go-mfp](https://github.com/OpenPrinting/go-mfp) project includes its own implementation of a CPython binding for Go, which enables Python scripting to be embedded into Go programs. + +While other bindings exist, this implementation offers several unique features: + + * It utilizes the host Python installation and is highly tolerant to Python version upgrades, even for compiled binaries, greatly simplifying deployment. + * It provides a simple API for using multiple independent, isolated virtual Python interpreters (known as sub-interpreters) within the same process. + * Python objects (values) on the Go side are automatically garbage-collected, eliminating the need for manual memory management. + +Currently, this package is part of the go-mfp project, but due to its independence and broader utility, it is planned to be moved into a separate repository — similar to what happened with go-avahi. Once this occurs, OpenPrinting will maintain its own official Go-to-CPython binding. + +Should this package attract community interest after the move, it could be widely adopted as a generic embedded scripting engine across many applications, potentially becoming part of critical Linux infrastructure. At that stage, ensuring the absence of serious bugs and vulnerabilities will be essential. + +The goal of this project is to fuzz and test the package, as has been done with go-avahi. Given that the CPython interpreter internals can change significantly even between minor versions, it is important to conduct this testing across a range of Python versions, from 3.8 up to the latest available. +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate, Singapore Management University (jiongchiyu at gmail dot com), TBD + +Desired Knowledge: Programming in C and Go, Fuzz testing +### Code License + BSD 2-Clause "Simplified" License diff --git a/_gsoc2026/09-Extend-PDFio-to-be-a-PDF-renderer-displayer.md b/_gsoc2026/09-Extend-PDFio-to-be-a-PDF-renderer-displayer.md new file mode 100644 index 00000000..50903467 --- /dev/null +++ b/_gsoc2026/09-Extend-PDFio-to-be-a-PDF-renderer-displayer.md @@ -0,0 +1,13 @@ +--- +title: "Extend PDFio to be a PDF renderer/displayer" +--- +### Introduction +1 contributor large-size (350 hours), Level of difficulty: Hard + +To avoid binary compatibility issues of C++, and more importantly, there are no PDF renderers with fully permissive licensing. This project's aim is to develop a PDF rasterization engine in pure C that utilizes [PDFio](https://github.com/michaelrsweet/pdfio) for parsing and Cairo as the rendering engine. It is primarily for use as a print filter to be used with CUPS and Printer Applications. A simple screen viewer for development and debugging should also be included. +### Mentors + Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Ira McDonald (blueroofmusic at gmail dot com), TBD +### Desired knowledge + C, CUPS +### Code License + Apache 2.0 diff --git a/_gsoc2026/10-Porting-OpenPrinting-Software-to-Zephyr.md b/_gsoc2026/10-Porting-OpenPrinting-Software-to-Zephyr.md new file mode 100644 index 00000000..5d6e446b --- /dev/null +++ b/_gsoc2026/10-Porting-OpenPrinting-Software-to-Zephyr.md @@ -0,0 +1,17 @@ +--- +title: "Porting OpenPrinting Software to Zephyr" +--- +### Introduction +1 contributor, large-size (350 hours), Level of difficulty: Intermediate + +As printers move further toward driverless IPP Everywhere printing, OpenPrinting’s printing software stands at the forefront of this movement, enabling various driverless print servers. However, for such a print server to be integrated directly within and/or sold with a printer while keeping costs low, a suitable low-power, low-form-factor platform to run the server is needed. This places the system in the realm of embedded systems, where real-time operating systems (RTOSes) are preferred for their reliability for time-critical tasks. However, full-fledged print servers are currently only supported on general-purpose operating systems (GPOSes) such as Linux, which many embedded microcontroller and some system-on-chip (SoC)-based platforms do not support. + +This project aims to address this issue by continuing the porting of the OpenPrinting printing stack, including libraries like libcups and parts of PAPPL, as well as applications such as PAPPL and CUPS, to Zephyr, a major open-source RTOS. Furthermore, details on hardware requirements, IPP-over-USB communication with printers, and software changes should be investigated. + +This project is the continuation of [Hubert Guan's GSoC 2025 project](https://hubertyguan.github.io/GSoC-2025/posts/final/). +### Mentors + Iuliana Prodan (iuliana dot prodan at gmail dot com), Hubert Guan (hubertyguan at gmail dot com), Akarshan Kapoor (akarshankap at gmail dot com), Till Kamppeter, organization lead OpenPrinting (till at linux dot com), Zephyr developers TBD + +Desired Knowledge: C programming (Rust is also desirable), real-time operating systems (especially Zephyr) and embedded systems, familiarity with networking concepts, especially DNSSD and TLS, is recommended, familiarity with version control systems, including Git +### Code License + Apache 2.0, MIT (licenses of the OpenPrinting projects) diff --git a/_gsoc2026/11-Build-a-Full-Print-System-Testing-Pipeline.md b/_gsoc2026/11-Build-a-Full-Print-System-Testing-Pipeline.md new file mode 100644 index 00000000..2be0a4f6 --- /dev/null +++ b/_gsoc2026/11-Build-a-Full-Print-System-Testing-Pipeline.md @@ -0,0 +1,36 @@ +--- +title: "Build a Full Print System Testing Pipeline" +--- +### Introduction +1 contributor, large-size (350 hours), Level of difficulty: Hard + +We currently have a [printer simulator](https://github.com/OpenPrinting/go-mfp) (still a work in progress, but already functional for many tests) and an [image evaluation framework](https://github.com/Sanskary2303/OpenPrinting-Image-Evaluation), both created as part of a GSoC 2025 project. + +The missing piece is integrating them into a complete system. + +The goal of this project is to build a tool capable of performing the following tasks: + + 1. Load a simulation model of the printer + 2. Automatically create a CUPS print queue based on that model + 3. Instantiate a simulator + 4. Test printing in all modes supported by the printer (duplex/simplex, color/monochrome, various DPI settings, etc.) + 5. Capture printed documents from the simulator + 6. Use the image evaluation framework to verify that the resulting document matches expectations + +The tool should be able to run tests in both single-test and batch modes to support automated regression testing. + +An interesting aspect of this project is the choice of programming language for the main procedure. + +The simulator itself is written in Go, and most of its functionality is available as Go libraries (packages), with some simple command-line utilities built on top of them—these mainly add a command-line interface. Therefore, creating and controlling an MFP simulator instance would likely be simpler if done directly in Go, using the same libraries, rather than by invoking external command-line tools. + +However, the image evaluation framework is written in Python. + +Fortunately, we already use an embedded Python interpreter, which means we can write a Go program that implements and controls the simulation directly while running image evaluation scripts within the embedded Python interpreter. + +An alternative would be to write the main program in Python. In that case, we would need to design a method to instantiate and use the simulator from within the Python script. +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), TBD + +Desired Knowledge: Programming in Go and Python +### Code License + BSD 2-Clause "Simplified" License diff --git a/_gsoc2026/12-Validation-of-the-IANA-IPP-Registrations-Database.md b/_gsoc2026/12-Validation-of-the-IANA-IPP-Registrations-Database.md new file mode 100644 index 00000000..c702d831 --- /dev/null +++ b/_gsoc2026/12-Validation-of-the-IANA-IPP-Registrations-Database.md @@ -0,0 +1,82 @@ +--- +title: "Validation of the IANA IPP Registrations Database" +--- +### Introduction +1 contributor, large-size (350 hours), Level of difficulty: Intermediate + +IANA maintains the IPP protocol registrations database. This database contains formal definitions of all standard IPP attributes, including their groupings, names, syntax, and standard values for enumerations and keywords. + +The database is available in a machine-readable format (a large XML file) and can be downloaded from the IANA website: + + + +The go-mfp project uses this database as its source of knowledge about IPP attributes. + +The database is very comprehensive (containing over 1,600 attributes) and largely accurate. + +However, it still contains some errors. For example: + +1. Job Template/stitching/stitching-method(extension): Broken syntax. + +``` +Currently: type2 keyword] (note the stray ']' character at the end) +Correct: type2 keyword +``` + +2. System Status/system-config-changes: Broken syntax. + +``` +Currently: integer:0:MAX +Correct: integer(0:MAX) +``` + +3. Operation/client-patches: Unnecessary apostrophes in syntax. + +``` +Currently: text(255) | 'no-value' +Correct: text(255) | no-value +``` + +4. Document Status/imposition-template-actual: Missing parentheses in syntax. + +``` +Currently: 1setOf type2 keyword | name +Correct: 1setOf type2 (keyword | name) +``` + +5. Job Status/force-front-side-actual: Duplicated 1setOf keyword. + +``` +Currently: 1setOf (1setOf integer(1:MAX)) +Correct: 1setOf integer(1:MAX) +``` + +Note 1: `1setOf` cannot be nested. + +Note 2: The same error exists in the `PWG-5100.8.pdf` standard document. + +6. Job Template/job-accounting-sheets(deprecated): Missing member definitions. + +7. Ambiguous collection references: Many attributes use syntax like . This is a reference to another collection where these attributes are defined. However, the reference to the "cover-back" collection is ambiguous because it is defined in both the Job Template and Document Template groups. This needs to be fixed, or disambiguation rules must be specified. The same applies to references to "cover-front", "finishings-col", etc. + +8. Missing collection references: Sometimes, a reference to another collection is missing entirely, which makes a collection appear to have no members. Examples: Document Status/document-format-details(deprecated), Job Status/document-format-details-supplied. + +9. Obsolete collections: Some obsolete collections are present (without members) in the registration database, but due to their obsolescence, their specifications cannot be located. Example: Document Template/pdl-init-file(obsolete). + +10. Job Template/finishings-col(extension) shadows Job Template/finishings-col and contains no member attributes. + +This list is not exhaustive and is provided only as an example. A more comprehensive list can be found here: + + + +The goal of this project is to develop a tool that validates the IANA IPP registration database for formal consistency and to collaborate with the IETF PWG group (e.g., M. Sweet) on reporting and fixing the identified issues. + +The full validation of the database against relevant specification is the giant work and out of scope of this project. However, sometimes this is still required to look to the specification, so ability to read standards and specifications is required. + +An ideal side product of this project would be a generic parser for the IANA IPP registration database, implemented as a reusable library. +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), TBD + +Desired Knowledge: Programming in at least one of C or Go, reading standards and specifications. +### Code License + BSD 2-Clause "Simplified" License diff --git a/_gsoc2026/13-Cloud-Native-Packaging-for-CUPS-and-Printer-Applications.md b/_gsoc2026/13-Cloud-Native-Packaging-for-CUPS-and-Printer-Applications.md new file mode 100644 index 00000000..1edc3dcd --- /dev/null +++ b/_gsoc2026/13-Cloud-Native-Packaging-for-CUPS-and-Printer-Applications.md @@ -0,0 +1,36 @@ +--- +title: "Cloud-Native Packaging for CUPS and Printer Applications" +--- +### Introduction +​ +1 contributor, large-size (350 hours), Level of difficulty: Intermediate + +**Summary​** + +Package OpenPrinting’s CUPS and Printer Applications for use on​​ **cloud-native and immutable Linux systems​** ​using​​ **OCI container technology​**. Evaluate existing container-based packaging and refine it where necessary to​ ensure compliance with cloud-native requirements.​ + +**Details​** + +Modern Linux systems are increasingly adopting​​ **immutable and cloud-native designs**​, where traditional​ ​system-level package installation is not possible. In such environments, system services and daemons such as​ ​**CUPS and Printer Applications​​** must be deployed using​​ **container-based​​ approaches​**.​ + +For immutable desktop systems, system components are part of the immutable OS image and additional services​ ​must be provided as **​​OCI containers**​. On cloud-native servers, CUPS is often not installed at all and must be​ deployed as a containerized service.​ + +Previous GSoC work has produced OCI/Docker containers for CUPS and OpenPrinting Printer Applications. It is​ ​currently unclear whether these containers fully meet​​ **cloud-native criteria**​, or whether changes are required to their​ ​build process, configuration, or runtime behavior.​ + +This project will evaluate the existing containers, determine whether they already qualify as cloud-native, and improve​ ​them where necessary. Printing workflows on immutable desktop systems will also be validated, including printing​ ​from sandboxed desktop applications via the XDG Desktop Portal.​ + +**Deliverables​** + + * Cloud-native OCI container images for CUPS​ + * Cloud-native OCI container images for OpenPrinting Printer Applications​ + * Evaluation of existing container build approaches and identification of required changes​ + * Optional use of alternative build systems (e.g. Rockcraft) where beneficial​ + * Deployment examples for container-based and orchestrated environments​ + * Documentation for users and administrators​ + * Final project report​ +### Mentors + Kyle Yu (ydz627 at gmail dot com), Mohammad Ali (aerabi at gmx dot de), Sonali Srivastava (srivastava dot sonali1 at gmail dot com), Till Kamppeter, organization lead OpenPrinting (till at linux dot com), CNCF/cloud-native developers TBD +### Desired knowledge + Experience with containers and cloud-native technologies​, familiarity with Linux system services and daemons​​, basic understanding of CUPS/IPP (or willingness to learn)​, shell scripting and Git​, optional Kubernetes or container orchestration experience​, knowledge of immutable Linux distributions​, ​experience with container build tools​ +### Code License + Apache 2.0 diff --git a/_gsoc2026/14-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md b/_gsoc2026/14-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md new file mode 100644 index 00000000..0ead1573 --- /dev/null +++ b/_gsoc2026/14-CI-Testing-programs-for-libpappl-retrofit-and-libppd.md @@ -0,0 +1,27 @@ +--- +title: "CI Testing programs for libpappl-retrofit and libppd" +--- +### Introduction +1 contributor full-size (350 hours), Level of difficulty: Intermediate + +To protect a free software project worked on by several contributors against regressions caused by a committed change, one needs frequent, automated testing of the code, base, ideally triggered by every commit into the repository. This is called Continuous Integration (CI). + +What is triggered on each commit is usually some static analysis of the code using common, specialized tools and also build and execution tests, usually doing `./configure; make; make test` on different system platforms. + +This naturally requires test scripts/programs which are compiled and run by the `make test` step. For CUPS for example the daemon is started (on an unprivileged port so that it does not need root), queues created and listed, jobs sent, the logs checked whether everything went OK, ... For Ghostscript a large collection of input files (gathered from bug reports) is processed and converted into raster formats. + +The contributor's task here is to write test programs for the OpenPrinting projects libppd and pappl-retrofit so that `make test` does something useful, being efficient to catch regressions. They should exercise important functionality of the software with different parameters and analyse logs and output files to check whether the program did the expected work. + +Test programs are also needed for the so-called 'autopkgtest' tests which are added to Debian packages and executed whenever the package is uploaded to Debian or Ubuntu. + +In addition, instruction files and shell scripts are needed to build the software on different platforms/environments, run tests, create GitHub Actions (for the automatic triggering on each commit ...). + +This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: ([Summary](https://openprinting.github.io/OpenPrinting-News-September-2022/#openprinting-micro-conference-on-the-linux-plumbers-2022), [Slides](https://lpc.events/event/16/contributions/1161/attachments/942/1851/lpc-printing-ci-2022.pdf), [Video](https://www.youtube.com/watch?v=c--Uki7cvGE)) + +Here you can see what we already have in terms of CI, and what is missing ... +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), TBD +### Desired knowledge + C, Shell, PAPPL, CUPS, CI +### Code License + Apache 2.0 diff --git a/_gsoc2026/15-cups-filters.md b/_gsoc2026/15-cups-filters.md new file mode 100644 index 00000000..d4edad9d --- /dev/null +++ b/_gsoc2026/15-cups-filters.md @@ -0,0 +1,19 @@ +--- +title: "cups-filters: Create OCR filter to deliver scans as searchable PDFs" +--- +### Introduction +1 contributor medium-size (175 hrs), Level of difficulty: Intermediate + +Scanning with IPP Scan gives the user the possibility to request the scanned image in PDF format. If the IPP Scan server is a Scanner Application, a filter function from cups-filters would convert the the raster image coming from the scanner into PDF. + +Now such PDF files are simply raster images in a PDF frame, not high-level graphics with text and fonts, as PDFs produced by office applications are. Especially one cannot search text in a PDF coming from a scanning process. + +Ghostscript has a new "pdfocr8" device with which Ghostscript takes raster graphics PDFs (or PostScript files) as input, applies OCR (Optical Character Recognition) to the raster image, and creates a PDF which contains the raster image to visually show the scan but adds data about the contained text and where it is located, so that you can find text with the search facility of a PDF viewer. + +Here the contributor's task is to write a filter function (or extend the `cfFilterGhostscript()` filter function) to make the "pdfocr8" output device of Ghostscript being used so that a searchable PDF is obtained. +### Mentors + Till Kamppeter, organization lead OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD +### Desired knowledge + C/C++, CUPS +### Code License + Apache 2.0 diff --git a/_includes/nav_list b/_includes/nav_list index e2beab50..e41e33c1 100644 --- a/_includes/nav_list +++ b/_includes/nav_list @@ -38,7 +38,7 @@ {% endif %}

  • - {{ child.title }} + {{ child.title }}

    • {% endfor %} diff --git a/_pages/gsoc.md b/_pages/gsoc.md index 7ee0d534..77bf5ce0 100644 --- a/_pages/gsoc.md +++ b/_pages/gsoc.md @@ -5,14 +5,24 @@ permalink: /gsoc/ ## Year-Wise GSoC Project List -### 1. [GSOC 2021](/gsoc2021/) +### 1. [GSOC 2026](/gsoc2026/) -### 2. [GSOC 2020](/gsoc2020/) +### 2. [GSOC 2025](/gsoc2025/) -### 3. [GSOC 2019](/gsoc2019/) +### 3. [GSOC 2024](/gsoc2024/) + +### 4. [GSOC 2023](/gsoc2023/) + +### 5. [GSOC 2022](/gsoc2022/) + +### 6. [GSOC 2021](/gsoc2021/) + +### 7. [GSOC 2020](/gsoc2020/) + +### 8. [GSOC 2019](/gsoc2019/) ## Year-Wise GSoC Students ### 1. [GSOC 2021](/gsoc-2021-students/) -### 2. [GSOC 2020](/gsoc-2020-students/) \ No newline at end of file +### 2. [GSOC 2020](/gsoc-2020-students/) diff --git a/_pages/gsoc2022.md b/_pages/gsoc2022.md new file mode 100644 index 00000000..9bf22a42 --- /dev/null +++ b/_pages/gsoc2022.md @@ -0,0 +1,59 @@ +--- +layout: collection +title: "GSoC 2022 Projects" +collection: gsoc2022 +permalink: /gsoc2022/ +author_profile: false +sidebar: + nav: "gsoc22" +--- + + +

    Contact

    +
    + +

    +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 +

    + +

    +OpenPrinting GitHub +

    + +

    +Code License: See project descriptions +

    + +
    + +

    Organization Administrators

    +
    + +

    +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. +

    + +

    Projects

    +
    + {% include documents-collection.html collection=page.collection sort_by=page.sort_by sort_order=page.sort_order type=page.entries_layout %} +
    diff --git a/_pages/gsoc2023.md b/_pages/gsoc2023.md new file mode 100644 index 00000000..1b0ce5a6 --- /dev/null +++ b/_pages/gsoc2023.md @@ -0,0 +1,59 @@ +--- +layout: collection +title: "GSoC 2023 Projects" +collection: gsoc2023 +permalink: /gsoc2023/ +author_profile: false +sidebar: + nav: "gsoc23" +--- + + +

    Contact

    +
    + +

    +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 +

    + +

    +OpenPrinting GitHub +

    + +

    +Code License: See project descriptions +

    + +
    + +

    Organization Administrators

    +
    + +

    +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. +

    + +

    Projects

    +
    + {% include documents-collection.html collection=page.collection sort_by=page.sort_by sort_order=page.sort_order type=page.entries_layout %} +
    diff --git a/_pages/gsoc2024.md b/_pages/gsoc2024.md new file mode 100644 index 00000000..3ea2c90c --- /dev/null +++ b/_pages/gsoc2024.md @@ -0,0 +1,59 @@ +--- +layout: collection +title: "GSoC 2024 Projects" +collection: gsoc2024 +permalink: /gsoc2024/ +author_profile: false +sidebar: + nav: "gsoc24" +--- + + +

    Contact

    +
    + +

    +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 +

    + +

    +OpenPrinting GitHub +

    + +

    +Code License: See project descriptions +

    + +
    + +

    Organization Administrators

    +
    + +

    +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. +

    + +

    Projects

    +
    + {% include documents-collection.html collection=page.collection sort_by=page.sort_by sort_order=page.sort_order type=page.entries_layout %} +
    diff --git a/_pages/gsoc2025.md b/_pages/gsoc2025.md new file mode 100644 index 00000000..9e4c84df --- /dev/null +++ b/_pages/gsoc2025.md @@ -0,0 +1,59 @@ +--- +layout: collection +title: "GSoC 2025 Projects" +collection: gsoc2025 +permalink: /gsoc2025/ +author_profile: false +sidebar: + nav: "gsoc25" +--- + + +

    Contact

    +
    + +

    +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 +

    + +

    +OpenPrinting GitHub +

    + +

    +Code License: See project descriptions +

    + +
    + +

    Organization Administrators

    +
    + +

    +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. +

    + +

    Projects

    +
    + {% include documents-collection.html collection=page.collection sort_by=page.sort_by sort_order=page.sort_order type=page.entries_layout %} +
    diff --git a/_pages/gsoc2026.md b/_pages/gsoc2026.md new file mode 100644 index 00000000..e1913fa9 --- /dev/null +++ b/_pages/gsoc2026.md @@ -0,0 +1,59 @@ +--- +layout: collection +title: "GSoC 2026 Projects" +collection: gsoc2026 +permalink: /gsoc2026/ +author_profile: false +sidebar: + nav: "gsoc26" +--- + + +

    Contact

    +
    + +

    +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 +

    + +

    +OpenPrinting GitHub +

    + +

    +Code License: See project descriptions +

    + +
    + +

    Organization Administrators

    +
    + +

    +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. +

    + +

    Projects

    +
    + {% include documents-collection.html collection=page.collection sort_by=page.sort_by sort_order=page.sort_order type=page.entries_layout %} +
    diff --git a/_pages/projects.md b/_pages/projects.md index 25e9a164..3b4f18d6 100644 --- a/_pages/projects.md +++ b/_pages/projects.md @@ -6,6 +6,6 @@ permalink: /projects/ author_profile: false --- -OpenPrinting is reponsible for development of many opensource printing projects. +OpenPrinting is responsible for development of many opensource printing projects. ## Project List diff --git a/_posts/2022-02-13-OpenPrinting News - February 2022.md b/_posts/2022-02-13-OpenPrinting News - February 2022.md index f9c3264b..af0f7f25 100644 --- a/_posts/2022-02-13-OpenPrinting News - February 2022.md +++ b/_posts/2022-02-13-OpenPrinting News - February 2022.md @@ -69,7 +69,7 @@ GUI toolkit projects are large projects, often with long release cycles and all An important part of the maintenance of a GUI toolkit is that it interfaces well and correctly with the underlying operating system, graphics, sound, storage, …, and printing! The OS is under continuous development, things are changing all the time, components get replaced by others, printing is CUPS for 22 years, but within CUPS we have also changes, and they need to be taken care of in the print dialogs. -Several years back, CUPS started to create temporary queues for driverless IPP network printers (or remote CUPS printers, which are emulations of IPP printers), which are only physically available when they are accessed (capabilities are polled or job printed). Print dialogs used an old API which did not support this, the temporary queues did not appear in the dialog, a helper daemon, cups-browsed had to convert the temporary queues into physical queues as a workaround. The correct solution had been to change the print dialogs to a newer CUPS API which supports these queues, but no one at the GUI toolkit projects has felt reponsible and taken the time for this update for many years. Only recently this got fixed. +Several years back, CUPS started to create temporary queues for driverless IPP network printers (or remote CUPS printers, which are emulations of IPP printers), which are only physically available when they are accessed (capabilities are polled or job printed). Print dialogs used an old API which did not support this, the temporary queues did not appear in the dialog, a helper daemon, cups-browsed had to convert the temporary queues into physical queues as a workaround. The correct solution had been to change the print dialogs to a newer CUPS API which supports these queues, but no one at the GUI toolkit projects has felt responsible and taken the time for this update for many years. Only recently this got fixed. This made me introducing the Common Print Dialog Backends (CPDB), a de-coupling of the print technology (CUPS, print-to-file, back in 2017 also Google Cloud Print) from the GUI. The GUI projects have to adopt the CPDB support only once and then OpenPrinting (or any upcoming cloud printing projects) takes care of the CPDB backend for the print technologies to be up-to-date with any changes. This way print technology projects can react quickly and are not dependent any more on the GUI toolkit’s inertia. diff --git a/assets/css/custom.css b/assets/css/custom.css index feddd097..4ff73bf0 100644 --- a/assets/css/custom.css +++ b/assets/css/custom.css @@ -3,18 +3,16 @@ width: 90%; } +html { + overflow-y: scroll; +} + .side-nav-li{ white-space: nowrap; overflow: hidden; text-overflow: ellipsis; word-break: break-all; } -.side-nav-li:hover{ - overflow:visible; - white-space: normal; - height: auto; - font-weight: bold; -} .nav__list{ } @@ -95,6 +93,10 @@ vertical-align: middle; } +.fa-fw { + color: #000 !important; +} + /* Dark mode overrides */ @media (prefers-color-scheme: dark) { body { @@ -174,4 +176,13 @@ .page__footer { color: #ccc !important; } + + .fa-fw { + color: #b0b0b0 !important; +} + .highlighter-rouge { + background-color: #fff4 !important; + color:#0ff !important; + } } +