Despre printarea fişierelor postscript

Cătălin ŞERBĂNESCU

Deşi tendinţele recente în ceea ce priveşte lanţul de procesare şi printare a documentelor sunt îndreptate spre utilizarea din ce în ce mai mult a formatului PDF (referindu-ne aici la folosirea RIP-urilor APPE – Adobe PDF Print Engine – despre care am discutat într-unul din numerele anterioare ale revistei), atât timp cât pentru trimiterea fişierelor se folosesc în continuare drivere de imprimantă, postscriptul nu va putea fi înlăturat în totalitate. Simplist vorbind, chiar dacă dispunem de un RIP (Raster Image Processor) APPE (şi care, în mod implicit, acceptă direct la intrare documente în format PDF), prin utilizarea unui driver de printare fişierul respectiv este convertit în format postscript, urmând ca ulterior RIP-ul să îl reconvertească în PDF pentru a putea fi procesat prin APPE. Ca o mică paranteză, APPE a apărut, printre altele, ca soluţie la eliminarea erorilor apărute la printarea folosind postscript a documentelor incorect create pentru tipar, cum ar fi cele ce includ transparenţe.

În mod surprinzător totuşi, neeliminându-se driverele de printare postscript, dezideratul amintit nu mai poate fi atins decât dacă documentele sunt întâi convertite în PDF şi apoi importate direct in RIP-ul APPE. Bineînţeles, este imperios necesar utilizarea unui standard PDF pentru tipar de tipul PDF/Xn, despre care am mai vorbit cu prilejul altor articole. Închizând această scurtă paranteză, trebuie să spunem că, atât timp cât folosim drivere postscript, un echipament de tipărire ce dispune de un RIP APPE nu garantează o procesare întotdeauna corectă a oricărui tip de document, referindu-ne aici, cu predilecţie, la programul software utilizat de clientul ce ne furnizează fişierele, fie el MS Word, CorelDraw, Adobe InDesign, Scribus sau altele.
Astfel, mulţi dintre noi ne-am aflat, nu o dată, în faţa unor situaţii de tipul lipsei complete sau printării incorecte a anumitor elemente grafice, deşi, în programul de editare şi generare, documentul este reprezentat „normal”. Şi, de cele mai multe ori, suntem tentaţi să dăm vina pe echipamentul final de printare, aceasta fiind totodată „soluţia” cea mai la îndemână. Cu atât mai mult cu cât, folosind, poate, o imprimantă de birou, lucrările sunt executate corect. Aşadar, fără a mai încerca deloc o analiză a eventualelor cauze, întrebarea care ne acaparează în totalitate este: „De ce pe o imprimantă de 25 de euro documentele sunt printate correct, iar pe una de mii sau zeci de mii nu?”.

Înseamnă acest fapt că echipamentul, achiziţionat poate cu un oarecare efort financiar, este defectuos? Şi dacă nu, există o posibilitate de a determina cu precizie elementul care generează aceste erori? Ne propunem, aşadar, să efectuăm o scurtă analiză a întregului lanţ de procesare postscript, ţelul nostru fiind acela de a putea localiza, cu o acurateţe cât mai mare, poziţia de apariţie a greşelilor de interpretare a documentului iniţial. Drept consecinţă, vom considera o reprezentare schematică a întregii secvenţe de prelucrare, din faza de document şi până la tipărirea efectivă (figura 1). Un astfel de lanţ de procesare rămâne valabil atât pentru echipamentele digitale, cât şi pentru cele offset. În cazul celor offset, locul ultimului element reprezentat poate fi luat de către un platesetter sau un imagesetter.
Aşa cum se poate observa, punctele „cheie” în care pot apărea erorile de procesare sunt: echipamentul de printare – A, software-ul de rasterizare a fişierului postscript (RIP) – B, mediul de transmitere a informaţiei (reţeaua de calculatoare) – C, driverul postscript folosit – D, aplicaţia grafică – E şi, în final, documentul de printat (reprezentat îndeosebi de modul de creare al elementelor constituente) – F. Înainte însă de a trece la analiza efectivă a acestora, consider utilă prezentarea câtorva exemple vizuale (perechi document-print rezultat).(figura 2) După cum am arătat anterior, primul element ce ar trebui analizat este modulul RIP (raster image processing). În acest caz avem două situaţii posibile, şi anume:
1) dispunem de un preview, o reprezentare vizuală a datelor rasterizate. Astfel, prin simpla comparaţie cu documentul original, putem decide dacă eroarea este provocată sau nu de dispozitivul de imprimare efectivă (A) sau de catre RIP (B).
2) nu se poate face un preview, iar pentru această situaţie nu putem decela între locaţiile A şi B, deci trecem la pasul următor al analizei. Deşi improbabil, în practică există situaţii în care mediul de transmitere la distanţă (reţea, Internet – C) poate deteriora conţinutul informaţiei, însă din fericire, există o multitudine de soluţii pentru detectarea acestor anomalii. Cea mai simplă şi la îndemână este aceea de importare directă a fișierului postscript în RIP sau echipament folosind un mediu de stocare portabil al datelor, precum un stick USB.

