| Noget teoretisk baggrundsmateriale om: CUPS, IPP, PostScript® og Ghostscript |
| forrige | næste |
Indholdsfortegnelse
Formålet med dette kapitel er at give en smule af den teoretiske baggrund for udskrift i almindelighed og for CUPS i særdeleshed. Hvis du ikke har brug for dette vil du måske hellere skippe frem til næste kapitel. Jeg vil regne med du kommer tilbage til dette kapitel på et eller andet tidspunkt alligevel, for sommetider har man brug for lidt ekstra teori for at løse et praktisk problem.
Udskrift er et af de mere komplicerede kapitler i IT-teknologi.
Tidligere i historien måtte enhver udvikler af et program, der skulle kunne producere udskriveligt materiale ud, også selv skrive sine egne printer-drivere. Dette var temmelig kompliceret, fordi forskellige programmer har forskellige filformater. Selv programmer med det samme formål, for eksempel, tekstbehandlingsprogrammer, forstår ofte ikke hinandens formater. Der var derfor ingen fælles grænseflade for alle printere, og derfor understøttede programmørerne ofte kun nogle få udvalgte modeller.
Når en ny enhed kom på markedet var det nødvendigt at programforfatterne skulle skrive en ny driver, hvis de ønskede deres program skulle understøtte den. Det var også umuligt for fabrikanter at sørge for at deres enhed var understøttet af noget som helst program i hele verden (selvom der var langt færre end i dag).
Det at skulle understøtte ti programmer og et dusin printere betød, at en systemadministrator skulle håndtere 120 drivere. Så udviklingen af forenede grænseflader mellem programmer og printere blev et påtrængende behov.
Fremkomsten af “Sidebeskrivelsessprog”, som beskriver den grafiske repræsentation af blæk og toner papirark (eller andre uddata enheder som skærme fotosættere, osv.) i på en fælles måde udfyldte et stort tomrum.
En sådan udvikling var PostScript® af Adobe. Det betød at en programmør kunne koncentrere sig om at få programmet til at lave en PostScript®-sprog beskrivelse af udskriftssiden, mens udskriftsenhed-udviklerne kunne fokusere på at få deres enheder til at forstå PostScript®.
Naturligvis kom der med tiden en udvikling af andre beskrivelsesmetoder. De vigtigste konkurrenter til PostScript® var PCL (“Print Control Language”, fra Hewlett-Packard®), “ESC/P” (fra Epson) og GDI (“Graphical Device Interface” fra Microsoft®).
Fremkomsten af disse sidebeskrivelsessprog gjorde livet nemmere og hjalp udviklingen for alle. Men det faktum at der stadig var forskellige, inkompatible og konkurrerende sidebeskrivelsessprog gør livet svært nok endda for brugere, administratorer, udviklere og fabrikanter.
PostScript® er den mest brugte i professionel printmiljøer såsom PrePress og udskriftsservice industrier. Indenfor UNIX® og Linux® domænerne, er PostScript® den dominerende standard som et PDL. Her genererer næsten alle programmer en PostScript®-repræsentation af dens sider når du trykket på “Udskriv”-knappen. Lad os kigge på et simpelt eksempel på (hjemmelavet) PostScript®-kode. Følgende listning beskriver to simple tegninger:
Eksempel 4.1. PostScript®-kode
%!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
Dette beder den imaginære PostScript®-“pen” om at tegne en sti af en bestemt form, og så udfylde den med forskellige afskygninger af gråt. Den første del oversættes til mere forståeligt engelsk som “Gå til koordinat (100,100), tegn en linje med længde 50 opad; så en derfra til højre, så ned igen, og tilsidst lukkes denne del af. Udfyld nu den tegnede form med 70% grå.”
PostScript® kan naturligvis være meget mere kompliceret end dette simplistiske eksempel. Det er et fuldt udviklet programmeringssprog med mange forskellige operatorer og funktioner. Du kan endog skrive PostScript®-programmer der beregner Pi's værdi, formatere en disk eller skriver til en fil. Hovedværdien og styrken ved PostScript® er imidlertid i evnen til at beskrive layout af grafiske objekter på en side: den kan også skalere, spejle, translatere, transformere, rotere og forvrænge alt du kan forestille dig på et stykke papir -- såsom bogstaver i forskellige skrifttyperepræsentationer, figurer, forme, skygger, farver, linjer, prikker, raster...
En PostScript®-fil er en repræsentation af en eller flere sider der skal udskrives, beskrevet på en relativ abstrakt måde. Ideelt set er det meningen at siderne skal beskrives uafhængigt af enheden. PostScript® er ikke direkte “synlig”; det lever kun på disken og i RAM som en indkodet repræsentation af fremtidige udskrifter.
Det du ser på et stykke papir er næsten altid et “rasterbillede”. Selv om din hjerne får dig til at se en linje: så tag et godt forstørrelsesglas og du vil opdage masser af små prikker... (Et eksempel på det modsatte er linjer der er tegnede med “pen-plottere”). Og det er det eneste som nutidens printeres “markeringsmaskiner” kan putte på papir: simple prikker i forskellige farve, størrelse og resolution til at lave et fuldstændigt “sidebillede” komponeret af forskellige bitmap-mønstre.
Forskellige printere skal have rasterbilledet tilberedt på forskellig måde. Hvis du tænker på en inkjet-enhed: afhængig af dens resolution, antallet af blækpatroner (de meget gode har brug for 7 slags blæk, mens en billigere måske vil bruge 3), antallet af tilgængelige dyser (nogle printhoveder har mere ned 100!) der fordeler blæk samtidigt, “dithering-algoritmen” der bruges og mange andre ting, er det endelige rasterformat og overførselsrækkefølge til markeringsmaskinen stærkt afhængig af den nøjagtige model der bruges.
I et tidligere liv af “Linje Printer Dæmon”, printere, var det maskiner der hamrede rækker af ASCII-tekst mekanisk på lange medier, foldet som en zig-zag papirslange, trukket fra kartonfelte nedenunder bordet... Sikke en forskel til i dag!
Før de endelige rasterbilleder bliver putte på papir skåret ud i ark, skal de beregnes på en eller anden måde ud fra deres abstrakte PostScript®-repræsentation. Dette er en meget beregnings-intensiv proces. Den kaldes “Raster Imaging Process”, eller hyppigere “RIP”).
Med PostScript®-printere bliver RIP-ning sørget for i selve enheden. Du sender blot en PostScript®-fil til den. “Raster Imaging Processor” (også kaldet RIP) indeni printeren er ansvarlig for (og specialiseret til) at udfylde opgaven at fortolke PostScript®-sidebeskrivelserne og putte rasterbilledet på papir.
Mindre PostScript®-enheder har en hardware-RIP indbygget, den skåret i silicon, på en særlig chip. Store professionelle printere har ofte deres RIP implementeret som en software-RIP indeni en dedikeret hurtig UNIX®-kørt computer, ofte en Sun SPARC Solaris eller en SGI™ IRIX® maskine.
Men hvad sker der hvis du ikke er så heldig at du har en PostScript®-printer tilgængelig?
Du bliver nødt til at gøre RIP-ningen før udskriftsdata sendes til markeringsmaskinerne. Du må selv fordøje PostScript® genereret af dit program på værtsmaskinen (udskriftsklienten). Du bliver nødt til at vide hvordan nøjagtige rasterformat for målprinterens markeringsmaskine skal komponeres.
Med andre ord, da du ikke kan regne med at printeren selv kan forstå og fortolke PostScript®, bliver problemet en hel del mere kompliceret. Du har brug for programmel der prøver at løse de involverede problemer for dig.
Dette er nøjagtigt hvad den allestedsnærværende ghostscript-pakke gør for mange Linux®, *BSD og andre UNIX® maskiner der har brug for at udskrive til ikke-PostScript® printere: ghostscript er en PostScript®-fortolker, en programmeret RIP der er i stand til at køre mange forskellige enheder.
For at producere rastede bitmaps fra PostScript® inddata bruges “filter”-begrebet af ghostscript. Der er mange forskellige filtre i ghostscript, nogle af dem specialiseret til en bestemt model af en printer. ghostscript-filter til bestemte enheder er ofte blevet udviklet uden samtykke eller støtte fra vedkommende der fremstillede enheden. Uden adgang til specifikationerne og dokumentation, var det en pinefuld proces at 'reverse engineer' protokoller og dataformater.
Ikke alle ghostscript-filtre virker lige godt for deres printere. Men nogen af de nyere som stp-filtret for Gimp-printprojektet, producerer fremragende resultater der fører til fotografisk kvalitet der er på lige fod eller endog bedre end deres Microsoft® Windows® driver-modstykker.
PostScript® er det de fleste programmer producerer til udskrift i UNIX® og Linux®. Filtre er de sande arbejdsheste for et vilkårligt udskriftssystem der. Det er dem der egentlig producerer de rigtige bitmaps fra en vilkårlig PostScript®-inddata for ikke-PostScript® målmaskiner.
CUPS bruger sine egne filtre selvom filtersystemet er baseret på Ghostscript. Filtrene pstoraster og imagetoraster filters er nemlig direkte afledt fra Ghostscript-kode. CUPS har re-organiseret og strømlinjet hele mekanikken i denne gamle kode og organiseret den i nogle få klare adskilte moduler.
Denne næste tegning (lavet ved hjælp af Kivio) giver et overblik over filtrene og de undeliggende programmer for CUPS og hvordan de passer sammen. “Flydningen” er ovenfra og ned. De underliggende programmer er specielle filtre: de konverterer ikke data til et andet format, men de sender de parate filer til printeren. Der er forskellige underliggende programmer for forskellige overførselsprotokoller.
Foruden den tunge del med at filteropgaven til at generere en udskrifts-parat bitmap, vil udskriftsprogrammel altid behøve en kø-mekanisme: dette er for at sætte forskellige jobs op i rækkefølge fra forskellige brugere til forskellige printere og forskellige filtre og sende dem til deres mål på efter hinanden. Udskriftsdæmonen tager sig af alt dette.
Denne dæmon sørger for husorden: den er også ansvarlig for jobkontrollen: brugere skal have lov til at annullere, stoppe, genstarte osv. deres jobs (men ikke andre menneskers jobs) og så videre.
| forrige | hjem | næste |
| Planer for yderligere udvikling | op | Ekskursion: Hvordan “CUPS” bruger styrken i PPDer |
