Die 4 Lücken, die Open-Source-Druck schließt

Beim Open-Source-Druck wird diesmal das mittlere Stück zwischen Rechner und Gerät geschlossen – die Stelle, an der die Leitung am häufigsten reißt. OpenPrinting hat am 2026-07-26 elf Google Summer of Code 2026-Projekte veröffentlicht, die sich um CUPS 3.x, PDFio, CI, Fuzz-Testing, Drucker- und Scanner-Emulation sowie Local-ML-Driver-Lookup drehen

OpenPrinting (eine Gruppe von Open-Source-Druckprojekten, die als Unterorganisation der Linux Foundation am GSoC teilnimmt und die Linux/Unix-Druckwerkzeuge und -Daten pflegt) – diese Welle an Fortschritt übersetze ich in einen Satz aus dem Alltag: Findet der Rechner die Maschine, wird das PDF korrekt in druckbare Daten zerlegt, und geht nach einem Update auf der Kundenseite etwas kaputt

Google Summer of Code (Googles Open-Source-Programm, bei dem Beiträger unter Mentor-Begleitung Programmierprojekte umsetzen) wirkt meistens sehr technisch. Aber die Druck-Beschaffung muss auf die Risikostellen schauen. Druckprobleme sind selten an einem einzelnen Punkt kaputt – meist schieben sich Datei, Treiber, Betriebssystem und Geräte-Firmware gegenseitig die Verantwortung zu. Genau diese Verantwortungsgrenzen werden im Open-Source-Druck gerade geschlossen

CUPS 3.x wirkt sich auf die Beschaffung aus, weil es das Druckmanagement in Richtung IPP-Druckziele und Printer Applications schiebt; die Installationslogik der klassischen PPD-Treiber rückt allmählich in den Hintergrund

CUPS (Common Unix Printing System, das verbreitete Druck-System unter Unix/Linux, das Aufträge entgegennimmt, in die Warteschlange stellt, Optionen anwendet und weiterleitet) ist die Schaltzentrale vieler Linux-Druckabläufe. IPP (Internet Printing Protocol, der Netzwerk-Druck-Standard, mit dem Rechner Geräte finden, Fähigkeiten abfragen und Aufträge schicken) ist so etwas wie die gemeinsame Sprache, mit der Geräte miteinander reden

OpenPrinting weist darauf hin, dass der KDE Print Manager derzeit parallel CUPS 2.x und CUPS 3.x bedient und die Tests versionsabhängig aufgeteilt hat. Ein weiteres CI-Projekt nimmt libppd, libpappl-retrofit, libcupsfilters, cups-filters und cups-snap in automatisierte Tests auf und deckt CUPS 2.4.x, 2.5.x, 3.x/libcups3 sowie vier Architekturen ab

Bei der Beschaffung nicht nur fragen: „Kann es drucken?”. Lieber fragen: Unterstützt das Gerät Driverless-IPP, brauchen ältere Maschinen eine Printer Application, lässt sich der Status im Verwaltungs-Web sehen, und wer verifiziert das Ganze nach einem künftigen OS-Upgrade? Wenn diese vier Fragen durch sind, wird das Angebot sehr schnell still

Der PDF-Renderer schließt die Lücke, PDFs in Rasterdaten umzuwandeln, die das Gerät versteht. Fuzz-Testing schließt die Lücke, Programme mit kaputten, seltsamen und randständigen Dateien so lange zu traktieren, bis die Schwächen vorher auffliegen

PDFio (eine von Michael Sweet gepflegte PDF-Bibliothek, mit der Programme PDF-Strukturen lesen und schreiben können) wird gerade zum permissive-lizenzierten PDF-Renderer ausgebaut. Für Laien heißt das schlicht: Ein PDF sieht normal aus, heißt aber nicht, dass der Drucker die Schriften, Bilder, Seitenränder und Auflösung im PDF direkt versteht – der Renderer zerlegt das PDF in Pixeldaten und übergibt sie an das Gerät

Der PDFio-Renderer im Material unterstützt bereits Target-DPI-Scaling, Page-Boundary-Constraints und /XObject-Resource-Mapping; TrueType-Schriften aus /FontFile2 liest er mit FreeType, und bei defekten oder fehlenden Schriften fällt er auf DejaVuSans.ttf zurück. Wer in der Branche arbeitet, spürt hier sofort den Wermutstropfen: Wenn die Laufweiten kippen, sieht der Kunde keine technische Schuld, sondern einen schiefen Druck

Fuzz-Testing (eine Testmethode, die Programme mit massenhaft fehlerhaften Eingaben füttert, um Abstürze und Sicherheitslücken zu finden) schließt ebenfalls Risiken. Das cups-filters-Fuzzing-Projekt von OpenPrinting setzt AFL++, Honggfuzz und OSS-Fuzz-Gen ein und hat 1.079 Raw Crashes in 22 behandelbare Unique Clusters sortiert. Diese Art von Test ist nicht glamourös, kommt aber dem Druck-Alltag mit seinen merkwürdigen PDFs ziemlich nah