Dacă nici în acest punct nu se constată o îmbunătăţire a rezultatelor (printurilor), singura locaţie ce mai rămâne de cercetat este cea reprezentată de staţia de lucru, adică totalitatea ansamblului calculator (sistem de operare), driver de imprimare, aplicaţie grafică şi documentul propriu-zis. Şi, de fapt, aici intervine „greul”. Cum putem, de exemplu, să scoatem din ecuaţie driverul postscript sau modul de realizare al documentului? Soluţia magică este „Print to file…”, adică generarea şi salvarea locală pe calculatorul de lucru a fişierului postscript, în locul trimiterii lui direct, dar şi transparent pentru utilizator, la dispozitivul de imprimare. Următorul pas ar putea fi analizarea în sine a fişierului rezultat, însă din păcate, aceasta nu este o soluţie la îndemâna oricui deoarece necesită cunoştinţe solide de programare şi sintaxă postscript, fiind totodată şi mare consumatoare de timp. Scopul nostru este acela de a utiliza soluţii cât mai simple, rapide şi care pot fi aplicate indiferent de bagajul de cunoştinţe al utilizatorului.

Există însă alternative mult mai comode, dar şi extrem de „economice”. Vom prezenta doar două dintre aceste soluţii considerate de noi ca fiind printre cele mai reprezentative. Prima dintre acestea se numeşte Ghostscript, fiind în esenţă un interpretor postscript extrem de puternic şi versatil. Totodată, acesta poate fi folosit şi ca un procesor de imagine rasterizată (RIP). Un mic impediment ar fi acela că acest program nu dispune nativ de o interfaţă grafică pentru utilizator, controlul acestuia făcându-se doar la nivel de linie de comandă (DOS prompt). Deci este necesară instalarea independentă a unui alt software numit GSView, disponibil gratuit ( figura 3), ce va prelua acest rol.

Trebuie menţionat faptul că, începând cu versiunea 9.0, actual – 9.18, Ghostscript dispune intern şi de mecanisme de management de culoare prin folosirea profilelor ICC, acest fapt permițând comparaţii vizuale din punct de vedere coloristic între documentul original şi reprezentarea postscript a acestuia. Mai mult, Ghostscript poate fi utilizat cu succes pentru convertirea documentelor în formatele standardizate PDF/A, pentru arhivare, şi PDF/X3, specific industriei artelor grafice, punând la dispoziţie chiar şi un driver postscript de imprimantă în scopul facilitării acesteia. Totuşi, merită să menționăm două modalităţi de utilizare a GostScript-ului în ceea ce priveşte obţinerea de informaţii valoroase dintr-un fişier postscript, sau virtual din orice alt tip de document, folosind soluţia „Print to file…” amintită anterior.
Prima dintre acestea este reprezentată de detecţia prezenţei culorilor speciale într-un document, mai ales în cazul PDF-urilor. Ideea de bază este convertirea fişierului postscript în formatul Adobe Photoshop PSD. Comanda utilizată pentru aceasta este: „gswin32c.exe -q -r150 -dNOPAUSE -sDEVICE=psdcmyk -o fiesire_%04d.psd -f fintrare.ps “, unde ’-r150’ reprezintă rezoluţia fişierului PSD rezultat (150 dpi), ‘fiesire’ – numele documentului PSD (fără extensie), respectiv ‘fintrare.ps’ pe cel al postscriptului de analizat. Secvenţa ’_%04d’ este instrucţiunea de generare a câte unui fişier PSD pentru fiecare pagină a documentului. Astfel, pentru documentul postscript fintrare.ps cu trei pagini se vor obţine fiesire0001.psd, fiesire0002.psd şi fiesire0003.psd. În figura 4, este prezentat un fişier PSD astfel obţinut.

