Auf dieser Seite finden Sie die Details zu einem Projekt für technisches Schreiben, das für Google Season of Docs angenommen wurde.
Projektzusammenfassung
- Open-Source-Organisation:
- The Linux Foundation
- Technischer Redakteur:
- PIYUSHgoyal16
- Projektname:
- Anleitung und Designrichtlinien für Drucker-/Scannertreiber in Druckeranwendungen
- Projektdauer:
- Standardlaufzeit (3 Monate)
Projektbeschreibung
Übersicht
Klassische Druckertreiber, die aus druckerspezifischen Filtern und PPD-Dateien (Postscript Printer Description, beschreibt die Druckerfunktionen und die zu rufenden Filter) bestehen und in bestimmte Verzeichnisse des Dateisystems abgelegt werden müssen, werden durch sogenannte Druckeranwendungen ersetzt, die eine IPP-Netzwerkdrucker-Emulation darstellen.
Die meisten modernen Allzweckdrucker sind IPP-Drucker, die den treiberlosen Druck ermöglichen. Sie werben über DNS-SD für sich selbst, Clients können ihre Funktionsinformationen über IPP-Anfragen abfragen und sie verwenden Standarddatenformate für Druckaufträge. Drucker, die diese Funktion nicht bieten, benötigen in der Regel einen Druckertreiber. Das ist in der Regel bei älteren oder speziellen Druckern der Fall.
Eine Druckeranwendung ist ein Daemon, der die unterstützten Drucker erkennt und diese auf dem lokalen Host als IPP Everywhere-Drucker bewirbt. Druckeranwendungen enthalten die Software zum Drucken eingehender Jobs auf den unterstützten Druckern. Dabei werden die Daten in die native Sprache des Druckers konvertiert. Auf Anfrage erhalten Kunden Informationen zu den Funktionen des Druckers. Die Druckeranwendung hat sogar eine Webadministrationsoberfläche, ähnlich wie ein echter Netzwerkdrucker.
Wie wir wissen, wird unter Linux eine Sandbox-Verpackung eingeführt (z. B. Snap) und auch die Druckfunktion wird in diese Richtung entwickelt. In einem Paket mit einer Sandbox können wir den Verzeichnisinhalt nach dem Erstellen nicht mehr ändern. Unser System ist nicht mehr modular. Wir können nicht auswählen, welches Druckertreiberpaket installiert werden soll. Druckeranwendungen lösen dieses Problem der Modularität und bieten uns die gleiche Freiheit wie im Fall von Druckertreibern.
Drucker- und Scannertreiber in Snaps sind nicht nur für eine gesnappte CUPS- und gesnappte Anwendung erforderlich, sondern funktionieren auch auf vollständig klassischen Systemen. Im Gegensatz zu klassisch verpackten Treibern sind sie jedoch unabhängig von der Betriebssystemverteilung. Sie erstellen einen Druckertreiber als Snap und er funktioniert auf allen Betriebssystemen, auf denen snapd ausgeführt wird. Sie müssen Druckertreiber nicht für jede Distribution (und Version) separat verpacken und sich nicht durch die Abhängigkeits-Hölle kämpfen. Ein weiterer Vorteil ist, dass das alte Konzept von PPD-Dateien, das von PostScript-Druckern stammt, eingestellt wurde. Außerdem können sich sowohl das CUPS-System als auch die Druckeranwendung in separaten Paketen in einer Sandbox befinden, da das CUPS-System und der Druckertreiber über eine IP-Verbindung gekoppelt werden, anstatt Dateien in das CUPS-System zu verschieben.
Meine Aufgabe besteht darin, zu beschreiben, wie die Treiber für Drucker und Scanner für diese Art der Verpackung entworfen und in Snaps verpackt werden. Ziel ist es, allen Entwicklern von Drucker- oder Scannertreibern, insbesondere den Hardwareherstellern, in Zukunft zu helfen, die richtigen Entscheidungen zu treffen.
Der Workflow der Druckeranwendung kann mit dem folgenden Flussdiagramm zusammengefasst werden:
Die Grundlage für die Erstellung solcher Drucker-/Scanneranwendungen ist PAPPL, eine Bibliothek, die die meisten Funktionen dafür bietet, aber auch Cups-Filter, die Code für Druckeranwendungen enthalten. Das Konzept befindet sich noch in der Entwicklungsphase, hauptsächlich im Rahmen des diesjährigen Google Summer of Code. Am 14. September, wenn die Dokumentation geschrieben wird, ist die Programmierphase des GSoC jedoch bereits vorbei. Zu diesem Zeitpunkt benötigt OpenPrinting das Tutorial.
Vorlage für Druckertreiber Struktur für JOB-Daten definieren
Konstanten-Array für Mediengrößen deklarieren
Funktionen deklarieren i) Callback oder init Eine boolesche Funktion, die den Namen des Fahrers, Fahrerdaten usw. akzeptiert und die Fahrerattribute entsprechend festlegt. Wenn die angegebenen Details korrekt sind, wird „true“ zurückgegeben, andernfalls „false“.
ii) boolesche Funktion „print“, die den Job, Optionen für den Job und das Gerät akzeptiert. Sie gibt eine Datei aus und gibt im Erfolgsfall „true“ und im Fehler „false“ zurück.
iii) rendjob: Boolesche Funktion, die einen Job, Optionen für den Job und das Gerät akzeptiert. Er beendet den Job und gibt bei Erfolg "true" und bei Fehlschlagen "false" zurück.
iv) boolesche Funktion zur Annahme des Jobs, Optionen für den Job, Gerät und Seitennummer. Damit wird die Seite beendet und bei Erfolg wird „true“ zurückgegeben, bei Fehlern „false“.
v) rstartjob: Boolesche Funktion, die Job, Optionen für den Job und das Gerät akzeptiert. Sie startet den Job und gibt bei Erfolg „true“ und bei Fehler „false“ zurück.
vi) rstartpage: Boolesche Funktion, die Job, Optionen für den Job, Gerät und Seitennummer akzeptiert. Er startet die Seite und gibt bei Erfolg „true“ und bei Fehler „false“ zurück.
vii) rwrite: boolesche Funktion zur Annahme des Jobs, Optionen für den Job, Gerät, Zeilennummer und Zeichenarray. Die Zeile schreibt die Zeile und gibt im Erfolgsfall "true" und bei einem Fehler "false" zurück. viii) optionale Funktionen wie "Identifizieren" (ermöglicht die Identifizierung von Druckern anhand der angegebenen Aktion), "Komprimieren" (eine Zeile mit Grafiken komprimieren)