Aquest capítol està orientat a oferir una mica de rerefons teòric sobre la impressió en general i especialment sobre ∪︀. Si no necessiteu aquesta informació, passeu directament al següent capítol. Segurament haureu de tornar a aquest capítol en algun moment, perquè a vegades és necessària teoria extra per a resoldre problemes pràctics. La impressió és un dels capítols més complicats de la tecnologia IT. Al principi, tot desenvolupador d'un programa que era capaç d'imprimir també havia d'escriure els seus propis controladors. Això era força complicat perquè diferents programes tenien formats diferents. Fins i tot programes amb el mateix ús, per exemple, els processadors de text, tot sovint no entenien d'altres formats. De manera que no hi havia una interfície comú per a totes les impressores, per tant els programadors sovint tan sols donaven suport a uns pocs models seleccionats. L'aparició d'un nou dispositiu en el mercat obligava als autors dels programes a escriure un nou controlador si volien que el seu programa el suportés. També per als fabricants, no era possible assegurar de que el seu dispositiu estigués suportat per tots els programes coneguts (tot i que ara n'hi ha molts menys). Oferir suport a deu programes d'aplicació i a una dotzena d'impressores, volia dir que l'administrador del sistema havia de batallar amb 120 controladors. De manera que el desenvolupament d'interfícies unificades entre programes i impressores es convertia en una necessitat urgent. L'aparició dels Llenguatges de descripció de la pàgina, descrivint la representació gràfica de la tinta i el tòner en fulls de paper (o d'altres dispositius de sortida, com monitors, tipògrafs fotogràfics, &etc;) d'una manera comuna, el qual va ocupar un gran buit. Un d'aquests desenvolupaments fou el &PostScript; de Adobe. Significava que un programador d'aplicacions es podia concentrar en fer que el seu programa generés un llenguatge de descripció &PostScript; de les pàgines que volia imprimir, mentre que els desenvolupadors de dispositius de la impressió es podien concentrar en crear dispositius conformes a &PostScript;. Per descomptat, amb el temps, varen aparèixer d'altres mètodes de descripció. Els competidors més importants de &PostScript; foren PCL (Print Control Language, de &Hewlett-Packard;), ESC/P (de Epson) i GDI (Graphical Device Interface de &Microsoft;). L'aparença d'aquests llenguatges de descripció de pàgina va facilitar la vida i el desenvolupament futur a tot el món. Tot i això encara n'hi havien de diferents, incompatibles, i competien entre sí dificultant la vida dels usuaris, administradors, desenvolupadors i fabricants. &PostScript; és més usat en entorns professionals de la impressió tals com PrePress i industries de serveis d'impressió. En els dominis de &UNIX; i &Linux;, &PostScript; és un estàndard predominant com PDL. Allí, gairebé tots els programes generen una representació &PostScript; de les seves pàgines una vegada que feu clic sobre el botó Imprimeix. Mirem un exemple simple (fet a ma) de codi &PostScript;. El següent llistat descriu dos dibuixos simples: %!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 Aquest exemple us indica a la imaginària ploma de &PostScript; que dibuixi una certa forma, i després ompli les diferents ombres de gris. La primera part es tradueix en castellà amb Moure a la coordenada (100,100), dibuixa una línia de longitud 50 cap a dalt, després una a la dreta, altra vegada cap avall i finalment tanca aquesta part. Ara usa un dibuix gris al 70% i usa-la per omplir la forma geomètrica. exemple mostrat com una imatge. Per descomptat, el &PostScript; pot ser molt més complicat que el que es veu en aquest simple exemple. És un complet llenguatge de programació amb molts operadors i funcions. Fins i tot es poden escriure programes de &PostScript; per a calcular el valor de Pi, formatar un disc dur o escriure un fitxer. El principal valor i força de &PostScript; resideix en el camp de la descripció dels objectes gràfics d'una pàgina: També podeu canviar l'escala, moure, transformar, rotar i distorsionar qualsevol cosa susceptible de ser representada en un full de paper; tals com lletres amb diferents aspectes, figures, formes, ombres, colors, línies, punts, dibuixos... Un fitxer &PostScript; és una representació d'una o més pàgines destinades a ser impreses, d'una forma relativament abstracta. La seva utilitat ideal és la de representar pàgines d'una forma independent al dispositiu que s'usarà per a imprimir-les. &PostScript; no és visible directament, tan sols es desa en discos durs i en memòria RAM com a una representació codificada de futures pàgines impreses. El que es veu sobre una full de paper gairebé sempre és una imatge de trama. Tot i que el vostre cervell us suggereixi que el que els vostres ulls veuen és una línia: Agafeu una bona lupa i descobrireu cents de petits punts... (un exemple del contrari són les línies que han estat dibuixades per un traçador). Y això és tot el que els motors de dibuix de les impressores actuals són capaces de posar sobre el paper: Simples punts de diferents colors, mides i resolucions, per a composar una imatge de pàgina completa en base a diferents patrons de mapes de bits. Les diferents impressores necessiten les imatges de trama preparades en maneres diferents. Penseu en un dispositiu d'injecció de tinta: Depenen de la seva resolució, el nombre de tintes usades (les millors necessiten 7 tintes diferents, mentre que les més barates tan sols en solen usar 3), el nombre d'injectors disponibles (alguns capçals de la impressió tenen fins a 100) que dispensen tinta simultàniament, l'algoritme de tramat que s'usi, i moltes altres coses, el format de trama final i l'ordre de transferència al motor d'injecció depenen en gran mesura del model exacte utilitzat. Al començament de la existència del Line Printer Daemon, les impressores eren màquines que martellejaven mecànicament línies de text ASCII en un paper continu que es recollia d'una caixa ubicada sota la taula... Tota una diferència amb avui dia! Abans de que les imatges de trama siguin impreses en fulls de paper, ha estat necessari calcular d'alguna manera un representació &PostScript; abstracta. Aquest procés requereix un càlcul força intensiu. S'anomena Raster Imaging Process -procés de tramat de la imatge-, més comunament conegut com RIP. En les impressores &PostScript; el procés RIP es realitza en els propis dispositius d'impressió. Simplement s'ha d'enviar el fitxer &PostScript;. El Processador de tramat de la imatge (que també s'anomena RIP) intern de la impressora és el responsable (i especialista) en dur a terme correctament aquesta tasca d'interpretació de les descripcions de la pàgina &PostScript; i posar la trama sobre el paper. Els dispositius &PostScript; petits tenen un RIP incorporat en el maquinari; gravat e silici, sobre un xip especial. Les grans impressores professionals tenen el seu RIP implementat per programari dins d'un ordinador &UNIX; ràpid i dedicat en exclusiva al procés, normalment màquines Sun SPARC Solaris o &SGI; &IRIX;. Però, què succeeix quan no es te la sort de poder disposar d'una impressora &PostScript;? És necessari realitzar el procés de RIP abans d'enviar la informació a la impressora. Necessitareu interpretar el &PostScript; generat per l'aplicació en la mateixa màquina (client d'impressió). Necessitareu conèixer el format de trama exacte que requereix la impressora per a poder-lo composar adequadament. En altres paraules, com no es pot deixar en mans de la impressora la responsabilitat d'interpretar el &PostScript;, tot resulta més complicat. Necessitareu un programari que intenti resoldre automàticament la qüestió. Això és exactament el que s'encarrega de fer l'omnipresent &ghostscript; en molts sistemes &Linux;, *BSD o d'altres &UNIX; que necessiten imprimir en impressores que no són &PostScript;: &ghostscript; és un intèrpret de &PostScript;, un RIP per programari capaç d'ocupar-se de molts dispositius diferents. Per a produir imatges de trama a partir d'una entrada &PostScript;, en &ghostscript; s'usa el concepte de filtres. Hi ha molts filtres diferents en &ghostscript;, alguns d'ells específics per a un model d'impressora. Els filtres específics per a dispositius de &ghostscript; en moltes ocasions han estat desenvolupats sense el consentiment o el suport del fabricant en qüestió. Sense accés a les especificacions i a la documentació, resulta un procés molt complicat descobrir els protocols i els formats de dades a través de enginyeria inversa. No tots els filtres de &ghostscript; funcionen igual de bé en les seves impressores corresponents. Alguns dels més moderns, com el filtre stp del projecte de la impressió de Gimp, produeixen uns resultats excel·lents amb una qualitat de la impressió a qualitat fotogràfica igual o fins i tot superior que els seus controladors equivalents en &Microsoft; &Windows;. &PostScript; és el que produeixen la majoria de programes d'aplicació que imprimeixen en &UNIX; i &Linux;. Els filtres són autèntiques màquines de conversió cap a qualsevol sistema d'impressió. Essencialment el que fan és produir els mapes de bits correctes a partir de qualsevol entrada &PostScript; i amb destí als enginys que no són &PostScript;. ∪︀ usa els seus propis filtres, tot i que el sistema de filtratge està basat en Ghostscript. En concret els filtres pstoraster i imagetoraster estan derivats directament del codi de Ghostscript. ∪︀ ha reorganitzat i optimitzat tots els mecanismes del codi antic i l'ha distribuït en uns quants mòduls més concrets i diferents. El següent dibuix (realitzat amb l'ajuda de &kivio;) mostra una idea dels filtres i els dorsals que funcionen dins de ∪︀, i de com interaccionen junts. El flux va de dalt cap a avall. Els dorsals són filtres especials: No converteixen les dades a un format diferent, però envien els fitxers una vegada preparats a la impressora. Hi ha diferents dorsals per als diferents protocols de transferència. Diàleg de &kprinter; iniciat (esborrany del dibuix de &kivio;) Diàleg de &kprinter; iniciat (esborrany del dibuix de &kivio;) A part de la dura tasca del filtratge per a generar mapes de bits llestos per a la impressió, qualsevol programari d'impressió necessita usar un mecanisme de cues: Això serveix per alinear els diferents treballs dels diferents usuaris per a les diferents impressores a través dels diferents filtres i enviar-los correctament cap als seus destins. El dimoni de la impressió s'encarrega de tot això. Aquest dimoni manté la casa ordenada: També és el responsable del control de tasques: Els usuaris tenen que poder cancel·lar, aturar, reiniciar, &etc; les seves tasques (però no les d'altres persones) i tot ha de funcionar correctament. Ara que ja coneixem com es transforma un fitxer en llenguatge &PostScript; (el qual descriu la disposició de la pàgina de manera independent al dispositiu) en una imatge de trama, podríem preguntar: Bé, hi ha diferents tipus de dispositius de sortida: Difereixen en la seva resolució, en els diferents mides de paper, en les opcions de l'acabat (a doble cara, pamflets, enquadernació entre fulls de diferents colors que es recullen de diferents safates, &etc;). Com s'ajusta tot això en el nostre model de &PostScript; independent del dispositiu? La resposta la trobarem en els fitxers de descripció d'impressores &PostScript; (&PPD;). Un &PPD; descriu totes les característiques dependents del model en concret que s'usin en una impressora determinada. També conté els comandaments codificats que s'han d'usar per a invocar a certes característiques del dispositiu. Però els &PPD; no són un llibre tancat, simplement són fitxers de text ASCII. Els &PPD; foren inventats per Adobe per a facilitar als fabricants la implementació de les seves pròpies característiques en les impressores &PostScript;, i alhora conservar la manera estàndard de fer-ho. Els &PPD; estan ben descrits i documentats per Adobe. La seva especificació resulta ser un estàndard obert de facte. Tingueu present que la impressió avançada de &PostScript; es desenvolupar originalment per a ser usada tan sols en sistemes &Microsoft; &Windows; i Apple &Mac;. Durant molt de temps les característiques especials dels dispositius de la impressió moderns no han estat disponibles en &Linux; i &UNIX;. ∪︀ ha suposat un canvi radical en això. ∪︀ està unit molt a prop als &PPD; i per això els &PPD; existents es poden usar completament en els sistemes que usen ∪︀. Mitjançant l'ús dels &PPD;, els fabricants d'impressores foren capaços d'introduir característiques específiques del maquinari en els seus productes, com per exemple, la impressió a dues cares, l'enquadernació, les grapadores, l'acabat, &etc;. El controlador de la impressora carrega el &PPD; de la mateixa manera que un fitxer de configuració. D'aquesta manera el controlador de la impressora s'informa sobre les opcions del dispositiu que estan disponibles i com cridar-les; el controlador també presenta un &GUI; per a l'usuari. A través d'aquest mecanisme encara podreu imprimir fitxers de llenguatges de descripció &PostScript; que són independents del dispositiu i especificar opcions d'acabat que sí són exclusives de cada dispositiu en concret i que s'afegeixen al &PostScript; generat per l'aplicació. Els &PPD; no foren originalment utilitzats rutinàriament en els sistemes &UNIX; i &Linux;. Els distribuïdores dels &PPD; mai varen tenir la intenció de que fossin usats en d'altres sistemes operatius diferents als suportats originalment: &Microsoft; &Windows; i &MacOS;. Gràcies al brillant esforç realitzat per a suportar i tornar a usar l'especificació &PPD; existent, ∪︀ ofereix ara la possibilitat d'usar totes les característiques de les impressores modernes als usuaris dels sistemes operatius &Linux; i similars. &kdeprint; fa el seu ús fins i tot més còmode del que el varen concebre originalment els desenvolupadors de ∪︀. ∪︀ pot usar els &PPD; originals de &Windows;, distribuïts pels fabricants en el cas de les impressores &PostScript;. Normalment no solen costar diners i es poden obtenir de qualsevol ordinador &Windows; que tingui instal·lat el controlador &PostScript; del model en qüestió o dels discos proveïts junt amb la impressora. També hi ha diverses pàgines web des de les que es poden descarregar. Ara ja coneixem com poden usar els &PPD; les impressores &PostScript;. Però, què passa amb les impressores que no són &PostScript;? ∪︀ ha realitzat un bon truc amb això: Usant el mateix format i la mateixa estructura que en les descripcions d'impressores &PostScript; (els &PPD;) del mon &PostScript;, es poden descriure les opcions existents en les impressores que no són &PostScript;. Per a aquest propòsit ∪︀ ha afegit algunes opcions especials (principalment la línia que defineix el filtre a usar en el procés posterior del fitxer &PostScript;). D'aquesta manera els desenvolupadors poden usar el mateix motor de programari per a processar les opcions disponibles en els fitxers de descripció d'impressores de tot tipus de dispositius. És obvi que els desenvolupadors de ∪︀ no poden esperar a que els fabricants de les impressores no &PostScript; decideixin de sobte posar-se a desenvolupar els &PPD;. Haurien de fer-ho ells sols i començar des de cero. Hi ha més de 1.000 d'aquests fitxers disponibles amb la versió comercial de ∪︀, anomenada ESP PrintPro. Però també hi ha disponibles molts &PPD; específics de ∪︀. Fins i tot ara segueixen sense estar realitzats, en molts casos, pels fabricants de les impressores, si no per desenvolupadors de programari lliure. L'equip de ∪︀ ha comprovat el seu funcionament i els altres han vingut al darrere: Mentre que fa un o dos anys imprimir en &Linux; i &UNIX; era una tortura amb determinades impressores, en l'actualitat és possible usar a la perfecció una gran gama d'aquestes, incloent impressores d'injecció de 7 colors capaces de donar una sortida de qualitat fotogràfica. Es poden obtenir els &PPD; per a usar amb ∪︀ i impressores que no són &PostScript; de diferents punts en la web: En primer lloc està el repositori de www.linuxprinting.org, el qual permet generar automàticament un &PPD; per a qualsevol impressora que estigués anteriorment suportada per &ghostscript;. Això ajuda a realitzar el canvi a ∪︀ sense molt esforç, si és que voleu fer-ho. Si la vostra impressora funcionava bé amb el mètode tradicional de &ghostscript;, useu el generador automàtic per afegir el controlador a ∪︀ i així tindreu el millor d'ambdós mons. En segon lloc, hi ha els &PPD; de ∪︀ per a més de 120 models d'impressores, guiats pel nou controlador universal stp. stp (usat originalment per a Stylus Photo) ara és desenvolupat pel projecte gimp-print; el projecte fou iniciat per en Mike Sweet, el líder desenvolupador de ∪︀ i ara està disponible en la pàgina gimp-print.sourceforge.net. Aquest controlador imprimeix en qualitat fotogràfica real en la majoria de les impressores d'injecció de tinta modernes i es pot configurar per a crear 120 &PPD; de ∪︀, a més de la seva pròpia compilació. Estan suportades les impressores làser i d'injecció d'&HP;, els models Stylus i Photo Color de Epson així com alguns models de Canon i Lexmark. En tercer lloc està l'extensió comercial de ∪︀ realitzada pels mateixos desenvolupadors de ∪︀: S'anomena ESP PrintPro i inclou més de 2.300 controladors d'impressora. Fins i tot porta incloses unes versions millorades dels filtres imagetoraster i pstoraster. ∪︀ facilita molt als fabricants incloure suport de la impressió per a &Linux; i &UNIX; a un cost raonablement baix. El marc de treball modular de ∪︀ facilita la inclusió de qualsevol filtre (=controlador) amb un esforç mínim i l'accés i ús de tot l'entorn de treball de la impressió que crea ∪︀. Podeu llegir més sobre les impressionants característiques de ∪︀ en la documentació de ∪︀ que està disponible en http://www.cups.org/documentation.html i http://www.danka.de/printpro/faq.html. També és interessant http://www.linuxprinting.org/, a on es troba el repositori universal de tot el relacionat amb la impressió en &Linux; i &UNIX;. Durant molt de temps gran quantitat de desenvolupadors estaven en profund desacord amb l'antic LPD. Diversos nous projectes varen mirar de millorar la impressió: LPRng és l'exemple més conegut. D'altres són PDQ, PPR, PLP, GNUlpr i RLPR. Però cap dels nous programes varen resultar ser un gran avanç; la majoria d'aquests es limitaven a implementar l'antiga especificació del LPD amb unes poques (o unes moltes) noves extensions, el que els feia incompatibles entre ells. Després d'haver vist el desenvolupament de no un, si no de diferents alternatives al venerable LPD d'estil BSD, en Grant Taylor, autor del Linux Printing HOWTO, va alçar la veu per a dir LPD ha de morir! en la seva Campanya per a l'abolició del Line Printer Daemon. Conjuntament amb el vist anteriorment, en el costat de la industria, es varen fer esforços per a superar les conegudes debilitats de LPD. Es va començar amb extensions propietàries de l'antic LPD i es va arribar fins el punt de que &Hewlett-Packard; va intentar establir &HP; JetDirect com a un nou estàndard en la impressió en xarxa. Això va desembocar en més incompatibilitats. Al final, va prendre forma una iniciativa per a definir un nova industria comú i l'estàndard IETF. El Printer Working Group o PWG, una unió de fabricants de maquinari, programari i sistemes operatius, va crear un esborrany del nou Internet Printing Protocol, &IPP;. La versió 1.1 de &IPP; ha estat aprovada per la IETF (Internet Engineering Task Force) com a un estàndard proposat i ara frueix del suport unànime en la industria a Europa, els Estats Units i el Japó. La majoria dels models d'impressores de xarxa actuals incorporen suport per a &IPP; junt amb el tradicional LPR/LPD o per a la impressió JetDirect. &IPP; promet resoldre molts dels problemes als que s'enfronten els administradores de xarxa. Aquest col·lectiu normalment ha d'ocupar-se d'entorns de xarxa heterogenis i passa més de la meitat de les seves hores de treball resolent problemes d'impressió. Al crear un conjunt únic de funcions de consulta per a les impressores i els servidors compatibles amb &IPP;, per a la transferència de fitxers i l'establiment d'atributs de control de tasques entre altres coses, &IPP; està destinat a funcionar en totes les plataformes i sistemes operatius. De tota manera, la implantació no va a produir-se de manera immediata, ja que molts dispositius d'impressió antics seguiran en ús durant diversos anys. Pel que, en &IPP; es preveu la compatibilitat amb qualsevol implementació anterior de &IPP;. ∪︀ proveeix la viabilitat de la impressió &IPP; en tots els entorns. Sense dubte el seu major avantatge serà la integració en el conjunt existent d'altres protocols IP robustos. Al ser una extensió del provat i robust protocol HTTP 1.1, per a la tasca especial de manejar fitxers i dades relacionades, també resulta molt simple afegir-li d'altres estàndards a mesura que es van desenvolupant: Autenticació bàsica, organitzada i certificada per als usuaris que desitgen accedir als serveis d'impressió. Xifratge SSL3 i TLS per a la transferència de dades. Comunicació bidireccional entre els clients i els dispositius d'impressió, usant els mecanismes GET i POST de HTTP/&IPP;. Integració amb el servei de directori LDAP per a mantenir una base de dades consistent d'impressores disponibles, les seves capacitats i els costos per pàgina, &etc;, així com contrasenyes d'usuari, les ACL, &etc;. Impressió de recollida (en oposició al model tradicional d'impressió per enviament), a on el servidor o la impressora tan sols han de ser informats de la &URL; d'un document, per a poder-lo rebre des del recurs sobre la Internet i imprimir-lo. Heu vist alguna vegada una demostració de les capacitats de ∪︀ en la xarxa? Segurament us haureu quedat molt impressionat si no teníeu una idea prèvia del que anava a succeir. Imagineu que sou l'administrador d'una xarxa local. Amb el propòsit de realitzar unes proves heu instal·lat un sistema &kde;/∪︀ a la vostra xarxa, junt amb una dotzena d'impressores configurades i funcionant: Impressores làser &PostScript;, d'injecció de tinta, &etc; Els usuaris de &kde; d'aquest sistema estan feliços i contents, ja que poden imprimir com mai ho havien fet, podent accedir a tots els ítems de cada impressora. Heu tardat 2 hores en tenir-ho tot funcionant a la perfecció... i ara 100 usuaris de la xarxa volen un el mateix. Dues hores més en cada sistema? Creieu que és impossible acabar-ho abans de l'any que ve? Doncs aneu errat! Simplement amb que canvieu un paràmetre en el sistema ∪︀ original per a convertir-lo en un servidor. Instal·leu ∪︀ en els altres cinc sistemes, com a client. En el moment en el que torneu al vostre primer sistema, trobareu als usuaris jugant feliçment amb els paràmetres de la dotzena d'impressores que havíeu instal·lat en el servidor. D'alguna manera màgica les impressores han aparegut en tots els diàlegs de la impressió dels cinc nous sistemes client de ∪︀. Els seus usuaris poden imprimir, però no s'ha instal·lat ni un controlador en els clients, ni tan sols s'han definit cues d'impressió. Llavores, quin és el truc? La resposta no és de cap manera complicada. Si en la xarxa local hi ha un servidor ∪︀, aquest envia els noms de totes les impressores disponibles, usant el protocol UDP i el port 631. El port 631 està reservat com a un port conegut per la IANA (l'Autoritat d'assignació de números d'Internet) per als propòsits de &IPP;. Tots els clients ∪︀ esperen informació d'un servidor ∪︀ en el port 631. D'aquesta manera és com tenen notícia de les impressores disponibles i també és així com coneixen la ruta cap a aquestes impressores. Usant &IPP;, el qual en realitat és una intel·ligent extensió per a HTTP v1.1, ∪︀ és capaç d'adreçar tots els objectes relacionats amb el sistema d'impressió a través de localitzadors universals de recursos (Universal Resource Locators o URL). Ja siguin tasques d'impressió per eliminar o reiniciar, impressores per a ser consultades o modificades, o tasques d'administració per a realitzar en el servidor, amb &IPP; i ∪︀ es pot accedir a qualsevol recurs a través d'una URL determinada. Moltes de les coses més importants es poden fer a través de la interfície web de ∪︀, la qual és accessible, per exemple, amb &konqueror;. I encara més, els clientes bàsicament poden administrar i usar qualsevol impressora de la que tinguin noticia, de la mateixa manera que si fossin una impressora local. Òbviament això es pot restringir a través de llistes de control d'accés, &etc;, de manera que cap client no pugui usar qualsevol impressora de la manera que vulgui. Els clientes poden fins i tot imprimir sense tenir el filtre (o controlador) adequat instal·lat localment. Com funciona això? Si un client vol conèixer i seleccionar les opcions específiques d'una impressora, envia una petició (anomenada CUPS-get-ppd) al servidor. El servidor informa al client de totes les opcions específiques de la impressora, tal i com les ha llegit &PPD; al costat del servidor. L'usuari del client pot veure les opcions i seleccionar les que requereixi. Llavores envia al servidor d'impressió el fitxer a imprimir, normalment &PostScript; en brut sense filtrar, amanit amb les opcions específiques de la impressora, usant &IPP; com a protocol de transport. Tota la resta del procés, especialment el filtratge per a generar el format final adequat per a la impressora en concret, es realitza en el servidor. El servidor disposa dels programes necessaris (controladors o filtres) per a fer-ho. D'aquesta manera un client pot imprimir sense la necessitat de tenir instal·lat un controlador localment. Qualsevol canvi en el servidor, com l'afegit o modificació d'una impressora, és conegut a l'instant pels clients, sense que sigui necessari cap altra tipus de configuració. Algunes altres de les característiques avançades que es troben integrades en ∪︀, són la possibilitat de fer balanceig de càrrega. Si definiu les mateixes cues d'impressió en dos o més servidors diferents, els clients enviaran els seus treballs al primer servidor disponible o que respongui. Això implica un balanceig de càrrega automàtic entre els servidors. Si necessiteu retirar de la xarxa un servidor per a realitzar tasques de manteniment, els altres s'ocuparan de les seves tasques sense que l'usuari arribi a notar la diferència.