Se observă în secţiunea de layere existenţa tuturor culorilor speciale utilizate (în cazul nostru, Pantone 266 şi Pantone 299), cât şi poziţionarea lor exactă în layoutul documentului. Bineînţeles, această analiză poate deveni prohibitivă în cazul documentelor cu foarte multe pagini, fiind necesară deschiderea şi inspectarea unui număr mare de fişiere PSD. Rămâne totuşi o soluţie viabilă şi economică mai ales în situaţia în care nu dispunem de software specializat, precum Acrobat Professional, şi avem de-a face cu documente cu un număr rezonabil de pagini.
Cealaltă modalitate auxiliară de utilizare a Ghostscript este legată de gradul de acoperire cu cerneală (ink coverage) pentru un document. Aceasta poate reprezenta o informaţie utilă atât în ceea ce priveşte calculul estimativ al costurilor de tipărire, cât şi al decelării, în cadrul unui document, al paginilor alb-negru de cele color, ceea ce este util în situaţia printării pe echipamente digitale alb-negru şi color pentru optimizarea costurilor. Comanda folosită pentru determinarea gradului de acoperire cu cerneală este: „gswin32c.exe -q -o – -sDEVICE=inkcov fisier”.

Fişierele acceptate sunt atât cele de tip postscript, cât şi PDF. Drept rezultat se obţin doar procentaje CMYK, eventualele elemente monocrome sau RGB din document fiind convertite intern în mod generic. Cu alte cuvinte, rezultatele obţinute nu sunt foarte exacte, mai ales în situ-aţia în care avem activat mecanismul de management de culoare în RIP-ul echipamentului de tipărire folosit. Pentru a ne apropia cât mai mult de situaţia reală, putem include profilele ICC utilizate astfel: „gswin32c.exe -q -o – -sDEVICE=inkcov -sDefaultCMYKProfile=ISOcoated_v2_eci.icc -sDefaultRGBProfile=AdobeRGB1998.icc -sOutputICCProfile=EchipamentPrintare.icc fisier”, unde -sDefaultCMYKProfile şi -sDefaultRGBProfile sunt profilele de cu-loare utilizate drept spaţiu de lucru, iar -sOutputICCProfile reprezintă profilul de culoare al echipamentului de printare utilizat. Condiţia necesară şi suficientă este ca profilele menţionate să se afle în acelaşi director cu gswin32c.exe. În ceea ce priveşte detectarea paginilor alb-negru, vă propunem un mic experiment: am creat două documente precum cel din figura 5 pe care le-am convertit ulterior în format PDF, generând fișiere postscript utilizând un driver şi „Print to file…”

Acest din urmă pas este opţional, putându-se analiza direct fişierele PDF. Singura diferenţă dintre cele două documente este reprezentată de poză, într-unul ea fiind monocromă, iar în celălalt convertită în RGB. Rezultatul analizării acestora în ceea ce priveşte gradul de acoperire cu cerneală este prezentat în figura 6. Se poate observa cu uşurinţă fişierul monocrom (valori de 0% pentru CMY), cât şi faptul că al doilea document prezintă procentaje identice, dar nenule de C,M şi Y. Practic, aceasta este o indicaţie a faptului că, în marea majoritate a cazurilor, putem tipări folosind doar K acest din urmă fişier, deşi nu este unul monocrom. Am spus „marea majoritate a cazurilor” deoarece există unul particular în care printarea folosind doar cerneală sau toner K nu este recomandată.

