Ce chapitre vise à donner un peu de fond théorique sur l'impression en général, et sur ∪︀ en particulier. Si vous n'avez pas besoin de ça, vous pouvez aller directement au chapitre suivant. Il y a des chances pour que vous reveniez à ce chapitre quand même, car quelquefois, on a besoin de théorie supplémentaire pour régler un problème pratique. L'impression est un des chapitres les plus compliqués dans la technologie IT. Tôt dans l'histoire, chaque développeur d'un programme qui était capable de produire une sortie imprimable devait écrire son propre pilote d'imprimante. C'était très compliqué, car différents programmes avaient différents formats de fichiers. Même les programmes avec le même but, par exemple des traitements de texte, ne comprennent souvent pas les formats des autres. Pour cette raison, il n'y avait pas d'interface commune pour toutes les imprimantes, d'où le fait que les programmeurs ne géraient qu'un nombre limité de modèles. Un nouveau matériel apparaissant sur le marché nécessitait que les auteurs du programme écrivent un nouveau pilote s'ils voulaient que leur programme le gère. Pour les fabricants, il était impossible d'être sûr que leur matériel était compatible avec n'importe quel programme connu (bien qu'il y en ait eu bien moins que maintenant). Ayant à gérer 10 programmes et une douzaine d'imprimantes, il fallait 120 pilotes. ainsi, le développement d'interfaces unifiées entre les programmes et les imprimantes devenait urgent. L'apparition de Langages de description de pages décrivant la représentation graphique de l'encre et du toner sur les feuilles de papier (ou autre périphérique de sortie, comme les moniteurs, les photocompositeurs, &etc;) d'une manière générale fut un mouvement qui combla un grand fossé. Un tel développement fut &PostScript;, d'Adobe. Il signifiait qu'un programmeur d'application pouvait se concentrer sur le fait que son programme générait une description de sa page imprimable en langage &PostScript;, et que les développeurs des pilotes d'imprimantes pouvaient se concentrer sur l'impression des fichiers &PostScript;. Bien sûr, avec le temps, sont venus d'autres langages de description. Les plus importants concurrents de &PostScript; étaient PCL (Print Control Language, de &Hewlett-Packard;), ESC/P (d'Epson) et GDI (Graphical Device Interface de &Microsoft;). L'apparition de ces langages de description de page rendit la vie plus facile, et facilita les développements ultérieurs pour tout le monde. Comme il restait des langages différents, incompatibles et concurrents de description de pages, la vie des utilisateurs, des administrateurs et des développeurs resta suffisamment compliquée. &PostScript; est très utilisé dans les environnements d'impression professionnels, comme PrePress et les industries de services d'impression. Dans les domaines &UNIX; et &Linux;, &PostScript; est le standard dominant comme PDL. Ici, presque chaque programme génère une représentation &PostScript; de ses pages une fois actionné le bouton Imprimer. Voyons un exemple simple de code (fait main) &PostScript;. Le listing suivant décrit deux simples dessins : %!PS 100 100 moveto 0 50 rlineto 50 0 rlineto 0 -50 rlineto closepath .7 setgray fill % first box over; next 160 100 moveto 0 60 rlineto 45 10 rlineto 0 -40 rlineto closepath .2 setgray fill Ceci dit au crayon imaginaire &PostScript; de dessiner un chemin d'une certaine forme, et l'emplit de différentes nuances de gris. La première partie se traduit en un français plus compréhensible par Aller à l'emplacement (100,100), dessiner une ligne de longueur 50 vers le haut, puis de là vers la droite, puis vers le bas, et enfin clore cette partie. Maintenant, emplissons la forme dessinée d'un gris sombre à 70 % exemple de rendu comme une image Bien sûr, &PostScript; peut être bien plus compliqué que cet exemple simpliste. C'est un langage de programmation complet, avec différents opérateurs et fonctions. Vous pouvez même écrire des programmes &PostScript; pour calculer la valeur de Pi, formater un disque dur ou écrire dans un fichier. La valeur principale et la force de &PostScript; repose cependant dans le champ pour décrire la mise en page d'objets graphiques : il peut aussi changer l'échelle, inverser en miroir, déplacer, transformer, tourner et distordre tout ce que vous pouvez imaginer sur un morceau de papier comme des lettres dans différentes représentation de polices, des figures, des formes, des nuances, des couleurs, des lignes, des points, du quadrillage... Un fichier &PostScript; est une représentation d'une ou plusieurs pages à afficher, d'une manière relativement abstraire. Idéalement, il est supposé décrire les pages d'une manière indépendante du matériel. &PostScript; n'est pas directement visible ; il ne vit que sur les disques durs et dans la RAM comme une représentation codée des futures impressions. Ce que vous voyez sur un morceau de papier est presque toujours une image en quadrillage. Même si votre esprit suggère que vos yeux voient une ligne : prenez une puissante loupe et vous découvrirez de petits points... (un exemple contraire est une ligne dessinée par un traceur). Et c'est la seule chose que les moteurs de marquage des imprimantes d'aujourd'hui peuvent écrire sur le papier : de simples points de différentes couleurs, taille et résolution pour dessiner une image de page complète, composée de différents motifs de cartes de points. Les différentes imprimantes ont besoin d'images en quadrillage préparées de différentes manières. En pensant à un matériel à jet d'encre : en fonction de sa résolution, du nombre d'encres utilisées (les très bonnes en ont jusqu'à 7, alors que les meilleurs marchés en utilisent 3), du nombre de jets disponibles (certaines têtes d'impression en ont jusqu'à 100 !) qui projettent l'encre simultanément, de l'algorithme d'adoucissement utilisé, et de beaucoup d'autes choses, le format de quadrillage final et l'ordre de transfert au moteur de marquage sont très dépendants du modèle exact utilisé. À l'époque des débuts du Line Printer Daemon, les imprimantes étaient des machines qui frappaient des lignes de texte ASCII mécaniquement sur du papier plié en accordéon placé sous la table&etc; Quelle différence avec aujourd'hui ! Avant que le quadrillage final ne soit couché sur des feuilles de papier coupées, il a besoin de le calculer à partir de la représentation abstraite &PostScript;. C'est un travail de calcul très intensif. Il est appelé le Raster Imaging Process, (Processus d'image par quadrillage) plus communément RIP). Avec les imprimantes &PostScript;, la gestion du RIP-ping est prise en charge par l'imprimante elle-même. Vous lui envoyez juste le fichier &PostScript;. Le Raster Imaging Processor (aussi nommé RIP) situé dans l'imprimante est responsable (et spécialisé) de remplir très bien cette tâche d'interpréter la description de page &PostScript; et de mettre l'image quadrillée sur le papier. Les plus petites imprimantes &PostScript; ont un RIP intégré, gravé dans le Silicium, sur une puce spéciale. Les grosses imprimantes professionnelles ont souvent leur RIP implémenté en tant que logicielRIP intégré dans un ordinateur &UNIX; rapide, souvent une machine Sun SPARC Solaris ou &SGI; &IRIX;. Mais qu'arrive-t-il si vous n'avez pas assez de chance pour avoir une imprimante &PostScript; ? Vous avez besoin de RIPer avant d'envoyer les données au moteur de marquage. Vous avez besoin de traiter le &PostScript; fabriqué par votre application sur la machine-hôte (le client d'impression). Vous avez besoin de savoir comment le format de quadrillage de l'imprimante-cible doit être composé. En d'autres mots, comme vous ne pouvez pas vous reposer sur l'imprimante pour comprendre le &PostScript;, le problème se complique. Vous avez besoin d'un logiciel qui essaye de résoudre pour vous les problèmes soulevés. C'est exactement ce que l'omniprésent &ghostscript; fait pour beaucoup de boîtes &Linux;, *BSD et autres &UNIX; qui ont besoin d'imprimer sur des imprimantes non-&PostScript; : &ghostscript; est un interpréteur &PostScript;, un logiciel RIP capable de fonctionner sur différents matériels. Pour produire des quadrillages de points à partir d'une entrée &PostScript;, le concept de filtre est utilisé par &ghostscript;. Il y a beaucoup de filtres différents dans &ghostscript;, quelques uns d'entre eux spécialisés pour un certain modèle d'imprimante. Les filtres &ghostscript; spécialisés dans les périphériques ont souvent été développés sans le consentement ou l'aide du fabricant concerné. Sans accès aux spécifications et à la documentation, c'était un processus difficile de deviner le fonctionnement des protocoles et des formats de données. Tous les filtres &ghostscript; ne fonctionnent pas aussi bien pour leurs imprimantes. Cependant, certains des derniers, comme le filtre stp du projet d'impression de Gimp produisent d'excellents résultats, menant à la qualité photographique comparable voire supérieure aux équivalents de &Microsoft; &Windows;. &PostScript; est ce que la plupart des programmes d'application produisent pour l'impression &UNIX; et &Linux;. Les filtres sont de vrais chevaux de trait pour n'importe quel système d'impression. Ils produisent essentiellement les bonnes cartes de points pour n'importe quelle entrée &PostScript; pour les cibles non-&PostScript;. ∪︀ utilise ses propres filtres, à travers lesquels le système de filtrage est basé sur Ghostscript. Nommément, les filtres pstoraster et imagetoraster sont directement dérivés du code de Ghostscript. ∪︀ a réorganisé et perfectionné la totalité des mécanismes de ce code hérité et l'a organisé en quelques modules clairs et distincts. Ce dessin suivant (fait avec l'aide de &kivio;) donne un aperçu des filtres et interfaces matérielles (backends) dans ∪︀, et comment ils s'adaptent entre eux. Le flux se fait du haut vers le bas. Les interfaces matérielles sont des filtres spéciaux : ils ne convertissent pas les données vers un format différent, mais ils envoient les fichiers prêts pour l'imprimante. Il y a différentes interfaces matérielles pour les différents protocoles de transfert. Boîte de dialogue &kprinter; démarrée (dessin avec &kivio;) Boîte de dialogue &kprinter; démarrée (dessin avec &kivio;) À côté de la partie lourde de filtrage pour générer une image prête à imprimer, tout logiciel d'impression a besoin d'utiliser un mécanisme de SPOOL : c'est pour mettre en file différentes tâches d'impression de différents utilisateurs pour différentes imprimantes et différents filtres et les envoyer selon leur destination. Le démon d'impression prend soin de ceci. Ce démon conserve la maison en ordre : il est aussi réactif pour le contrôle des tâches ; les utilisateurs devraient être autorisés à annuler, arrêter, redémarrer, &etc; leurs travaux (mais pas ceux des autres) et ainsi de suite. Maintenant que vous savez comment un fichier de langage &PostScript; (qui décrit la mise en page d'une manière largement indépendante du matériel) est transformé en un image quadrillée, vous pouvez demander : Eh bien, il y a différentes sortes de périphériques de sortie de quadrillage : d'abord, ils diffèrent dans leur résolution, puis il y a différentes tailles de papier, s'ajoutent plusieurs sortes de finitions (impressions duplex, livrets, sorties brochées et agrafées avec différentes feuilles de papier coloré dessinés de différents plateaux, &etc;). Comment ceci s'adapte-t-il dans notre modèle de &PostScript; ne dépendant pas de la machine ? La réponse vient avec ce qu'on appelle &PostScript; Printer Description (fichiers &PPD;). Un fichier &PPD; décrit toutes les fonctionnalités indépendantes du matériel qui peuvent être utilisées par un certain modèle d'imprimante. Il contient aussi les commandes codées qui doivent être utilisées pour appeler certaines fonctionnalités du matériel. Mais les &PPD; ne sont par un livre fermé, ils sont de simples fichiers de texte ASCII. Les &PPD; ont été inventés par Adobe pour rendre facile pour les fabricants d'implémenter leurs propres fonctionnalités dans les imprimantes &PostScript;, et en même temps, de retenir une manière standard de le faire. Les &PPD; sont bien documentés et décrits par Adobe. Leurs spécifications sont de facto un standard ouvert. Souvenez-vous, l'impression &PostScript; avancée était à l'origine seulement développée pour une utilisation avec les systèmes &Microsoft; &Windows; et Apple &Mac;. Pendant longtemps, toutes les fonctionnalités riches de l'impression sur du matériel moderne étain tout simplement indisponible sous &Linux; et &UNIX;. ∪︀ change ceci d'une manière décisive. ∪︀ est très proche des &PPD; et, de ce fait, les &PPD; existants peuvent être utilisés entièrement par tous les systèmes utilisant ∪︀. En utilisant les &PPD;, les fabricants d'ordinateurs furent capables d'insérer des fonctionnalités spécifiques au matériel dans leurs produits, des fonctions comme le duplex, le brochage, la reliure, la finition, &etc; Les pilotes d'imprimante chargent ce &PPD; juste comme un fichier de configuration supplémentaire. Ainsi, le pilote d'imprimante en apprend sur les options du matériel disponible, et comment les appeler ; le pilote les présente aussi dans un &GUI; à l'utilisateur. Par ce mécanisme, vous pouvez toujours imprimer des fichiers de description de pages &PostScript;indépendantes du matériel et spécifier des options de finition dépendant du matériel par-dessus, qui seront ajoutées au &PostScript; généré par l'application. Les &PPD; à l'origine n'étaient pas utilisés en routine dans les systèmes &UNIX; et &Linux;. Les fabricants fournissant ces &PPD; ne les ont jamais prévus pour autre chose que les &SE; supportés : &Microsoft; &Windows; et &MacOS;. Par son brillant mouvement pour gérer et utiliser complètement les spécifications &PPD; existantes, ∪︀ donne maintenant la puissance d'utiliser toutes les fonctionnalités des imprimantes modernes aux utilisateurs de systèmes &Linux; et proches d'&UNIX;. &kdeprint; rend son usage bien plus confortable que les développeurs de ∪︀ ne l'ont jamais rêvé. ∪︀ peut utiliser les &PPD; originaux de &Windows;, distribués par les fabricants dans le cas des imprimantes &PostScript;. Ceux-ci normalement ne coûtent rien et ils peuvent être récupérés sur n'importe quel ordinateur &Windows; avec un pilote &PostScript; pour le modèle concerné, ou sur le disque fourni avec l'imprimante. Il y a aussi plusieurs endroits sur le web pour les télécharger. Maintenant, vous savez comment les imprimantes &PostScript; peuvent utiliser les &PPD;. Mais les imprimantes non-&PostScript; ? ∪︀ a fait une très bonne astuce en utilisant le même format de données et de structure que le &PostScript; Printer Descriptions (&PPD;) dans le monde &PostScript;, il peut décrire les options de tâche d'impression disponibles pour les imprimantes non-&PostScript; de la même manière. Pour ses buts spéciaux, ∪︀ a juste ajouté quelques options spéciales (la ligne qui définit le filtre à utiliser pour un traitement ultérieur du fichier &PostScript;). Ainsi, les développeurs pouvaient utiliser le même moteur logiciel pour analyser le fichier de description d'imprimante pour les options disponibles pour toutes les sortes d'imprimantes. Bien sûr, les développeurs de ∪︀ ne pouvaient pas se reposer sur le fait que les fabricants de matériel &PostScript; développent soudain des &PPD;. Ils devaient faire le début difficile et les écrire eux-mêmes à partir de rien. Plus de 1 000 sont disponibles dans la version commerciale de ∪︀ nommée ESP PrintPro. Cependant, il y a beaucoup de &PPD; spécifiques à ∪︀ disponibles. Même maintenant, ils ne sont pas dans la plupart des cas originaires des fabricants d'imprimantes mais des développeurs de logiciels libres. Les gens de ∪︀ l'ont prouvé, et les autres ont suivi : là où l'impression sous &Linux; et &UNIX; ; il y a un an ou deux était un bricolage, il est maintenant capable de gérer une grande gamme d'imprimantes, y compris les modèles à cartouches 7 couleurs capables de sortir de la qualité photo. Vous pouvez obtenir des &PPD; à utiliser avec ∪︀ et les imprimantes non-&PostScript; dans différents endroits du Web : d'abord, il y a le dépôt à www.linuxprinting.org, qui vous permet de générer un &PPD;CUPS-O-Matic en ligne pour n'importe quelle imprimante qui a déjà été gérée par le système &ghostscript;. Ceci vous aide à basculer vers ∪︀ avec peu d'efforts si vous le souhaitez. Si votre imprimante fonctionnait bien avec la manière traditionnelle d'impression &ghostscript;, prenez CUPS-O-Matic pour connecter votre pilote dans le système ∪︀ et vous aurez le meilleur des deux mondes. ensuite, il y a ∪︀-&PPD; pour les plus de 120 modèles d'imprimantes qui sont gérés par le nouveau pilote universel stp. stp (pour Stylus Photo) est maintenant développé par le projet gimp-print ; il a été commencé par Mike Sweet, le développeur en chef de ∪︀ et est maintenant disponible par gimp-print.sourceforge.net. Ce pilote imprime une vraie qualité photo sur beaucoup d'imprimantes à jet d'encre modernes et peut être configuré pour faire 120 ∪︀-&PPD; à côté de sa propre compilation. Les modèles &HP; Laser et DeskJet, Epson Stylus et PhotoColor et certains modèles Canon et Lexmark sont couverts. en troisième, il y a l'extension commerciale de ∪︀, des développeurs ∪︀ eux-mêmes : il est nommé ESP PrintPro et est fourni avec 2 300 pilotes d'imprimantes. Il y a même des filtres améliorés imagetoraster et pstoraster inclus. ∪︀ rend vraiment facile pour les fabricants de commencer à supporter l'impression sous &Linux; et &UNIX; pour leurs modèles à un coût raisonnablement bas. Le cadre modulaire de ∪︀ facilite le branchement de n'importe quel filtre (=pilote) avec un effort minimal et l'accession et l'utilisation du cadre complet d'impression que ∪︀ crée. Lisez-en plus sur les fonctionnalités excitantes de ∪︀ dans la documentation de ∪︀ à http://www.cups.org/documentation.html et http://www.danka.de/printpro/faq.html. De plus, à http://www.linuxprinting.org/ se trouve un référentiel universel pour tous les problèmes relatifs à l'impression sous &Linux; et &UNIX;. Pendant un long temps, beaucoup de développeurs étaient profondément insatisfaits du bon vieux LPD. Assez peu de nouveaux projets étaient démarrés pour améliorer l'impression : LPRng en est le meilleur exemple. Les autres sont PDQ, PPR, PLP, GNUlpr et RLPR. Mais aucun des nouveaux programmes n'était vu comme un pas décisif ; la plupart d'entre eux implémentaient simplement la même ancienne spécification LPD avec quelques (ou beaucoup) extensions, qui à nouveau les rendaient incompatibles ensemble. Ayant vu le développement de non seulement un, mais de différentes alternatives viables au vénérable BSD-style LPD, Grant Taylor, auteur du Linux Printing HOWTO, rallia finalement LPD Must Die! dans sa Campagne pour abolir le démon LPD. À côté de ce qui précède, du côté de l'industrie, il y a eu des efforts pour surmonter la faiblesse bien connue de LPD. Cela a commencé avec des extensions propriétaires au simple vieux LPD, et est allé jusqu'à la tentative de &Hewlett-Packard; pour établir &HP; JetDirect en tant que nouveau standard pour un protocole d'impression réseau. Le résultat fut encore plus d'incompatibilités. À la fin, une initiative pour définir un nouveau standard commun de l'industrie et un standard IETF prit forme. Le Printer Working Group ou PWG, un conglomérat informel de fabricants de matériel, de logiciel et de systèmes d'exploitation, ébaucha le nouvel Internet Printing Protocol, &IPP;. &IPP; v1.1 a été maintenant complètement approuvé par l'IETF (Internet Engineering Task Force) comme un standard proposé, et maintenant jouit d'un support unanime de l'industrie en Europe, aux USA et au Japon. La plupart des modèles actuels d'imprimante réseau ont maintenant une gestion &IPP; intégrée par-dessus les traditionnels LPR/LPD ou JetDirect Printing. &IPP; promet de résoudre beaucoup de problèmes que les administrateurs réseau rencontrent. Ce travail se heurte à des environnements de réseaux hétérogènes et prend la moitié des heures de travail passées à régler des problèmes d'impression. En créant un jeu unifié de fonctions de requêtes pour les imprimantes et serveurs prévus pour &IPP;, pour transférer des fichiers et établir des attributs de contrôle des tâches, &etc;, &IPP; est destiné à travailler sur toutes les plates-formes de &SE;. Le changement, cependant, ne se fera pas en une nuit, car beaucoup de matériel de conception ancienne restera en utilisation pendant de nombreuses années. Pour cela, dans &IPP;, il y a un précaution prise pour la compatibilité rétrograde de toutes les implémentations d'&IPP;. ∪︀ prouve la viabilité d'&IPP; dans tous les environnements. L'avantage le plus frappant sera son intégration dans le jeu existant d'autres protocoles IP robustes. Étant une extension du protocole éprouvé et robuste HTTP 1.1 pour la tâche spéciale de gérer la file d'impression et les données en rapport, il est aussi très facile à connecter dans d'autres standards au fur et à mesure qu'ils sont développés et déployés : Bases, résumé et certificat d'authentification pour les utilisateurs cherchant à accéder aux services d'impression. Chiffrement SSL3 et TLS pour le transfert des données. Communication bidirectionnelle des clients avec le matériel d'impression, en utilisant le mécanisme HTTP / &IPP; GET et POST Intégration au service de répertoires LDAP pour conserver une base de données cohérente d'imprimantes disponibles, leurs capacités et le coût par page, aussi bien que les mots de passe utilisateurs, les ACL, &etc; L'impression par Tirer (à l'opposé du modèle habituel Pousser), où un serveur ou une imprimante a juste besoin qu'on lui dise l'&URL; d'un document, où on le retrouve sur la ressource sur l'Internet et on l'imprime. Avez-vous déjà vu une démonstration des capacités de ∪︀ sur le réseau ? Vous devez avoir été très impressionné si vous ne saviez pas par avance quoi en attendre. Imaginez que vous êtes administrateur d'un LAN. Pour des raisons de test, vous avez totalement installé une boîte &kde; / ∪︀ sur votre réseau, avec une douzaine d'imprimantes configurées et fonctionnelles : &PostScript;, LaserJets, InkJets and BubbleJets, et autres. Vos utilisateurs de &kde; sur cette machine sont heureux comme jamais, ils peuvent imprimer comme jamais auparavant, faisant sonner tous les cloches et sifflets de chaque imprimante. Cela vous a pris 2 heures pour que tout fonctionne à la perfection... et maintenant, tous les autres 100 utilisateurs sur le réseau en veulent autant. Deux heures de plus pour chaque machine ? Pas moyen de le faire avant l'année prochaine, pensez-vous ? Faux. Changez juste un réglage dans la boîte ∪︀ du départ pour en faire un serveur. Installez ∪︀ sur cinq autres machines comme clients. Le temps que vous retourniez à votre premier client, vous trouvez les utilisateurs jouant gaiement avec les réglages de la douzaine d'imprimantes que vous avez définies plus tôt sur le serveur. Comme par magie, les imprimantes sont apparues sur toutes les boîtes de dialogue Imprimer des cinq nouvelles machines clientes de ∪︀. Vos utilisateurs impriment, mais par un seul pilote n'a été installé sur les clients, ni une file d'attente d'impression définie. Ainsi, comment cette magie fonctionne-t-elle ? La réponse n'est pas compliquée du tout. Si un serveur ∪︀ est sur le LAN, il balaye par broadcast les noms de toutes les imprimantes disponibles sur le LAN, en utilisant le protocole UDP et le port 631. Le port 631 est réservé comme port bien connu par l'IANA (l'Internet Assigning Numbers Authority) pour les besoins d'&IPP;. Tous les clients ∪︀ écoutent les les informations envoyées par les serveurs ∪︀ à leur port 631. C'est la manière dont ils connaissent les imprimantes disponibles et comment ils apprennent le chemin vers ces imprimantes. En utilisant &IPP;, qui est vraiment une extension intelligente à HTTP v 1.1, ∪︀ est capable d'adresser tous les objets en relation à un système d'impression via des Universal Resource Locators ou URL. Les tâches d'impression à supprimer ou à redémarrer, les imprimantes à interroger ou à modifier, les tâches d'administration à réaliser sur le serveur avec &IPP; et ∪︀, tout est adressable par un certain URL. Beaucoup de choses importantes peuvent être faites par l'interface Web à ∪︀, accessible par exemple avec &konqueror;. De plus, les clients peuvent basiquement administrer et utiliser n'importe quelle imprimante qu'ils voient, juste comme si elle était installée localement. Bien sûr, vous pouvez mettre des restrictions dessus avec les listes de contrôle d'accès, &etc;, de telle manière que n'importe qui ne puisse pas utiliser n'importe quelle imprimante comme il le souhaite. Les clients sont même capables d'imprimer sans le filtre approprié (ou pilote) installé localement. Comment cela fonctionne-t-il ? Si un client veut en savoir sur une imprimante et sélectionner des options spécifiques à l'imprimante, il envoie une requête (nommée CUPS-get-ppd) au serveur. Le serveur dit tout au client sur les options spécifiques à l'imprimante, comme il le lit sur le &PPD; du côté serveur. L'utilisateur du côté client peut voir les options et sélectionner celles qui sont nécessaires. Il envoie le fichier à imprimer, habituellement des fichiers &PostScript; bruts, agrémentés des options d'impression au serveur d'impression, en utilisant &IPP; comme protocole de transport. Tout le processus ultérieur, spécialement le filtrage pour générer le format final pour l'imprimante-cible se fait par le serveur. Le serveur a les programmes nécessaires (pilotes ou filtres) pour faire cela. De cette manière, un client imprime sans avoir besoin d'installer un pilote localement. Tout changement sur le serveur, comme un ajout ou une modification d'imprimante est connu instantanément par les clients sans autre configuration. Certaines autres fonctionnalités avancées incorporées dans ∪︀ sont la capacité de faire le load balancing (équilibrage de charge). Si vous définissez la même file d'attente d'impression sur deux ou plus serveurs différents, les clients enverront leurs tâches au premier qui répond ou est disponible. Cela implique un équilibrage de charge automatique parmi les serveurs. Si vous devez retirer un serveur du réseau pour de la maintenance d'administration, les autres prendront juste ses tâches sans que les utilisateurs ne s'en rendent compte.