Cette page contient les détails d'un projet de rédaction technique accepté pour Google Season of Docs.
Résumé du projet
- Organisation Open Source:
- Linux Foundation
- Rédacteur technique:
- PIYUSHgoyal16
- Nom du projet:
- Tutoriels et consignes de conception pour les pilotes d'imprimante/de scanner dans les applications d'imprimante
- Durée du projet:
- Durée standard (3 mois)
Project description
Présentation
Les pilotes d'imprimante classiques constitués de filtres spécifiques à l'imprimante et de fichiers PPD (Postscript Printer Description, décrit les fonctionnalités de l'imprimante et les filtres à appeler) qui doivent être supprimés dans certains répertoires du système de fichiers sont remplacés par ce que l'on appelle des applications d'imprimante, c'est-à-dire une émulation d'une imprimante réseau IPP.
La plupart des imprimantes modernes à usage général sont des imprimantes IPP qui permettent l'impression sans pilote. Ils s'annoncent eux-mêmes via DNS-SD, les clients peuvent interroger les informations de capacité les concernant via des requêtes IPP et ils utilisent des formats de données standards pour les tâches d'impression. Les imprimantes n'offrant pas cette fonctionnalité, les imprimantes anciennes ou spécialisées nécessitent généralement un pilote d'imprimante.
Une application d'impression est un daemon qui détecte les imprimantes compatibles et les annonce sur le serveur local en tant qu'imprimante IPP Everywhere. Printer Applications contient le logiciel permettant d'imprimer les tâches entrantes sur la ou les imprimantes compatibles, en convertissant les données dans la langue maternelle de l'imprimante et en fournissant aux clients, sur demande, des informations sur les fonctionnalités de l'imprimante. Elle dispose même d'une interface d'administration Web, comme une véritable imprimante réseau.
Comme nous le savons, Linux adopte un packaging en bac à sable (Snap par exemple) et l'impression s'oriente également dans cette direction. Dans un package en bac à sable, nous ne pouvons pas modifier le contenu du répertoire une fois celui-ci créé. Notre système n'est plus modulaire. Impossible de choisir le package du pilote d'imprimante à installer. Les applications d'imprimante répondent à ce problème de modularité et nous offrent la même liberté que dans le cas des pilotes d'imprimante.
Les pilotes d'imprimante et de scanner de Snaps ne sont pas seulement une exigence pour un CUPS et une application ancrés, ils fonctionnent également sur des systèmes complètement classiques. Mais contrairement aux pilotes empaquetés classique, ils sont indépendants de la distribution de l'OS. Vous créez un pilote d'imprimante Snap, qui fonctionne sur toutes les distributions de système d'exploitation qui s'exécutent en un clin d'œil, il n'est pas nécessaire de empaqueter des pilotes d'imprimante pour chaque distribution (et leur version) indépendamment et se heurter à un enfer des dépendances. Autre avantage : l'ancien concept des fichiers PPD provenant des imprimantes PostScript n'est plus disponible. De plus, en associant le système CUPS et le pilote de l'imprimante via une connexion IP au lieu de déposer des fichiers dans le système CUPS, le système CUPS et l'application d'imprimante peuvent se trouver dans des packages de bac à sable distincts.
Ma tâche sera de décrire comment concevoir les pilotes des imprimantes et des scanners pour ce type d'emballage et comment les emballer dans des Snaps. L'objectif est d'aider à l'avenir tous ceux qui écrivent des pilotes d'imprimantes ou de scanners, en particulier les fabricants de matériel, à le faire correctement.
Le workflow de l'application d'impression peut être résumé à l'aide de l'organigramme donné:
À la base de la création de telles applications imprimante/scanner est PAPPL, une bibliothèque fournissant la plupart des fonctionnalités à cet effet, mais également des filtres-cups contenant le code à utiliser pour les applications d'imprimante. Le concept est toujours en cours de développement, principalement dans le programme Google Summer of Code de cette année, mais le 14 septembre, lorsque la période de rédaction de la documentation a commencé, la période de codage des GSoC est déjà terminée et c'est à ce moment-là qu'OpenPrinting a besoin du tutoriel.
Modèle pour les pilotes d'imprimante Définir la structure des données du JOB
Déclarer un tableau de constantes pour les tailles de médias
Déclarer des fonctions i) Callback ou init Une fonction booléenne acceptant le nom du conducteur, les données du conducteur, etc., et définit les attributs du pilote en conséquence. Si les informations fournies sont appropriées, les valeurs "true" et "false" sont renvoyées en cas d'échec.
ii) imprimer une fonction booléenne acceptant le job, les options de cette tâche et l'appareil. Elle imprime un fichier et renvoie la valeur "true" en cas de réussite et la valeur "false" en cas d'échec.
iii) rendjob la fonction booléenne acceptant le job, les options de la tâche et l’appareil. Elle met fin à la tâche et affiche "true" en cas de réussite et "false" en cas d'échec.
iv) rendpage Fonction booléenne acceptant le job, options pour la tâche, appareil et numéro de page. Elle termine la page et affiche "true" en cas de réussite et "false" en cas d'échec.
v) rstartjob Une fonction booléenne acceptant la tâche, les options pour cette tâche et l’appareil. Elle démarre la tâche et renvoie la valeur "true" en cas de réussite et la valeur "false" en cas d'échec.
vi) rstartpage Fonction booléenne acceptant la tâche, options pour la tâche, appareil et numéro de page. Il lance la page et affiche "true" en cas de réussite et "false" en cas d'échec.
vii) rwrite fonction booléenne acceptant la tâche, options pour cette tâche, appareil, numéro de ligne et tableau de caractères. Il écrit la ligne et renvoie "true" en cas de réussite et "false" en cas d'échec. viii) des fonctions facultatives telles que l'identification (permet d'identifier les imprimantes en fonction de l'action fournie), la compression(compresser une ligne de graphiques), etc.