De exemplu, dacă documentul conţine doar elemente monocrome plus trei imagini CMYK, fiecare dintre ele cu aceeaşi deviaţie spre una dintre culorile de bază (de exemplu, prima cu 11% spre C, a doua cu 11% spre M şi a treia cu 11% spre Y). Per totalul documentului, procentajele de C, M şi Y vor fi identice, însă nu vom putea trage concluzia cum că întregul fişier este sau poate fi tipărit monocrom. Este, totuşi, aşa cum am mai spus, un caz cu totul special şi destul de improbabil să apară în realitate. Încheiem în acest punct discuţia referitoare la Ghostscript şi, revenind la programele software de vizualizare a fişierelor postscript, ne grăbim să enumerăm o a doua variantă, disponibilă gratuit, eVince (figura 7).

Ambele pachete software amintite în acest articol dispun de versiuni portabile, ceea ce le întăreşte şi mai mult statutul de unelte indispensabile ale oricărui departament de prepress sau dtp. În consecinţă, cu ajutorul acestora, putem determina acum eventualele probleme legate de ultimele segmente rămase spre a fi analizate (D, E şi F). Aşa cum am menţionat anterior, soluţia ce se impune este de a „capta” fişierul postscript generat pe calculatorul gazdă prin folosirea opţiunii „Print to file” (figura 8). Marea majoritate a aplicaţiilor grafice şi a driverelor de printare permit asta, deci lasându-ne posibilitatea vizualizării efective a fişierului rezultat, fără a mai fi nevoie de prezenţa fizică a unui echipament de printare sau de RIP-uire. Bineînţeles, cineva ar putea riposta: de ce să nu exportăm fişierul ca PDF direct din aplicaţie şi să-l vizualizăm ulterior?

Personal, nu recomand această soluţie, deoarece, în cele mai multe dintre cazuri, toate fişierele PDF rezultate vor fi identice cu documentul original, putând duce la rezultate sau concluzii eronate. Deci, acum putem ajunge în potenţiala situaţie în care driverul postscript sau documentul în sine sunt elementele generatoare de erori. Mai trebuie doar să decidem între cele două. Dar cum? Răspunsul este foarte simplu: să printăm folosind un alt echipament postscript (eventual de la un alt producător). Şi nu, nu este necesară existenţa fizică a unui astfel de printer, ci doar a driverului postscript corespunzător. Deci, paşii de efectuat în continuare sunt următorii: se instalează unul sau mai multe drivere pentru diverse echipamente, dar totuşi din aceeaşi clasă ca şi putere de procesare, sau unul „generic” de la Adobe, apoi se printează din nou într-un fişier vizualizat apoi cu unul dintre utilitarele mai sus menţionate (figura 9).

Dacă eroarea persistă, suntem nevoiţi să scoatem din calcul driverul, singura posibilitate rămasă fiind aceea de creare a documentului (transparenţe, overprinturi, elemente grafice vectoriale mult prea complexe – cu zeci, sute de mii de puncte). De fapt, datorită simplităţii şi rapidităţii acestei proceduri, este recomandat ca aceasta să fie executată prima, pentru a putea elimina din start modul de creare al documentului. Bineînţeles, poate fi extrem de complicat şi consumator de timp operaţia de „depanare” a unui document, însă în ceea ce ne priveşte, ne-am atins scopul propus, și anume acela de localizare a elementului generator de eroare, iar o soluţie ar putea fi exportarea documentului ca PDF şi ulterior printarea acestuia.
Ca o paranteză ce trebuie totuşi amintită, după cum probabil aţi observat, am insistat asupra termenului de „postscript”. În preambulul acestui articol am amintit, de asemenea, situaţia „imprimantei de birou de 25 de euro” care, cel mai probabil, era una GDI sau PCL. Aceste tipuri de echipamente sunt aproape imune la modul de creare al documentelor datorită setului de facilităţi şi opţiuni mult mai redus decât în cazul postscriptului, reducându-se mult posibilitatea de apariţie a greşelilor de interpretare corectă.
În concluzie, urmând paşii descrişi anterior, se poate efectua o analiză extrem de rapidă şi concludentă în cazul apariţiei apariţiei de „printuri eronate”, fără a începe să „alergăm”, de multe ori fără succes, după update-uri sau patch-uri pentru drivere, RIP-uri, sistem de operare sau pentru aplicaţiile grafice folosite.