Selle peatüki siht on anda veidi teoreetilist tausta trükkimise kohta üldiselt ning eriti ∪︀i kohta. Kui sa seda ei vaja, võid kohe edasi tõtata järgmise peatüki juurde. Kuid on usutav, et millalgi jõuad siiski siia tagasi, sest vahel võib natuke teooriat mõne praktilise probleemi lahendamisel marjaks ära kuluda. Trükkimine on keerukaimaid IT-tehnoloogia osasid. Kunagi ammustel aegadel pidi iga sellise rakenduse arendaja, mis suutis tekitada trükitava väljundi, kirjutama ise ka printeridraiveri. See oli päris keeruline, sest erinevatel rakendustel on ju erinevad failivormingud. Isegi ühelaadsed rakendused, näiteks tekstitöötlusrakendused, ei saa sageli üksteise vormingust aru. Seepärast puudus ka ühine liides kõigile printeritele, sest programmeerijad kirjutasid oma draiverid sageli vaid mõnd üksikut mudelit silmas pidades. Kui turule ilmus uus seade, pidi rakenduse autor sellele uue draiveri kirjutama, kui ta soovis, et rakendus seda toetaks. Ka tootjad ei saanud sugugi kindlad olla, et nende seadet üldse mõni maailmas tuntud rakendus toetab (kuigi viimaseid oli toona palju-palju vähem kui praegu). Kui süsteemiadministraator pidi tegelema kümne rakenduse ja tosina printeriga, tähendas see ühtlasi tegelemist nii umbes 120 draiveriga. Seepärast muutus rakenduste ja printerite vahelise ühtse liidese väljatöötamine lihtsalt hädavajalikuks. Suure tühimiku täitis lehekülje kirjeldamise keelte (PDL) teke, mis kirjeldasid üldiselt tindi ja tooneri graafilist esitust paberilehel (või muudel väljundseadmetel, näiteks monitoridel, fotolaomasinatel &etc;). Üks selliseid oli Adobe loodud &PostScript;. See tähendas, et rakenduse programmeerija võis nüüd keskenduda sellele, kuidas panna oma rakendus genereerima trükitaval leheküljel &PostScript; keelt, printerite tootjad aga sellele, kuidas õpetada oma seadmeid &PostScript;-ist aru saama. Aegamööda ilmus teisigi kirjeldusmeetodeid. &PostScript; tähtsaimad võistlejad olid PCL (&Hewlett-Packard; trükkimise kontrollkeel), ESC/P (Epson) ja GDI (&Microsoft; graafilise seadme liides). Lehekülje kirjeldamise keelte teke muutis kõigi elu hõlpsamaks ning soodustas edasist arendustegevust. Kuid endiselt panid kasutajate, administraatorite, arendajate ja tootjate pea valutama erinevad, omavahel sobimatud ning konkureerivad kirjelduskeeled. &PostScript; on kõige kasutatavam professionaalsetes trükikeskkondades, näiteks PrePress ja trükitööstus. &UNIX; ja &Linux; maailmas on &PostScript; domineeriv PDL-standard. Seepärast genereerib peaaegu iga rakendus lehekülgede esituse &PostScript;-is, kui vajutada nuppu trüki. Vaatame korraks lihtsat (käsitsi loodud) &PostScript; koodi. Järgnev tekst kirjeldab kaht lihtsat joonistust: %!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 See annab &PostScript; kujuteldavale sulele käsu joonistada teatud tüüpi kujund ning täita see siis halli erinevate toonidega. Esimene osa tähendab inimlikumas keeles Mine koordinaadile (100,100), tõmba joon pikkusega 50 üles, siis joon sealt paremale, siis alla ja siis tagasi alguspunkti. Seejärel täida kujund 70%-lise tumedusega halliga näide teisendatud pildina. &PostScript; võib mõistagi täita märksa keerukamaid ülesandeid. See on võimas programmeerimiskeel paljude operaatorite ja funktsioonidega. On võimalik kirjutada isegi &PostScript; rakendusi, mis arvutavad pii väärtust, vormindavad kõvaketta või kirjutavad faile. &PostScript; peamine väärtus ja tugevus seisneb siiski selles, et ta suudab kirjeldada graafiliste objektide esitust leheküljel: ta võib skaleerida, peegeldada, tõlgendada, töödelda, pöörata ja moonutada kõike, mida on üldse võimalik paberile kanda, see tähendab kõikvõimalikes kirjatüüpides märke ja tähti, kujundeid, varje, värve, jooni, punkte, rastrit... &PostScript; fail kujutab endast ühe või mitme trükitava lehekülje suhteliselt abstraktset esitust. Ideaalis peaks ta kirjeldama lehekülgi seadmest sõltumatul viisil. &PostScript; ei ole sõna otseses mõttes nähtav, ta elab ainult kõvaketastel ja RAM-is tulevaste väljatrükkide kodeeritud esitusena. Paberilehel nähtav on peaaegu alati rasterkujutis. Isegi kui silmad paistavad ütlevat, et tegemist on joonega, võta korralik luup ja sa näed, et joone asemel on hulk tillukesi punkte... (Näide vastupidisest on jooned, mis on tõmmatud sulgplotteriga.) See ongi ainus asi, mida tänapäeva printerite märkemootorid suudavad paberile kanda: tavalised punktid, erinevuseks vaid nende värv, suurus ja lahutusvõime, mille abil luuakse erinevatest bittrastrite mustritest koosnev leheküljekujutis. Erinevad printerid vajavad erinevat rasterkujutise ettevalmistusviisi. Näiteks tindiprinteri puhul sõltub lahutusvõimest, kasutatavate tintide hulgast (parimatel võib olla seitse erinevat tinti, odavamatel kõigest kolm), düüside arvust (mõnel trükipeal võib neid olla üle saja!), mis võivad korraga tinti väljastada, kasutatavast pseudotoonimise algoritmist ja veel paljust muust rastri lõplik vorming ning ülekandeviis märkemootorile ehk teisisõnu sõltub kõik väga tugevasti konkreetsest printerimudelist. Kunagi ammu, veel reaprinterideemonite elupäevil, olid printerid masinad, mis tagusid mehhaaniliselt ASCII-teksti ridu pikale siksakilise maona kokku pakitud paberilohele, mis venis välja laua all seisvast suurest karbist... Oh, kuidas ajad on muutunud! Enne seda, kui lõplikud rasterkujutised paberilehtedele kantakse, tuleb nad kuidagi abstraktsest &PostScript; esitusest välja tuletada. See kujutab endast päris mahukat arvutamistegevust, mis kannab nimetust rastriprotsess (tavaliselt lühendina RIP). &PostScript; printerite puhul võtab RIP-pimise enda peale seade ise, talle tuleb vaid &PostScript;-fail ette anda. Printeris asuv rasterprotsessor (ka selle puhul kasutatakse lühendit RIP) vastutab (ja enamasti tuleb ka päris hästi toime) &PostScript; lehekülje kirjelduse tõlgendamise ning rasterkujutise paberile kandmisega. Väiksemad &PostScript; seadmed kasutavad riistvaralist RIP-i, mis asub erilisel kiibil. Suurematel professionaalsetel printeritel on RIP tihti tarkvaraline, asudes spetsiaalses kiires &UNIX;-põhises arvutis, enamasti Sun SPARC Solaris või &SGI; &IRIX; masinal. Kuid mis saab siis, kui &PostScript; printerit ei ole? RIP-pimine tuleb ette võtta enne trükiandmete saatmist märkemootorile. Selleks tuleb esitada &PostScript;, mille on loonud kasutatav rakendus masinal (trükkimise kliendil) endal. Peab ka täpselt teadma, milline näeb välja sihtprinteri märkemootori rastrivorming. Kuna pole võimalik tugineda printeri oskusele mõista ja tõlgendada &PostScript;-i, muutub kõik märksa keerulisemaks: vaja läheb tarkvara, mis suudaks probleemid lahendada. Just seda teebki kõikjale jõudev &ghostscript; paljudel &Linux;, *BSD ja muudel &UNIX; masinatel, mis peavad trükkima mitte-&PostScript; printeritele: &ghostscript; on &PostScript; tõlgendaja, tarkvaraline RIP, mis suudab töötada paljude erinevate seadmetega. &PostScript; sisendist rasterdatud bittrastrite loomiseks kasutab &ghostscript; niinimetatud filtreid. &ghostscript;i paketti kuulub hulk filtreid, osa neist spetsiaalselt teatud printerimudelitele mõeldud. &ghostscript;i filtrid on sageli välja töötatud ilma tootjapoolse teadmise või toeta. Spetsifikatsiooni ja dokumentatsioonita kujutab see endast väga vaevarikast protokollide ja andmevormingute lahtiharutamist. Mitte kõik &ghostscript;i filtrid ei tööta ühtmoodi hästi kõigi printeritega. Mõned uuemad, näiteks projekti Gimp Print stp filter, annavad aga suurepäraseid, fotokvaliteedini ulatuvaid tulemusi, olles mõnikord paremad isegi &Microsoft; &Windows; konkureerivatest draiveritest. &UNIX; ja &Linux; puhul tekitab enamik rakendusi trükkimiseks just &PostScript;-i. Seepärast on filtrid siin lihtsalt asendamatud. Põhimõtteliselt tekitavad nad suvalisest &PostScript;-sisendist korrektsed bittrastrid mitte-&PostScript; märkemootoritele. ∪︀ kasutab omaenda filtreid, kuigi temagi filtrisüsteemi aluseks on Ghostscript. Ennekõike filtrid pstoraster ja imagetoraster on otseselt arendatud Ghostscripti koodist. ∪︀ on selle suletud koodi ümber korraldanud ja mehaanikat parandanud ning organiseerinud mõneks selgelt eristatavaks mooduliks. Järgnev joonis (valmistatud &kivio; abil) annab ülevaate ∪︀is toimivatest filtritest ja taustarakendustest ning nende omavahelistest suhtest. Kulg suundub ülalt alla. Taustarakendused on erilised filtrid, mis ei teisenda andmeid uude vormingusse, vaid saadavad valmis failid printerile. Erinevad ülekandeprotokollid kasutavad erinevaid taustarakendusi. &kprinter;i dialoogi käivitamine (&kivio; joonistus) &kprinter;i dialoogi käivitamine (&kivio; joonistus) Lisaks trükivalmis bittrastri loomiseks vajalikule raskele ja mahukale filtreerimisele vajab igasugune trükkimistarkvara spuulimismehhanismi, see tähendab meetodit, kuidas reastada erinevate kasutajate erinevatele printeritele ja filtritele lähetatud erinevad tööd ning saata nad vastavalt sihtkohale edasi. Selle eest kannab hoolt trükkimisdeemon. Deemon hoiab nii-öelda maja korras ning vastutab ühtlasi trükitööde kontrolli eest: kasutajatel peaks üldiselt olema lubatud oma (aga mitte teiste) töid peatada, tühistada, taaskäivitada &etc; Nüüd, kui oled saanud mingi arusaama, kuidas &PostScript; keele fail (mis kirjeldab lehekülje väljanägemist üldiselt seadmest sõltumatult) teisendatakse rasterkujutiseks, võib tekkida küsimus: Aga olemas on ju mitut tüüpi rasterväljundseadmeid, mis erinevad lahutusvõime ja paberisuuruse poolest ja on väga erinevad ka mitmesuguste viimistlusvõimaluste poolest (duplekstrükk, brošüürid, perforeeritud ja köidetud väljund erinevatest salvedest pärit erinevat värvi paberil &etc;). Kuidas see kõik saab olla jõukohane seadmest sõltumatule &PostScript;-ile? Vastus peitub niinimetatud &PostScript; printeri kirjeldamise (&PPD;) failides. &PPD; kirjeldab kõiki seadmepõhiseid omadusi, mida konkreetne printerimudel saab kasutada. Selles on ka kodeeritud käsud, mida tuleb kasutada seadme teatud omaduse väljakutsumiseks. Kuid &PPD; ei ole mitte suletud raamat, vaid lihtsakoelised ASCII tekstifailid. &PPD; leiutamise au kuulub Adobele, kes püüdis muuta tootjatel lihtsamaks oma võimaluste rakendamise &PostScript; printerites ning samal ajal luua selleks standardse meetodi. Adobe on &PPD;-de dokumentatsiooni ja kirjeldamise eest hästi hoolt kandnud. Sisuliselt on nende spetsifikatsioonid vabavara. Pea meeles, et algupäraselt loodi täiustatud &PostScript; trükkimise võimalus &Microsoft; &Windows; ja Apple &Mac; süsteemi tarbeks. Kaua aega ei olnud kõik moodsate seadmete rikkalikud trükkimisvõimalused &Linux; ja &UNIX; puhul lihtsalt kasutatavad. Otsustava muutuse tõi kaasa ∪︀. ∪︀ on väga tihedalt seotud &PPD;-dega ning seepärast saavad kõik ∪︀i kasutavad süsteemid täiel määral pruukida olemasolevate &PPD;-de võimalusi. &PPD;-de abil saavad printeritootjad kasutada oma toodetes seadmepõhiseid riistvaralisi võimalusi, näiteks duplekstrükk, köitmine, perforeerimine &etc; Printeridraiverid laevad &PPD;-d, nagu oleks need lihtsalt täiendavad seadistustefailid. Nii saab printeri draiver teada seadme võimalustest ja viisidest nende väljakutsumiseks, samuti saab draiver neid &GUI; kujul kasutajale näidata. Seda mehhanismi kasutades saab kasutaja endiselt luua seadmest sõltumatu&PostScript; lehekülje kirjeldamise faili ning määrata seadmepõhised viimistlustingimused, mis lisatakse rakenduse loodud &PostScript;-ile. &PPD; ei leidnud alguses sugugi mitte sageli kasutamist &UNIX; ja &Linux; süsteemides. &PPD;-sid pakkuvad tootjad pidasid nende loomisel ikka ja ainult silmas &OS;e, millele need algselt mõeldud olidki: &Microsoft; &Windows; ja &MacOS;. Hiilgav mõte täielikult toetada ja ära kasutada olemasolevaid &PPD; spetsifikatsioone on lubanud ∪︀il pakkuda kõiki moodsate printerite hiiglaslikke võimalusi &Linux; ja &Linux;-laadsete süsteemide kasutajatele. &kdeprint; muudab aga selle kasutamise veel lihtsamaks, kui ∪︀i arendajad isegi unistada oskasid. ∪︀ suudab kasutada &Windows; &PPD;-sid, mida tootjad levitavad koos &PostScript; printeritega. Need on tavaliselt tasuta ning neid võib hankida igast &Windows; arvutist, kuhu on paigaldatud vastava mudeli &PostScript; draiver, või siis printeriga kaasasolevalt kettalt. Neid leiab ka mitmelt poolt veebist. Nüüd on teada, kuidas kasutavad &PostScript; printerid &PPD;-sid. Aga mitte-&PostScript; printerid? ∪︀ on trikiga hakkama saanud: kasutades sama vormingut ja andmestruktuuri, mida pruugivad &PostScript; printeri kirjeldused (&PPD;-d) &PostScript; maailmas, suudab ta täpselt samamoodi kirjeldada saadaolevaid trükitöö võimalusi ka mitte-&PostScript; printeritele. ∪︀ on oma vajaduste rahuldamiseks lisanud küll mõned read (ennekõike rea, mis määrab filtri, mida kasutada &PostScript;-faili edasiseks töötlemiseks). Nii saavad arendajad kasutada üht ja sama tarkvaramootorit printeri kirjeldamise failide analüüsimiseks, et leida mis tahes printeri saadaolevad võimalused. Mõistagi ei saanud ∪︀i arendajad loota, et mitte-&PostScript; printerite tootjad hakkavad järsku agaralt &PPD;-sid produtseerima. Nad pidid selle keerulise tegevusega ise alustama ning PPD-d nullist peale valmis kirjutama. Praegu on neid juba üle tuhande ∪︀i kommertsversioonis ESP PrintPro. Samal ajal on ilmunud ka hulk ∪︀ipõhiseid &PPD;-sid. Kuid isegi praegu ei ole enamik pärit mitte printeritootjatelt, vaid vabavara arendajatelt. ∪︀i rahvas on sellise arengu heaks kiitnud ning tulemused ei ole jäänud tulemata: kui trükkimine &Linux; ja &UNIX; süsteemides oli veel mõne aasta eest tõeline imetegu, siis nüüd on tugi olemas väga paljudel printeritel, sealhulgas seitsmetindilistel printeritel, mis võimaldavad fotokvaliteediga trükki. &PPD;-sid, mida kasutada ∪︀i ja mitte-&PostScript; printeritega, leiab mitmelt poolt veebist: esiteks www.linuxprinting.org hoidlast, kus saab otse veebileheküljel luua CUPS-O-Matic &PPD; suvalisele printerile, mida traditsiooniline &ghostscript;iga trükkimine juba toetab. See aitab soovi korral hõlpsasti üle minna ∪︀i kasutamisele. Kui printer tuleb korralikult toime traditsioonilise &ghostscript;-trükkimisega, kasuta CUPS-O-Maticut oma draiveri ühendamiseks ∪︀-süsteemiga ja sa võid nautida parimat, mida kahe maailma liit pakkuda suudab. teiseks on ∪︀i &PPD;-d olemas enam kui 120 printerimudelile, mida juhib uus universaalne stp-draiver. stp (algselt Stylus Photo tähistus) arendamine on nüüd projekti gimp-print kätes. Selle algatas ∪︀i juhtivamaid arendajaid Mike Sweet ning praegu leiab selle aadressil gimp-print.sourceforge.net. See draiver suudab trükkida tõelise fotokvaliteediga suurel osal moodsatel tindiprinteritel ning seda on võimalik panna kasutama 120 ∪︀i &PPD;-d. Muu hulgas sobib see kokku &HP; laser- ja tindiprinteritega, Epson mudelitega Stylus ja Photo Color, samuti Canon ja Lexmark mõne mudeliga. kolmandaks on olemas ∪︀i arendajate välja töötatud ∪︀i kommertsvariant, mis kannab nime ESP PrintPro ja millega on kaasas enam kui 2300 printeridraiverit, sealhulgas isegi täiustatud imagetoraster ja pstoraster filtrid. ∪︀ on teinud tootjatele äärmiselt lihtsaks toetada trükkimist nende mudelitega &Linux; ja &UNIX; süsteemides mõistlikult odava hinna eest. ∪︀i mooduljas ülesehitus võimaldab kaasata iga filtri (= draiveri) minimaalse vaevaga ning pääseda ligi ja kasutada kogu ∪︀i pakutavat trükkimisraamistikku. ∪︀i vaimustavate omadustega saab lähemalt tutvuda ∪︀i dokumentatsiooni abil aadressil http://www.cups.org/documentation.html ja http://www.danka.de/printpro/faq.html. Lisaks sellele kujutab http://www.linuxprinting.org/ endast universaalset hoidlat kõige kohta, mis on seotud trükkimisega &Linux; ja &UNIX; süsteemides. Paljud arendajad tundsid aegamööda üha suuremat rahulolematust iidse LPD-ga. Trükkimise edendamiseks alustati üsna mitme uue projektiga. Parim näide on ilmselt LPRng, mille kõrval nägid ilmavalgust ka PDQ, PPR, PLP, GNUlpr ja RLPR. Ükski neist aga ei suutnud saavutada läbimurret, enamik pelgalt rakendas ikka sedasama LPD spetsifikatsiooni, lisades mõne (või ka terve hulga) uusi võimalusi, mis paraku muutis nad teistega kokkusobimatuks. Nähes, kuidas auväärsele BSD stiilis LPD-le tekib mitte ainult üks, vaid mitu erinevat elujõulist alternatiivi, käis lõpuks Linuxi trükkimise HOWTO autor Grant Taylor välja loosungi LPD peab surema!, alustades kampaaniat reatrükkimisdeemoni kaotamiseks. Kirjeldatu kõrval püüti ka tööstuse poolel üle saada LPD teada-tuntud nõrkustest. See algas firmapõhiste täienduste lisamisega LPD-le ning jõudis lõpuks välja selleni, et &Hewlett-Packard; püüdis oma &HP; JetDirecti kehtestada uue standardse võrgutrükkimisprotokollina. Tulemuseks oli aga veelgi suurem erinevate süsteemide omavaheline sobimatus. Lõpuks hakkas ilmet võtma uue, tööstuse ja IETF-i ühine standard. Printeri töögrupp ehk PWG (see kujutas endast lõdvalt seotud riistvara, tarkvara ja operatsioonisüsteemide tootjate ühendust) lõi uue internetitrükkimise protokolli &IPP;. &IPP; v1.1 on nüüdseks saanud IETF (Interneti tehniline operatiivkogu) heakskiidu standardina ning töösturid nii Euroopas, USAs kui Jaapanis toetavad seda üksmeelselt. Suuremal osal praegustel võrguprinteritel on lisaks traditsioonilisele LPR/LPD või JetDirecti toele ka &IPP; tugi. &IPP; võimaldab lahendada terve hulga võrguadministraatorite ees seisvaid probleeme. Tavaliselt on neil ju tegemist mitmekesise keskkonnaga ning sageli kulub enam kui pool nende tööajast just trükkimisprobleemide lahendamisele. &IPP;, millele on loodud &IPP;-ga ühilduvate printerite ja serverite ühtne päringufunktsioonide komplekt failide edastamiseks, trükitöö juhtatribuutide seadistamiseks &etc;, on kavandatud töötama kõigis &OS;ides. Üleminek ei juhtu siiski üleöö, sest paljud varasemad trükiseadmed on kahtlemata veel aastaid kasutusel. Seepärast näeb &IPP; ette tagasiühilduvuse kõigi &IPP; versioonidega. ∪︀ aga tõestab &IPP; trükkimismeetodi elujõulisust kõigis keskkondades. Tema kõige löövam külg on aga integreeritus muude olemasolevate ja oma töökindlust näidanud IP protokollidega. Kujutades endast tõestatult kvaliteetse protokolli HTTP 1.1 laiendust spetsiifiliselt trükifaili ja sellega seotud andmete käsitlemiseks, on seda ka väga hõlpus ühendada muude arendatavate ja kasutusele tulevate standarditega: Basic, Digest ja sertifitseerimisautentimine trükiteenuseid tarbida soovivatele kasutajatele. SSL3 ja TLS krüptimine andmeedastusel. Klientide kahesuunaline kommunikatsioon trükiseadmetega HTTP/&IPP;, GET ja POST vahendusel. LDAP kataloogiteenus, mis võimaldab pidevalt aktuaalsena hoida saadaolevate printerite, nende võimaluste, kulude &etc; andmebaasi, samuti paroole, ACL-e &etc; Tõmbav (vastandina tavapärasele tõukavale) trükkimine, kus serverile või printerile on vaja vaid anda dokumendi &URL;, misjärel see ise hangib selle internetist ja trükib. Oled sa kunagi näinud, mida ∪︀ õigupoolest võrgus suudab? Kui sa varem sellest midagi ei teadnud, peaks see päris rabavalt mõjuma. Kujuta ette, et oled kohtvõrgu administraator. Oled testimiseks paigaldanud võrku ühe täisväärtusliku &kde;/∪︀-masina, milles on seadistatud ja töökorda seatud kümneid printereid, olgu need siis &PostScript;, laser-, juga-, mullprinterid või mis tahes. Kõik &kde;-masina kasutajad on äärmiselt õnnelikud, sest nad võivad trükkida nagu ei kunagi varem, suutes võtta igast printerist välja viimase. Sul kulus kaks tundi, et kõik korralikult tööle hakkaks... ja nüüd tahavad kõik sada võrgus olevat inimest kogeda sedasama! Kaks tundi iga masina peale? Ei, enne järgmist aastat ma sellega küll hakkama ei saa, käib sul peas ringi. Unusta see. Vaid üks väike liigutus algupärases ∪︀-masinas ja see muutub serveriks. Paigalda ∪︀ veel viiele masinale, sedakorda kliendina. Selleks ajaks, kui esimese kasutaja juurde tagasi jõuad, leiad, et ta juba proovib juba õnneliku näoga nende kümnete printerite seadistusi, mida varem määrasid serverile. Otsekui ime läbi on need ilmunud kõigi viie ∪︀-kliendi trükkimisdialoogi. Kasutajad asuvad rõõmsalt trükkima, ometi ei ole klientidele paigaldatud ühtegi draiverit ega määratud trükijärjekorda. Kuidas see ime siis teoks saab? Vastus ei ole sugugi keeruline. Kui ∪︀i server asub kohtvõrgus (LAN), levindab see kõigi saadaolevate printerite nimed LAN-i, kasutades protokolli UDP ja porti 631. IANA (Internetinumbrite eraldamise kogu) on reserveerinud pordi 631 tuntud pordina &IPP; vajadustele. Kõik ∪︀i kliendid näevad ∪︀i serveri infot, mis jõuab nende porti 631. Nii saavadki nad teada olemasolevatest printeritest ning ühtlasi rajast, mis printerini viib. &IPP; abil, mis kujutab endast igati nutikat HTTP 1.1 laiendit, suudab ∪︀ anda kõigile trükkimissüsteemiga seotud objektidele üldise ressursiaadressi ehk URL-i. Trükitööde eemaldamine või taaskäivitamine, printerite uurimine või muutmine, serveri haldustööd - kõik see on &IPP; ja ∪︀i abil taandatav teatud URL-ile. Päris palju tähtsaid asju saab korda ajada ∪︀i veebiliidesega, mida saab kasutada näiteks &konqueror;is. Lisaks sellele saavad ka kliendid põhimõtteliselt hallata ja kasutada iga nähtavat printerit, nagu oleks see otse nende masinaga ühendatud. Loomulikult on administraatori ülesanne seada sellele piiranguid ligipääsu kontrollimise nimekirjadega &etc;, et mitte ükski klient ei saaks kasutada iga ja kõiki printereid oma suva kohaselt. Kliendid saavad trükkida isegi siis, kui vastavat filtrit (või draiverit) ei ole nende masinale paigaldatud. Kuidas see siis käib? Kui klient soovib teada saada ja valida printeripõhiseid võimalusi, saadab ta soovi (käsu CUPS-get-ppd) serverile. Server teatab kliendile kõik printeripõhised võimalused, nagu ta need enda valduses olevalt &PPD;-lt välja loeb. Kliendi poolel asuv kasutaja näeb võimalusi ja valib soovikohased välja. Seejärel saadab ta trükifaili, tavaliselt filtreerimata toor-&PostScript;-i, millele on lisatud printeripõhised võimalused, &IPP;-d edastusprotokollina kasutades printserverile. Kogu edasise töötluse, ennekõike just filtreerimise printerile saadetava lõpliku vormingu loomiseks, võtab enda kanda server. Sellel on ka olemas vajalikud rakendused (draiverid või filtrid). Nii ongi kliendil võimalik trükkida, ilma et tema masinasse oleks vaja ühtegi draiverit paigaldada. Suvaline muutus serveril, näiteks printeri lisamine või muutmine, levib tuntud klientidele automaatselt, ilma igasuguse täiendava seadistamise vajaduseta. ∪︀i mõningad täiustatud omadused suudavad näiteks koormust jagada. Kui määrata ühesugune trükijärjekord kahele või enamale serverile, saadavad kliendid oma töö esimesele vastavale või kättesaadavale serverile. Sellega kaasneb automaatne koormuse jagamine serverite vahel. Kui mõni serveritest võrgust ära võtta, näiteks haldustöödeks, võtavad teised tema ülesanded üle, ilma et kasutajad mingit vahet märkakski.