OpenPrinting · tillkamppeter · Aug 12, 2026 · Aug 12, 2026 · Aug 12, 2026
diff --git a/contents/documentation/02-designing-printer-drivers.md b/contents/documentation/02-designing-printer-drivers.md
@@ -9,7 +9,7 @@ h_range: [1,2]
 
 <h2 id="introduction"> Introduction </h2>
 
-A driver is a code or data specific to a certain model or group of hardware devices, needed to make the hardware work with the hardware-model-independent code of the operating system. Printing in Linux has moved towards [Driverless Printing](https://openprinting.github.io/driverless), which means there is no need for any hardware-model-specific code or data. However, there are some problems with the current framework. For example, some printers(especially the old ones) that cannot handle IPP requests are devoid of driverless printing capability. Printer Applications help to address these issues. Kindly refer <a href="/documentation/01-printer-application">Printer Applications - A new way to print in Linux</a> to learn more about Printer Applications, its working and benefits.
+A driver is a code or data specific to a certain model or group of hardware devices, needed to make the hardware work with the hardware-model-independent code of the operating system. Printing in Linux has moved towards [Driverless Printing](/driverless), which means there is no need for any hardware-model-specific code or data. However, there are some problems with the current framework. For example, some printers(especially the old ones) that cannot handle IPP requests are devoid of driverless printing capability. Printer Applications help to address these issues. Kindly refer <a href="/documentation/01-printer-application">Printer Applications - A new way to print in Linux</a> to learn more about Printer Applications, its working and benefits.
 
 For Designing the Printer Application Driver, it would be a lot of re-inventing the wheel if everyone who wants to create a printer driver has to implement all things from scratch. Therefore Michael Sweet has developed <a href="https://github.com/michaelrsweet/pappl">PAPPL</a>, a library that provides all the common functionality which is required in every Printer Application.
 

diff --git a/...g-non-driverless-printers-and-finding-suitable-Printer-Applications-for-them.md b/...g-non-driverless-printers-and-finding-suitable-Printer-Applications-for-them.md
@@ -10,7 +10,7 @@ Modern printers usually are driverless IPP printers, and those get discovered an
 
 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.
+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](/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

diff --git a/...23/CI-Testing-programs-for-libcupsfilters-libpappl-retrofit-libppd-CPDB-etc-.md b/...23/CI-Testing-programs-for-libcupsfilters-libpappl-retrofit-libppd-CPDB-etc-.md
@@ -18,7 +18,7 @@ Test programs are also needed for the so-called 'autopkgtest' tests which are ad
 
 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))
+This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: ([Summary](/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

diff --git a/contents/gsoc/2024/CI-Testing-programs-for-libpappl-retrofit-and-libppd.md b/contents/gsoc/2024/CI-Testing-programs-for-libpappl-retrofit-and-libppd.md
@@ -18,7 +18,7 @@ Test programs are also needed for the so-called 'autopkgtest' tests which are ad
 
 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))
+This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: ([Summary](/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

diff --git a/...soc/2024/Replace-QPDF-by-PDFio-as-PDF-manipulation-library-in-libcupsfilters.md b/...soc/2024/Replace-QPDF-by-PDFio-as-PDF-manipulation-library-in-libcupsfilters.md
@@ -6,7 +6,7 @@ title: "Replace QPDF by PDFio as PDF manipulation library in libcupsfilters"
 
 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++`.
+Like [CUPS](/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().
 

diff --git a/contents/gsoc/2025/CI-Testing-programs-for-libpappl-retrofit-and-libppd.md b/contents/gsoc/2025/CI-Testing-programs-for-libpappl-retrofit-and-libppd.md
@@ -16,7 +16,7 @@ Test programs are also needed for the so-called 'autopkgtest' tests which are ad
 
 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))
+This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: ([Summary](/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

diff --git a/contents/gsoc/2025/Extend-PDFio-to-be-a-PDF-renderer-displayer.md b/contents/gsoc/2025/Extend-PDFio-to-be-a-PDF-renderer-displayer.md
@@ -4,7 +4,7 @@ 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++`.
+Like [CUPS](/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).
 

diff --git a/...s/gsoc/2025/Image-output-evaluation-for-testing-of-print-scan-job-processing.md b/...s/gsoc/2025/Image-output-evaluation-for-testing-of-print-scan-job-processing.md
@@ -14,7 +14,7 @@ To compare graphical content they use the free software computer vision library
 
 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".
+See also [my report from the GUADEC 2024](/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

diff --git a/contents/gsoc/2025/Port-CUPS-and-Printer-Applications-to-Zephyr.md b/contents/gsoc/2025/Port-CUPS-and-Printer-Applications-to-Zephyr.md
@@ -2,7 +2,7 @@
 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.
+Probably many of you have already thought about that one can take an SBC, install Linux and [CUPS](/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.
 
@@ -12,7 +12,7 @@ Such tiny boards are often not powerful enough to run Linux, but there is also t
 
 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?
+This project is about investigating whether one could run the components of the free software printing stack, as [CUPS](/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

diff --git a/...25/Port-pyCUPS-to-CUPS-3-x-API-apply-the-new-pyCUPS-to-system-config-printer.md b/...25/Port-pyCUPS-to-CUPS-3-x-API-apply-the-new-pyCUPS-to-system-config-printer.md
@@ -8,7 +8,7 @@ Most software with print functionality or print administration functionality use
 
 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.
+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](/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.
 

diff --git a/contents/gsoc/2025/Qt-Print-Dialog.md b/contents/gsoc/2025/Qt-Print-Dialog.md
@@ -6,9 +6,9 @@ title: "Qt Print Dialog: Modernize the user interface"
 
 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.
+Now, after the internals of the dialog being up-to-date (Support for the [Common Print Dialog Backends](/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.
+The modernization should at least be a UI similar to the one of the GTK print dialog. 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

diff --git a/contents/gsoc/2025/System-Fuzz-Testing-of-Printing-Protocols.md b/contents/gsoc/2025/System-Fuzz-Testing-of-Printing-Protocols.md
@@ -14,7 +14,7 @@ Effective testing of printing protocols and Domain-specific languages (DSL) like
 
 **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)
+  * 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](/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.*