Ja, einen Teil des Druckablaufs kann man auch ohne echtes Gerät testen. Das go-mfp-Projekt von OpenPrinting verbindet gerade virtuelle Drucker, CUPS-Queues und Bildvergleich zu einem automatisiert laufenden Testablauf

CI (Continuous Integration, ein Ablauf, bei dem das Programm nach jeder Änderung automatisch gebaut und getestet wird) bedeutet für eine Druckerei schlicht: Vor einem Update das Ganze einmal automatisch durchlaufen lassen, statt zu warten, bis ein Eilauftrag des Kunden zeigt, dass die Queue hängt. Die Full-Print-System-Testing-Pipeline von OpenPrinting lädt ein Virtual-Printer-Modell, baut eine CUPS-Queue, listet die Print-Modes auf, schickt Print-Jobs los, nimmt die Ausgabe ab und vergleicht sie mit Bildmetriken wie SSIM und PSNR

go-mfp (das Go-Toolkit von OpenPrinting zum Emulieren und Testen von Multifunktionsdruckern) hat in Phase 1 drei Bugs im IPP-Attribute-Decoding behoben; in Phase 2 wird über eingebettetes CPython ein IPP-Server über TCP gestartet, mit lpadmin eine Queue registriert und mit lp eine Test-PNG losgeschickt. Ganz einfach: Erst in der Software stolpern lassen, dann geht die echte Linie nicht jedes Mal nur mit übernächtigten Meistern live

Auch die Scanner-Seite wird aufgefüllt. IPP-Scan ist der von der Printer Working Group in 5100.17 definierte Standard für Driverless Scanning over IPP; go-mfp von OpenPrinting baut gerade Client und Server ein. Für Firmen mit Scan-, Druck- und Archivierungsabläufen heißt das: „Scannen funktioniert” lässt sich künftig in derselben Abnahmesprache formulieren

Kleine und mittlere Druckereien sollten jetzt die Open-Source-Druck-Begriffe in eine Abnahme-Checkliste übersetzen – erst Kompatibilität managen, dann Tests, zuletzt die Verantwortung sauber schneiden

Ich nehme die „drei Tore von MINDS (MS, hochwertiger, voll individualisierter Geschäftsdruck) für die Druckannahme” für jedes neue Gerät oder jeden neuen Ablauf:

・① Datei-Tor: PDF-Seitenformat, Beschnitt, Schrifteinbettung, Auflösung und Farbmodus vorher prüfen

・② Geräte-Tor: Klären, ob das Gerät IPP unterstützt, ob es auf einer Printer Application läuft und ob sich der Status im Verwaltungs-Web abfragen lässt

・③ Test-Tor: Eine Standard-Testdatei parat halten und CUPS-Version, Treiber, Queue-Name und Fehlermeldungen dokumentieren

Bei hochwertigen Hochglanzbroschüren, Spezialpapieren oder Marken-Pitches lasse ich die Datei-Verantwortung am liebsten vorher bei MINDS klar abschneiden; für Visitenkarten, Sticker oder kleine DM-Mengen reicht es, bei 麥印刷 erst einmal die Spezifikationen sauber abzustimmen

Für Designer füllt Open-Source-Druck die Vorhersehbarkeit vor dem Druck. Für die Druckerei füllt Open-Source-Druck die gemeinsame Prüfsprache von IT und Produktion. Für die Beschaffung füllt Open-Source-Druck die Fähigkeit, Fragen zu stellen – nicht nur das Geräte-Datenblatt lesen, sondern nachweisen können, dass es nach einem Update noch zuverlässig Papier ausgibt

・Diese Welle im Open-Source-Druck schließt die Verantwortung in der Mitte: Geräte müssen auffindbar sein, Dateien müssen druckbar sein, Fehler müssen nachvollziehbar sein

・Die CUPS-3.x-Beschaffungsfrage ist sehr konkret: Neue Geräte müssen Driverless können, alte Geräte brauchen eine klare Printer Application

・PDF-Renderer und Fuzz-Testing legen kaputte Dateien früh auf den Tisch – bequemer als eine Zurückweisung erst an der Maschine

・Kleine und mittlere Betriebe legen zuerst Testdateien und Versionsprotokolle an, damit IT und Produktion endlich dieselbe Sprache sprechen

Die Druckerei-Seite sollte CUPS, IPP und Printer Applications in die Geräte-Abnahmeliste aufnehmen; die Design-Seite sollte die PDF-Vorprüfung als festen Schritt vor jeder Druckfreigabe verankern; bei KI-Integration nicht nur generierte Entwürfe anschauen, sondern Beschnitt, Schriften, Auflösung und Farbmodus prüfen können; SaaS-Teams, die Druckabläufe bedienen wollen, legen Queue-Status, Fehlerprotokoll, Dateiversion und Gerätefähigkeiten als abfragbare Felder an – das bringt mehr als eine weitere hübsche Upload-Seite

・OpenPrinting 2026 GSoC – Stand der Entwicklung